[Nawid3333]

FastStream now finds HLS and DASH manifests whose URL has no extension, by their Content-Type. Of a page's streams, the player now plays the longest, not the newest. This fixes anikage.cc (upstream issue 554), and the ad that played instead of the film on some cineby servers.

Fixes you would notice

anikage.cc plays. The episode is an HLS master playlist at og.bakayaro.live/m3u8/<token>. The URL has no extension; only the Content-Type: application/vnd.apple.mpegurl says what it is, so FastStream never detected it. Instead it took og.bakayaro.live/stream/<token> for an MP4: a media request, labelled image/jpeg, with MPEG-TS inside. That showed "Failed to load video!".

• Now a URL without a stream extension counts as HLS or DASH when its Content-Type says so: application/vnd.apple.mpegurl, application/x-mpegurl, audio/mpegurl, audio/x-mpegurl or application/dash+xml (chrome/background/ManifestTypes.mjs). Only manifests count: segments say video/mp4 or video/mp2t.
• Measured: the 23:54 episode plays.

The film plays, not the ad. When a page runs an ad or an intro first, the ad is among the detected streams. The player picked by kind and age alone: the first HLS or DASH stream, or else the newest MP4. That was often the ad. Now the background reads how long each detected stream runs, and the player plays the longest.

• What is read (chrome/player/utils/StreamLength.mjs, no browser APIs):

  • an HLS playlist; for a master playlist, its first variant;
  • a DASH manifest's mediaPresentationDuration, or the sum of its periods;
  • the header of an MP4 or WebM file, in 64 KiB ranges. When an MP4's movie header comes after its media data, a second read goes there.

  A live stream counts as the longest.

• With the page's own Referer, Origin and cookies (chrome/background/StreamLengths.mjs). A fetch() can't set those, so a declarativeNetRequest session rule adds them for the stream's URL, as for the player's own requests. The rule is limited to requests in no tab (tabIds: [TAB_ID_NONE]), so only the background's reads get them. A server that answers only the site's pages answers these reads too.

• When lengths are unknown or close: a stream of unknown length counts as 10 minutes. It beats a short ad and loses to a known full episode. Streams within 10% of the longest tie, and the old rule decides between those. So a page with one stream, or with streams of unknown length, plays what it did before.

• The Sources menu still lists every stream, to pick one by hand.

• MPV: the toolbar button and Ctrl+Shift+U's on-play fallback (for a blob: player) send the newest of the longest streams, not the newest one.

Behaviour changes

• With two or more streams, the player may open up to 2.5 s later. It waits for lengths still being read. The reads start as soon as a stream is detected, so they are usually done by then. The MPV on-play fallback waits the same way.
• The background reads the start of each stream a tab loads while FastStream is on there. At most 4 reads run at once. Each URL is read once, and the last 300 are remembered. A file gets at most three 64 KiB reads, and an HLS stream at most two playlists. Each read gives up after 8 s.
• The background's own reads are not detected as streams. They would have been sources of tab -1, pushed to every tab with a player.

Tests

• Unit: StreamLength (30), StreamLengths (17) and ManifestTypes (4).
• source-length, a new spec in test:ext (3 cases), on the installed extension with the site on the auto-enable list:
  • the film, not the ad the page loaded after it. The film is an MP4 with its movie header after the media data, as ffmpeg writes one by default;
  • manifests found by their Content-Type, and the longest played: a 9-second intro with an extension, then an HLS episode and a DASH manifest without;
  • a length read with the page's own headers, from a CDN that answers the site's pages only, and a slow read waited for.
• mpv-shortcut: a new case. An MSE player's film goes to mpv, not the ad it fetched after it.

Checked

• Full local runs: pnpm run verify and verify:linux.
• Against main's code: all 3 source-length cases fail there.
• Each part undone on its own: 48 undos, 40 in the unit tests and 8 in the browser specs. Every one was caught.
• Measured in Firefox: the rule for TAB_ID_NONE applies to the background's fetch(). The CDN case above depends on it.
• Measured in Firefox: Firefox reports a response (http-on-examine-response, which onHeadersReceived is built on), and a page's fetch() resolves, only when the body starts, not when the server sends the headers. So a slow manifest is detected late. The spec slows the variant playlist, not the master, for that reason.
• Your hand test in the dev Firefox, on anikage.cc, aniwaves.ru and cineby: "everything works".

Not in this PR

cineby, all 41 servers on this build, in the test browser:

• 5 play;
• 4 find the full-length stream but hit "1 Fragment Failed", on and off;
• 3 are DASH streams that don't load. Vidsrc's URL says H.265, which Firefox often can't decode;
• 4 open on a 5-14 s ad, the only stream the page had requested by then;
• 24 show no stream at all. Finding those needs detection that hooks into the page.

Two ideas for later, not built: waiting out pages that have only short streams, and falling back to the next stream when one fails to load.

The branch also carries fd5f874, the ESLint fix for the error that stopped main's CI (client-setup.e2e.mjs). #51 carries the same commit, so merging both is harmless.

🤖 Generated with Claude Code