Hi,
I am trying to use a GigaBlue UHD QUAD 4K PRO running OpenATV 7.6 as a source for Channels DVR.
My original source was a direct Enigma2/OpenWebif MPEG-TS stream from the box over port 8001.
What I am seeing
- Live playback in Channels sometimes has small picture errors / glitches
- It also has short freezes / hangs
- Recordings made by Channels are fine
- The exact same stream plays without issues in Emby
- The exact same stream also seems okay when played directly outside of Channels
- I see the issue on both Apple TV and Fire TV Cube
So the strange part is:
- the source stream seems generally okay
- recordings in Channels are okay
- only live playback through Channels shows the problem
Log messages I am seeing
Channels starts an HLS live session / encoder, and I get messages like:
[h264] mmco: unref short failure
[hls] Timestamps are unset in a packet for stream 5
[hls] Non-monotonous DTS in output stream 0:5
I also saw cases like:
[mpegts] Could not find codec parameters for some audio streams
At the same time, I do not see client-side buffer drops:
[SNR] Buffer statistics ... buf=0% drop=0%
I also tested HEVC transcoding in Channels, and the logs still seemed to point more to an input stream / timestamp / PID issue than to general bandwidth.
Important update
I then switched from the raw port 8001 stream to the transcoded stream on port 8002, and live playback now works well.
With port 8002:
- the glitches are gone
- the short freezes/hangs are gone
- playback is much more stable
So this makes me think the issue is related to the raw MPEG-TS stream from port 8001 and how Channels handles it in the live path, rather than a general network or client problem.
My questions
- Is this a known issue with certain MPEG-TS / Enigma2 streams in Channels live playback, including small glitches and short hangs/freezes?
- Could extra audio/data PIDs in the raw TS stream be causing the HLS/remux path to choke?
- Is there a way in Channels to ignore problematic extra streams and only use video + one audio track?
- Would Channels generally be expected to be more sensitive than Emby/VLC to slightly messy TS streams?
- Does the fact that port 8002 transcoding works well strongly suggest that the raw port 8001 TS stream is the real issue?
Setup summary
- Source box: GigaBlue UHD QUAD 4K PRO
- Image: OpenATV 7.6
- Original stream type: Enigma2/OpenWebif MPEG-TS over port 8001
- Working alternative: transcoded stream over port 8002
- Clients: Apple TV and Fire TV Cube
- Symptoms on port 8001: live glitches and short hangs, recordings okay
- Same stream in Emby: okay
- Port 8002 transcoded stream: stable
Example stream URL format
Raw stream:
http://<user>:<password>@<box-ip>:8001/<service-reference>
Transcoded stream:
http://<user>:<password>@<box-ip>:8002/<service-reference>
Any ideas would be appreciated. If needed, I can also post a longer log excerpt.
Thanks!
