[Bug]: All current NFL event channels (5000+) stall after source segment fetch failures

[bonzenpaule]

Description

Hello RebelIPTV team,

thank you for maintaining this project. I am reporting a reproducible issue affecting the dynamic NFL team/event streams in RebelIPTV. Regular IPTV channels continue to work normally, but the dedicated NFL team stream and the NFL game event stream do not deliver a sustained video stream.

On 2026-08-21 and on 2026-08-22 I tested my team stream (Channel 4000) and every current NFL event channel exposed in the generated playlist (channels 5000–5003), and none delivered a sustained stream.

Summary

The investigation shows the failure affects the complete NFL event set.

1. Denver Broncos team channel

   • Playlist channel ID: team-nfl-den
   • Stream endpoint: /stream/team-nfl-den.ts
   • Playlist channel number: 4000

2. Green Bay Packers vs Denver Broncos event channel

   • Playlist channel ID: gbp-vs-den-nfl-2026-08-21
   • Stream endpoint: /stream/gbp-vs-den-nfl-2026-08-21.ts
   • Playlist channel number: 5002

The proxy returns HTTP 200 and Content-Type: video/mp2t, but the stream subsequently stalls. In the failing tests the response included:

X-Stream-Error: source stalled: 5 consecutive segment fetches failed

The same problem is not present on several regular channels from the same RebelIPTV instance. Subsequent testing shows that this is not limited to Denver: all four currently listed NFL event channels in the 5000 range showed the same failure pattern.

Steps to Reproduce

Reproduction

curl --max-time 15 -D headers.txt \
  -o stream.ts \
  "http://<REBELIPTV_HOST>:8080/stream/team-nfl-den.ts"

curl --max-time 15 -D headers.txt \
  -o stream.ts \
  "http://<REBELIPTV_HOST>:8080/stream/gbp-vs-den-nfl-2026-08-21.ts"

Observed behavior:

• HTTP status: 200 OK
• Content type: video/mp2t
• The connection may initially return data, but then stops receiving usable data.
• In later tests the request timed out with 0 bytes received.
• When data was initially received, the response ended with the proxy diagnostic header:

X-Stream-Error: source stalled: 5 consecutive segment fetches failed

The same test against regular Denver local channels succeeded:

/stream/us/kcnc.ts   -> HTTP 200, approximately 23 MB received in 15 seconds
/stream/us/kdvr.ts   -> HTTP 200, approximately 1.5 MB received in 15 seconds

The exact byte counts vary by timing, but both regular channels delivered continuous data during the test.

Affected playlist entries

The generated M3U contains the expected dynamic entries:

#EXTINF:-1 channel-id="team-nfl-den" tvg-id="team-nfl-den" tvg-chno="4000" tvg-name="Denver Broncos" ... ,Denver Broncos
http://<REBELIPTV_HOST>:8080/stream/team-nfl-den.ts

#EXTINF:-1 channel-id="gbp-vs-den-nfl-2026-08-21" tvg-id="gbp-vs-den-nfl-2026-08-21" tvg-chno="5002" tvg-name="Green Bay Packers vs Denver Broncos" ... ,Green Bay Packers vs Denver Broncos
http://<REBELIPTV_HOST>:8080/stream/gbp-vs-den-nfl-2026-08-21.ts

The playlist itself is generated successfully with HTTP 200. The XMLTV EPG is also generated successfully with HTTP 200 and contains the expected guide data.

What has been checked locally

• RebelIPTV container is running and healthy.
• RebelIPTV health endpoint responds successfully.
• Playlist endpoint responds successfully.
• EPG endpoint responds successfully.
• Regular channels from the same lineup stream successfully.
• There are no useful error messages in the RebelIPTV Docker stdout logs.
• Purging the RebelIPTV data and rebuilding/scraping the data did not resolve the issue.
• The installation is already running the latest published RebelIPTV release, v1.4.1.
• Retrying the affected streams at a later time produced the same failure pattern.

This makes a local Docker, playlist, EPG, or basic connectivity problem unlikely. The failure appears specific to the upstream sources selected for these dynamic NFL team/event feeds, or to the event-stream resolver/failover path.

Expected behavior

When a team or event stream is present in the generated M3U, tuning it should result in a continuous MPEG-TS stream. If no upstream source is currently available, the dashboard should ideally mark the stream unavailable before advertising it as a playable channel, or expose a clearer diagnostic indicating that all event sources failed.

Actual behavior

The dynamic streams are advertised and return HTTP 200, but no sustained stream is available. They either:

• start briefly and then stop after repeated segment-fetch failures, or
• time out without delivering data on a subsequent attempt.

The regular channels continue to work.

Comparative test: all current NFL event channels

At approximately 2026-08-22 04:00 CEST, the generated playlist contained these four current NFL event channels:

Channel	Event	Result
5000	Chicago Bears vs Cincinnati Bengals	HTTP 200, then source stalled: 5 consecutive segment fetches failed; 499,450 bytes before timeout
5001	Philadelphia Eagles vs New England Patriots	timeout after 10 seconds, 0 bytes received
5002	Kansas City Chiefs vs Tampa Bay Buccaneers	HTTP 200, then the same stall error; 399,560 bytes before timeout
5003	Dallas Cowboys vs Arizona Cardinals	HTTP 200, then the same stall error; 209,769 bytes before timeout

