Tunarr 1.3.13: Standard HLS intermittently fails to establish successor stream at scheduled program boundary (Plex DVR stalls)

[KillerMazeOG]

Environment

• Unraid 7.2.3
• Tunarr 1.3.13
• Docker image: ghcr.io/chrisbenincasa/tunarr:latest
• Image digest: sha256:ffaedbfd237114bd68daa50405787a6d915e89456a87e86dc9e481b700c6c1b3
• FFmpeg 7.1.1
• Node.js v22.23.2 (inside running Tunarr container)
• Plex Media Server 1.43.3.10896-cb3ebc72d via Plex DVR/Live TV
• NVIDIA GeForce GTX 1080, driver 580.126.09
• Tunarr hardware acceleration: CUDA; H.264 video / AAC audio; 1920×1080
• Channel: 90s Black Entertainment, number 5, UUID b1774c9b-e04d-4db1-ae03-1bd4857a9baf
• Production stream mode: hls
• Watermark: enabled
• Transcode configuration: Default (ca0ccf3d-6dad-47bd-997e-0a7b11b35ea0)

Problem Description

During some scheduled program boundaries in Standard HLS mode, the outgoing channel-5-transcode process exits normally (signal=null, code=0, expected?=true), but the retained Channel 5 log window contains no successor transcode start and no usable successor stream is established. Plex continues polling Live TV data, stalls, and eventually stops playback.

This report describes observed behavior and does not claim a proven root cause.

Steps to Reproduce

1. Configure a Tunarr channel for Standard HLS and expose it to Plex DVR/Live TV.
2. Play the channel in Plex across a scheduled program boundary.
3. Observe Tunarr worker lifecycle and Plex live-playlist behavior at the boundary.
4. On an intermittent failing boundary, the outgoing worker exits with code 0 but a usable successor stream is not established; Plex eventually stops playback.

This is intermittent in this environment. I am attaching retained excerpts from a naturally observed failure rather than forcing another reproduction.

Expected Behavior

After the outgoing scheduled item completes, Tunarr should promptly start the next item and maintain a continuously usable stream so Plex Live TV does not stall.

Actual Behavior

At the strongest retained failure, the outgoing Channel 5 transcode exited normally. No successor Channel 5 transcode start appeared in the retained log window. Plex kept polling a live playlist whose sampled range was not advancing. Two Plex Live TV .ts requests eventually completed after approximately 180448 ms and 181578 ms, demonstrating that Plex had requests waiting for roughly three minutes. Plex then logged that it terminated the streaming session with reason Recording failed. Please check your tuner or antenna. Tunarr later force-killed the concat process after SIGTERM did not stop it. Playlist requests subsequently returned 404, and later client telemetry reported timeStalled=188.

Reproduction Timeline

All times below are 2026-08-28 EDT (UTC-04:00).

• 14:02:29.142 — Tunarr: channel-5-transcode exited. (signal=null, code=0, expected?=true).
• 14:02:29–14:06:30 — No successor Channel 5 transcode start appears in the retained log window.
• 14:04:53–14:04:59 — Plex repeatedly requests the live base/index.m3u8; requests return HTTP 200, while sampled buildLiveM3U8 state remains min 1352 max 1652 ended 0.
• 14:06:25.327 — Two Plex Live TV .ts requests complete after approximately 180448 ms and 181578 ms. The durations show that Plex had been waiting roughly three minutes for those requests.
• 14:06:25.726 — Plex logs: Streaming Resource: Terminated session ... with reason Recording failed. Please check your tuner or antenna.
• 14:06:30.020 — Tunarr: channel-5-concat still running after SIGTERM. Sending SIGKILL.
• 14:06:30.025 — Tunarr: concat exits with signal=SIGKILL, code=-1, expected?=true.
• 14:06:31.905–14:06:35.985 — Plex repeatedly requests the live playlist and receives HTTP 404.
• 14:06:36.576–14:06:36.584 — Plex receives a stopped timeline update with playbackTime=1653161 and timeStalled=188.
• 14:06:36.613 — Plex receives a stop request for the transcode session, warns that there is no valid session GUID, and returns HTTP 404.

The interval from the clean outgoing-transcode exit to forced concat cleanup is about 240.9 seconds. The two completed .ts request durations provide direct server-side evidence of requests waiting for about three minutes; the later timeStalled=188 telemetry independently reports a comparable stall duration.

Comparative Streaming Mode Tests

• Standard HLS: intermittent boundary failure as described above: outgoing transcode exits normally, no successor start in the retained window, Plex stalls and stops.
• HLS Direct v2: a successor worker/source did appear and continued after the boundary. The independent FFmpeg client ended early and logged AAC decode errors plus non-monotonically increasing DTS warnings. This did not reproduce the exact missing-successor-worker sequence.
• HLS Alt with watermark: startup failed. The client received HTTP 500; Tunarr logged retries, an ENOENT for the expected stream.m3u8, and later required SIGKILL cleanup.
• HLS Alt without watermark: the stream started. At a later transition, two Channel 5 transcodes exited normally; the client logged corrupt packets and non-monotonically increasing DTS, stopped later, and no replacement Channel 5 worker appeared in the retained filtered window.

These comparisons are observations, not proof that the modes share one root cause.

Relevant Logs

The attached evidence package contains minimal, redacted excerpts:

• tunarr-standard-hls.log
• plex-standard-hls.log
• ffmpeg-client-excerpts.log
• comparative-tests.md
• environment.md

No database or full historical log is included. Authentication query values, tokens, device identifiers, and unnecessary paths/query strings were removed or replaced.

Potentially Related Issue

Potentially related: #1727 — HLS transcode mode fails to start next program after segment transition.

Similarities:

• HLS playback freezes at a scheduled boundary.
• The outgoing transcode exits with code 0.
• No next transcode/item appears after the relevant exit.
• Plex DVR/Live TV eventually times out.
• Direct mode advances but exhibits codec/timestamp continuity problems.

Differences:

• HLS transcode mode fails to start next program after segment transition #1727 used Tunarr 1.2.3/1.2.4 as a native macOS arm64 binary with VideoToolbox; this report uses Tunarr 1.3.13 in Docker on Unraid with NVIDIA CUDA.
• HLS transcode mode fails to start next program after segment transition #1727 describes the HLS failure as consistently reproducible; this environment shows intermittent Standard HLS failures.
• This report includes correlated Plex request durations (~180–182 seconds), the recorded termination reason, telemetry (timeStalled=188), playlist polling/404s, and concat SIGKILL cleanup.
• HLS Alt/watermark behavior was also compared here.

Because the platforms, versions, and repeatability differ, I am treating #1727 as potentially related rather than asserting it is the same bug.

Additional Notes

• Human-readable outgoing/incoming program names could not be established from the retained excerpts and are intentionally not guessed.
• No relevant Tunarr ffmpeg-error-log-* file was generated in the strongest Standard HLS window; the outgoing transcode exited successfully.
• Channel 5 was verified restored to its production configuration: Standard HLS with watermark enabled.
• The existing Plex guide-refresh automation was not changed.

tunarr-standard-hls.log
plex-standard-hls.log
ffmpeg-client-excerpts.log
comparative-tests.md
environment.md