Very slow Firefox loading times

[t6fb3m59]

Official Instance

• The bug is reproducible on the official hosted instance, or is API-related.

Describe the bug

Shaka player seems to hang for a while before playing the video on Firefox. Upon closer inspection, it was not even waiting for requests to finish.

Might be linked with #278.

I asked Claude to look through and it delivered a hacky patch for it. I have attached the files from it for docker compose (piped-firefox-fix.zip). Make sure to delete your site cache before using it. The patch I use is for Kubernetes so I did not test this one, but it should be easy enough to fix if it has any issues. I am not sure if the maintainer still looks through issues and PRs so I will not make a fork or a PR until this issue is either ignored or aknowledged.

Here is a full write-up from Claude:

Player init stalls 15–20 seconds on Firefox before first frame (MediaCapabilities decodingInfo storm)

Affected

Firefox and other Gecko-based browsers. Not reproducible on Chromium.

Symptom

On a video watch page, the player UI renders and a spinner shows, then the page sits idle for up to a couple of minutes (more commonly around 10-20 seconds) before any segment is fetched or any frame is decoded. Looks like a network or codec stall but is neither — the JS event loop appears parked, no appendBuffer calls, no Shaka ticks, no fetches during the gap.

Root cause

Shaka Player's filterManifestByMediaCapabilities() calls navigator.mediaCapabilities.decodingInfo() once per Variant in the manifest. Firefox's native implementation costs ~14 ms per call (out-of-process RDD decoder probe). YouTube DASH manifests served via Piped routinely have 1000+ variants (codecs × resolutions × framerates × HDR / audio combos). Cumulative cost: ~14 ms × ~1230 ≈ 17 s, during which Shaka is blocked before addSourceBuffer even runs.

Evidence (reproducible in any Firefox DevTools console on a Piped instance)

• MediaSource instrumentation shows sourceopen at +0 ms, first addSourceBuffer at +26 s — the gap is inside Shaka's load flow, not in the MSE platform.
• Probing navigator.mediaCapabilities.decodingInfo directly returns [decodingInfo] 1230 calls, total 17750 ms.

Known upstream

shaka-project/shaka-player#4775 — Player init very slow in Firefox if there are a lot of variant tracks. Open since Dec 2022, no fix merged. The reporter suggests adding a caching layer in lib/util/stream_utils.js.

Workaround in place

A small ES5 script injected into index.html wraps navigator.mediaCapabilities.decodingInfo so that — for non-DRM media-source queries on Gecko UAs only — it returns a synthetic response derived from MediaSource.isTypeSupported (sub-ms on Firefox), with a per-MIME cache. DRM queries fall through to native. Reduces player init from ~17 s to ~1 s.

Trade-off accepted

smooth / powerEfficient are reported as true whenever supported is true. Shaka loses one tiebreaker for initial variant selection; ABR adapts within 1–2 s if a too-heavy variant doesn't play smoothly.

To Reproduce

1. Use a Firefox browser (mobile or desktop)
2. Click on a video (example that showed the worst symptoms I could find: https://youtu.be/q9B_2Svzt_M)
3. Wait for up to a couple of minutes.
4. Video eventually plays

Expected behavior

1. Use a Firefox browser (mobile or desktop)
2. Click on a video (example that showed the worst symptoms I could find: https://youtu.be/q9B_2Svzt_M)
3. Wait for up to a couple of seconds.
4. Video eventually plays.

Logs/Errors

No response

Browser, and OS with Version.

Several browsers confirmed across Windows, Linux, Android, all based on Firefox.

Additional context

No response

[t6fb3m59]

Turns out the service worker was causing the page without the changes to be served.

Updated patch for kubernetes/ compose: firefox-patch.zip

[t6fb3m59]

I forked the frontend to address this issue.
image: logicalkarma/piped-frontend:latest

[nyarau]

The script in the patch can also be used as a userscript without changes server side.

// @run-at      document-start
// @inject-into page