MediaSourceDoctor: diagnose a manifest whose media is not published yet

Open
  • Is something wrong?
#199 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
25/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
android, kotlin
Domain
devtools, mobile

Research direction

Start with the dash-availability-start-time-skew corpus entry and its CANNOT_RECOVER row in HostileManifestLadderTest, then PRD.md §3.6 for the doctor's scope. The skew check is already named there, so the fixture and acceptance test are the newcomer-sized part. Do not settle where a non-error waiting state is reported; that design question belongs with the doctor and ADR-0011. Done means the row can be asserted against the doctor's output, and a BENIGN few-second skew is not flagged.

Written by the indexing model from the issue text.

Description

enhancement

Phase 5's fault sweep found the one hostile-corpus entry the fallback ladder cannot rescue. The ladder is not at fault, and neither is resilience: this is a diagnostics ticket, with one open design question at the end that diagnostics alone does not close.

What was found

dash-availability-start-time-skew sets an availabilityStartTime an hour ahead of now. Every segment it lists is therefore legitimately unpublished, so no load fails: the player waits, correctly, and forever. HostileManifestLadderTest records it in CANNOT_RECOVER with that reason rather than leaving it out, guarded by nothingListedAsBeyondTheLadderIsQuietlyPassing so the exemption cannot become a hiding place.

No rung would help. There is no failed load to retry, no host to fall back to, no variant to exclude, and nothing to classify — the ladder is never asked, because nothing went wrong.

The narrow half is already in scope

PRD.md §3.6 already names this pathology in MediaSourceDoctor's list:

a preflight and postmortem analyzer that fetches a manifest and reports pathologies in plain language: … DASH availabilityStartTime clock skew, missing or short timeShiftBufferDepth …

So this issue does not ask for a new check. What it adds is the fixture and the acceptance test: the corpus entry exists, and its CANNOT_RECOVER row in HostileManifestLadderTest is the thing the doctor's arrival should be able to change. Phase 9's exit criterion is "the doctor correctly identifies each pathology in a curated set of deliberately broken manifests", and this is one of them, already curated.

Worth checking when the doctor is built: the corpus generates graded severities, and BENIGN exists so a doctor is scored on false positives too. A clock skew of a few seconds is normal and must not be reported as a fault.

The open half, which is not the doctor's

The doctor supplies the explanation. What is missing is the trigger.

ADR-0011's ladder exists for failures: a load errors, a class is assigned, rungs are climbed, and rung 6 delivers a typed SuperPlayerError. A player waiting correctly for media that does not exist yet has raised nothing, so there is nothing to classify and nothing to deliver. From the outside — and from a consumer's listeners — it is indistinguishable from a slow network.

Diagnostics cannot close this on its own, for two reasons:

  • the doctor is invoked, not ambient, so something in the production path has to notice the situation is worth diagnosing;
  • the debug HUD is debug-builds-only (PRD.md §3.6), while a viewer-facing "this stream has not started yet" needs a release path.

So the question this issue opens is where a non-error condition is reported from: a distinct player state, a telemetry event, or a postmortem the player triggers itself after buffering at a standstill with no error for some interval. That is a core-facing design decision, it touches ADR-0011's "rung 6 is the top" framing, and it should be decided alongside the doctor rather than before it — the doctor is what makes the answer worth anything.

Notes

  • Not a blocker for Phase 5, which is complete.
  • Found while closing #184.
Dominant language
Kotlin
Stars
1
Forks
0
Avg merge
3h 32m
Merged PRs (30d)
64

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ramesh130/superplayer

All issues in ramesh130/superplayer

Similar issues

More Kotlin issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.