Video quality capped at 360p despite bg-helper (PO token) correctly configured

[TTG3301]

Checklist

• I am able to reproduce the bug with the latest version given here: CLICK THIS LINK.
• I am aware that this issue is being opened for the NewPipe Extractor, NOT the app, and my bug report will be dismissed otherwise.
• I made sure that there are no existing issues - open or closed - which I could contribute my information to.
• I have taken the time to fill in all the required details. I understand that the bug report will be dismissed otherwise.
• This issue contains only one bug.
• I have read and understood the contribution guidelines.

Affected version

2026-08-02/03

Steps to reproduce the bug

1. Deploy Piped per the above, confirm all containers healthy (docker compose ps).
2. Search for and play any YouTube video.
3. Check available quality via the API directly:
   curl -s https://pipedapi./streams/<video_id> | python3 -m json.tool | grep quality

Expected behavior

The full quality ladder (up to whatever the source video actually offers — 720p/1080p/etc.) should be available, especially since bg-helper is running and correctly wired up specifically to solve this class of problem (YouTube's PO token / SABR-enforcement requirement).

Actual behavior

Only a single stream is ever returned:

"quality": "360p",

Tested across multiple, unrelated video IDs — same result every time. No higher resolutions are offered by the API at all (not just hidden/unselectable in the frontend — confirmed directly against the backend's own /streams/ response).

Screenshots/Screen recordings

No response

Logs

Logs

bg-helper — entire log output since container start, nothing else is ever printed (no per-request activity, no errors):

Server started at http://0.0.0.0:3000

piped (backend) — startup, followed by a real extraction failure on a different video (same symptom, different ID — included to show this isn't specific to one video):

Database connection is ready!
PubSub: queue size - 0 channels
Cleanup: Removed 0 old videos
An error occoured in the path: /streams/mJaWwnPoNKE
org.schabi.newpipe.extractor.stream.StreamInfo$StreamExtractException: Could not get any stream. See error variable to get further details.
	at org.schabi.newpipe.extractor.stream.StreamInfo.extractStreams(StreamInfo.java:189)
	at org.schabi.newpipe.extractor.stream.StreamInfo.getInfo(StreamInfo.java:99)
	at org.schabi.newpipe.extractor.stream.StreamInfo.getInfo(StreamInfo.java:89)
	at org.schabi.newpipe.extractor.stream.StreamInfo.getInfo(StreamInfo.java:83)
	at me.kavin.piped.server.handlers.StreamHandlers.lambda$streamsResponse$0(StreamHandlers.java:54)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
	at java.base/java.lang.VirtualThread.run(VirtualThread.java:329)

Note this particular video (mJaWwnPoNKE) fails extraction entirely (no stream at all, not even 360p), while other videos tested (e.g. the one used in the quality comparison above) do extract successfully but capped at 360p — suggesting at least two distinct failure modes are in play, both plausibly tied to the same underlying PO token/SABR problem.

curl -vk against the instance's own HTTPS endpoint, confirming this isn't a TLS/network issue — the backend itself is reachable and responding normally, just with degraded stream data:

< HTTP/1.1 200 OK
< Server: nginx/1.31.3
< Content-Type: text/html

Question

Is there additional bg-helper configuration needed beyond BG_HELPER_URL to get it actually generating/applying valid PO tokens, or is this simply the current known state of bg-helper-server's development? Happy to provide more logs/debug output if useful — bg-helper's own logs currently only show its startup line with nothing per-request, so pointers on how to get more visibility (increased log verbosity, a way to confirm token generation succeeded/failed per-request) would also help.

Related upstream threads

• TeamNewPipe/NewPipe#13320 — the general SABR-enforcement/360p-cap issue this is presumably downstream of.
• TeamNewPipe/NewPipeExtractor#858 — active discussion redesigning the extractor's stream API with SABR as a first-class concept, suggesting a more durable fix is in progress upstream (though an in-progress branch linked there reportedly doesn't compile yet, so no ETA).

Additional information

Additional context — direct comparison against Invidious

To rule out something specific to my own network/IP being flagged by YouTube, I stood up a self-hosted Invidious instance (official production Docker Compose + the required Invidious companion sidecar, quay.io/invidious/invidious-companion:latest) on the same NAS, same network, same outbound IP, and tested the identical video ID:

curl -s http://localhost:3000/api/v1/videos/<same_video_id> | python3 -m json.tool | grep -E '"qualityLabel"'

Result — full ladder returned:

"qualityLabel": "144p",
"qualityLabel": "240p",
"qualityLabel": "360p",
"qualityLabel": "480p",
"qualityLabel": "720p",
"qualityLabel": "1080p",
"qualityLabel": "1440p",
"qualityLabel": "2160p",

This strongly suggests the SABR/PO-token bypass is achievable from this exact network/IP — Invidious's companion is succeeding at it, while Piped's bg-helper is not, despite being correctly configured and running without errors.

I'm aware bg-helper-server's own README currently marks itself # WIP ("This will be a server that can be used to generate PoTokens" — future tense), so this may simply be a maturity gap rather than a misconfiguration on my end. Filing this in case it's useful as a concrete, reproducible data point (exact config, versions, and a working counter-example on the same network) for whoever's working on this.

Question

Is there additional bg-helper configuration needed beyond BG_HELPER_URL to get it actually generating/applying valid PO tokens, or is this simply the current known state of bg-helper-server's development? Happy to provide more logs/debug output if useful — bg-helper's own logs currently only show its startup line with nothing per-request, so pointers on how to get more visibility would also help.