@eric i was wondering if you might have time to look at this whenever you get a min?
My best guess is that the device just can’t keep up with VP9 decoding on the CPU.
Have you found any other Apple TV apps that perform better than Channels at VP9? I would guess we all use the same VP9 software decoder.
Oh yeah vlc works perfectly, no issues whatsoever. Its just channels that has the issue.
And pretty sure IINA uses MPV.
Meaning your vlc-bridge transcodes the VP9 source to H.264 for output to Channels?
Nah its native vp9. No transcoding.
Ah, OK. I just don't understand what you mean by "When I configure the same source for H264 it works fine with Channels."
Same Channels DVR source, or same vlc-bridge source?
What are you using as your VP9 encoder?
You’re saying you’ve pointed IINA at the DVR stream.mpg for this VP9 stream and it doesn’t present the issues after long playback?
I'm not encoding its VP9 passthrough from my source, remuxed via ffmpeg to MPEG-TS/hls with the -c copy switch. not doing any re-encoding at all.
from the source (bypassing cdvr) works perfect (as well as VLC)
MPEG-TS or fMP4?
outputting hls with mpeg-ts segments (-f hls -c copy) not fmp4.
Are you using the ffmpeg that is bundled with the DVR or your own?
I checked your logs from the latest diagnostics and it looks like ffmpeg is actually outputting fMP4 segments, not MPEG-TS.
Could you record 1 minute off of that channel, then submit diagnostics again?
Please upload the recording to: https://www.dropbox.com/request/MMjICRc053JJpSBPDIfQ
I'm wrong, you are right it is fmp4. Im using my own ffmpeg to remux the VP9 stream into HLS. I just tried to do a test recording and it looks like I'm generating a panic every time I try...
just submitted logs as well 83305b60-d4df-40e4-928d-e967d9d44f35
2026/04/21 05:01:07 [Recovery] 2026/04/21 - 05:01:07 panic recovered:
runtime error: invalid memory address or nil pointer dereference
runtime/panic.go:336 (0x4936b7)
runtime/signal_unix.go:931 (0x493685)
github.com/fancybits/channels-server/hls/media_stream.go:479 (0x12d2bf9)
github.com/fancybits/channels-server/hls/reader.go:444 (0x12e6946)
github.com/fancybits/channels-server/tuner/stream.go:582 (0x1314af9)
github.com/fancybits/channels-server/tuner/stream.go:446 (0x1313ca4)
io/io.go:429 (0x4a8d2f)
io/io.go:388 (0x27f05a4)
github.com/fancybits/channels-server/http_device.go:800 (0x27f0105)
github.com/fancybits/channels-server/http_device.go:809 (0x27ee6c8)
github.com/gin-gonic/[email protected]/context.go:192 (0x1850d8d)
github.com/fancybits/channels-server/http_device.go:112 (0x2771fee)
github.com/gin-gonic/[email protected]/context.go:192 (0x1850d8d)
github.com/fancybits/channels-server/http.go:420 (0x2761613)
github.com/gin-gonic/[email protected]/context.go:192 (0x1850d8d)
github.com/fancybits/channels-server/http.go:397 (0x27612cf)
github.com/gin-gonic/[email protected]/context.go:192 (0x1850d8d)
github.com/fancybits/channels-server/http.go:372 (0x2760fa7)
github.com/gin-gonic/[email protected]/context.go:192 (0x1850d8d)
github.com/fancybits/channels-server/http.go:334 (0x2760348)
github.com/gin-gonic/[email protected]/context.go:192 (0x1850d8d)
github.com/gin-gonic/[email protected]/recovery.go:101 (0x185fa30)
github.com/gin-gonic/[email protected]/context.go:192 (0x1850d8d)
github.com/gin-gonic/[email protected]/logger.go:249 (0x185eb49)
github.com/gin-gonic/[email protected]/context.go:192 (0x1850d8d)
github.com/gin-contrib/[email protected]/sessions.go:54 (0x27645c4)
github.com/gin-gonic/[email protected]/context.go:192 (0x1850d8d)
github.com/fancybits/channels-server/http.go:596 (0x27feeae)
github.com/gin-gonic/[email protected]/context.go:192 (0x1850d8d)
github.com/gin-gonic/[email protected]/gin.go:689 (0x185db7d)
github.com/gin-gonic/[email protected]/gin.go:643 (0x185d52c)
net/http/server.go:3311 (0x77f4ed)
net/http/server.go:2073 (0x75de6f)
runtime/asm_amd64.s:1771 (0x498de0)
This should fix that panic. Still working on the underlying issue.
Let me know if this latest pre-release fixes the issues you're seeing with the VP9 frame rate.
@eric I just tried to redo the test and it looks like i am getting a different panic this time
2026/04/21 17:13:23.713276 stderr: panic: runtime error: invalid memory address or nil pointer dereference
2026/04/21 17:13:23.713380 stderr: [signal SIGSEGV: segmentation violation code=0x1 addr=0x98 pc=0x12d1391]
2026/04/21 17:13:23.713398 stderr:
2026/04/21 17:13:23.713413 stderr: goroutine 717 [running]:
2026/04/21 17:13:23.713434 stderr: github.com/grafov/m3u8.(*MediaPlaylist).Close(...)
2026/04/21 17:13:23.713455 stderr: github.com/grafov/[email protected]/writer.go:736
submitted logs 5a939b72-fa5f-449f-855f-9e7ece35b710
Okay, I think we did finally fix the crash — we weren't expecting an empty caption playlist and didn't handle it properly.
I just uploaded a test recording. It starts off fine and then goes south about half way in
@slampman could you submit diagnostics from your DVR so we have those logs to go along with the recording?
Additionally, if you could save a .zip of the output of the HLS segments on disk that could be really helpful (if you could do it of the segments that made it into a recording, that would be amazing, but even separately, it could be helpful).
1 Like
I think i can do this. Let me try to capture everything end to end with diagnotics. I'll work on this tonight or tomorrow.
1 Like
OK I think i got everything. I uploaded a tar.gz containing the raw segments as well as a test recording from Channels to your dropbox link. I also submitted diagnostics afterwards. The recording shows it really messing up so hopefully it is useful 