[BUG] #554

Activity

1. Nawid3333 commented on Sep 28, 2026

   

   Nawid3333

   on Sep 28, 2026

   Last edited by Nawid3333

   Contributor

   More actions

   Thanks for reporting this issue!

   Here is what I'm seeing on my end regarding the issue you described:

   Player Behavior: On aniwaves.ru, Vidplay is indeed the primary provider having issues. The stream/player detection fails to replace the native player properly or hangs during loading.

   Work in Progress: I am currently addressing player detection and stream extraction improvements in my own fork to handle these updated video player signatures.

   Important Notes Regarding My Fork:

   Firefox Exclusive: My personal fork targets Firefox exclusively. If you decide to test or use my version, keep in mind that I do not test or guarantee compatibility with Edge or Chromium-based browsers. If you are open to using Firefox, that will give you the best compatibility with my fix once it's ready.

   Upstream PR: Because adapting these changes to support all platforms cleanly requires extensive testing to avoid breaking existing setups across the core codebase, I may not immediately submit a Pull Request upstream.

   I'll share updates here once I have a stable fix verified!
2. Nawid3333 commented on Sep 29, 2026

   

   Nawid3333

   on Sep 29, 2026

   Contributor

   More actions

   Update: this is fixed in my fork, in v1.3.82.38.

   What went wrong on anikage.cc: the episode is an HLS stream whose URL has no .m3u8 extension (…/m3u8/<token>). Only the server's Content-Type: application/vnd.apple.mpegurl says what it is. FastStream recognises a stream mainly by its URL's extension, so it never saw this one. It took another of the page's requests for an MP4 file instead, and that one can't play.

   The fix, in two parts:

   1. A URL without a stream extension counts as HLS or DASH when its Content-Type says so.
   2. When a page loads several streams (ads, intros, previews), FastStream plays the longest. It reads each stream's length in the background, from the HLS or DASH manifest or from the header of an MP4 or WebM file.

   With both, anikage plays the episode. aniwaves.ru works for me too. And works yomi.to too.

   To use it: my fork runs on Firefox only (142 or newer). Install the .xpi from the latest release. It's signed by Mozilla and updates itself. Turn off the store version of FastStream while you use it, so the two don't both try to take over the player. On Edge and other Chromium browsers, the fix would have to land here.

   @Andrews54757, in case you want to bring it over, the diff is in Nawid3333#50:

   • Content-Type detection: ManifestTypes.mjs, called from onHeadersReceived in background.mjs.
   • Stream lengths: StreamLength.mjs parses them (no browser APIs) and StreamLengths.mjs reads them. The pick is in recieveSources in player/main.mjs.

   Notes for porting it to Chromium

   • onHeadersReceived needs 'responseHeaders' in its options to see the Content-Type. Your detection listener has none, on either browser.
   • The length reads need the page's Referer, Origin and cookies, which fetch() can't set. I add a declarativeNetRequest session rule for the stream's URL, limited to tabIds: [chrome.tabs.TAB_ID_NONE], so only the background's own requests get them. I measured that in Firefox; I haven't tried it in Chrome.
   • onHeadersReceived has to skip those reads, or they come back as sources of tab -1. Firefox gives the extension's origin in originUrl, Chrome in initiator.
   • A stream of unknown length counts as 10 minutes, and streams within 10% of the longest are left to the old rule. So a page with one stream, or with streams of unknown length, plays what it did before.
   • With two or more streams, the background waits up to 2.5 s for lengths still being read before it hands them to the player. The reads start as soon as a stream is detected, so they're usually done by then.