This broadens the original report substantially: it is not a Broncos-specific event or team problem. Every currently listed NFL event channel tested failed to provide a sustained stream. Some channels emit a short fragment before stalling; another produced no bytes at all.

The same RebelIPTV instance continued to expose the event entries in the M3U and reported a healthy API. The generated playlist and EPG endpoints also remained available. This points more strongly to a common event-stream upstream/resolver path (or a common event-source availability issue) rather than an individual game, individual team, local Docker networking, or a single corrupted database record.

Current service checks

• Health endpoint: healthy, 449 channels, 5 current events at the time of the latest check.
• Instance uptime: approximately 752,360 seconds at the latest health check.
• Playlist and EPG endpoints: HTTP 200 and successfully generated.
• Regular channels from the same instance: still available.
• All four current NFL event streams tested: failed as described above.
• Data purge/re-scrape: already attempted without resolving the problem.
• Version: already running v1.4.1, the latest published release at the time of testing.
• GitHub issue search: no open issue matching this exact common “all event channels stall” symptom was found.

IPTV Client

Jellyfin

Instance ID

89a3fb0a-80fc-83d8-a1f0-fb2bf214f57d

Version

1.4.1

Deployment Method

Docker Compose

Screenshots

I reviewed the relevant upstream reports and documentation:

• Issue #65 — Stream Not available yet was closed after the reporter confirmed that purging and re-scraping fixed corrupted sports data. That remedy was attempted here and did not help.
• Issue #55 — Persistent Sports Team Channels documents that team channels are intentionally persistent dynamic channels whose stream resolves to the current live event. It does not indicate that team channels are independent broadcast sources.
• Release v1.4.1 notes improvements to buffering, retries for sports fixture lookup, and stream handling, but the current installation already runs this release.
• The project README describes multi-source fallback and stream health monitoring. In this incident, the proxy still reports five consecutive segment-fetch failures across every tested current NFL event, suggesting that fallback candidates are either unavailable or that the event resolver is receiving no usable source.

The evidence therefore favors a shared upstream event-source failure or a resolver/failover problem that is not fixed by local re-scraping.

Priority

None

[rebel-bot]

Thanks for an exceptionally well-documented report — the per-channel breakdown and the X-Stream-Error captures made this much faster to trace than it would have been otherwise.

There are two separate causes here, and they compound each other.

1. Upstream sources are refusing/throttling your instance's network

The errors your instance has reported point to network-level blocking rather than a missing stream:

• One upstream is returning an explicit Website Access Blocked interstitial (HTTP 403) to your instance — an access-control page, not an authentication or credentials failure.
• The event streams themselves are recorded as connecting and then starving — the source is reached, but stops delivering data fast enough to sustain playback. Internally that is logged as starved, and it is exactly what your source stalled: 5 consecutive segment fetches failed is describing from the client side. A stream that genuinely didn't exist would fail differently and earlier.

That combination — an outright access-denied from one upstream, plus throttled throughput on the others — is the signature of a VPN or datacenter exit IP. The upstreams that serve live sports events are considerably more aggressive about
rate-limiting and blocklisting shared exit addresses than the ones serving regular channels.

This also explains the part of your report that looks contradictory at first: your regular channels keep working because they come from entirely different upstreams, which don't apply the same restrictions. It isn't that events are broken
and channels aren't — it's that only one of those two groups is being filtered on your egress address.

It's also why the purge and re-scrape didn't help. That rebuilds which events we find; the failure is in fetching them, further down.

2. A real bug on our side made this much worse than it should have been

Independently of your network, two of our event sources had stopped contributing anything — one because a site changed its page structure, one because of a configuration bug on our end. Neither failed loudly, so both went unnoticed.

The consequence for you: the affected games carried far fewer fallback sources than they were designed to. Our telemetry shows your instance running out of alternatives entirely — one source degraded and there was nothing left to switch to,
so the channel simply died instead of failing over.

Both are fixed in an upcoming release (1.4.2). Those same events now carry several working sources apiece, so a single throttled or blocked source degrades gracefully instead of taking the channel down. We've also added monitoring so a
source that quietly stops contributing raises an alert instead of looking like "no games today".

What would help to confirm

Could you try tuning one of the event channels with the VPN disabled, or with the container excluded from it (split tunnel)? That single test will separate the two causes cleanly.

To check what address the container is actually egressing from:

docker exec <container-name> wget -qO- https://api.ipify.org                                                                                                                                                                                      

If that shows your VPN's address rather than your ISP's, the container's traffic is going through the tunnel, and event sources will be treating it accordingly.

Setting expectations

To be straightforward about it: 1.4.2 will improve this but may not fully resolve it while the traffic is on a blocked exit. More sources means more chances one of them isn't being throttled — it doesn't make a blocklisted address
un-blocklisted. If the no-VPN test plays cleanly, routing the container outside the tunnel (or switching to a different exit) is likely to be the durable fix.

If the no-VPN test still fails, that's genuinely useful to know — please report back and we'll keep digging, as it would point somewhere else entirely.

[bonzenpaule]

Hi!
Thanks for your fast reply. Next weekend I will try the streams withoug my VPN and report back.
I didn't think the VPN would be an issue because the weekend before everything was working well (channel 4000 and 500X).