Live playback glitches/freezes with Enigma2/GigaBlue MPEG-TS on port 8001, but recordings and port 8002 transcoding are fine

[tovdave]

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

1. Is this a known issue with certain MPEG-TS / Enigma2 streams in Channels live playback, including small glitches and short hangs/freezes?
2. Could extra audio/data PIDs in the raw TS stream be causing the HLS/remux path to choke?
3. Is there a way in Channels to ignore problematic extra streams and only use video + one audio track?
4. Would Channels generally be expected to be more sensitive than Emby/VLC to slightly messy TS streams?
5. 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!

[chDVRuser]

What is your Channels DVR custom source setting set to. HLS or MPEG-TS ?

It should match your source stream.
https://getchannels.com/docs/channels-dvr-server/how-to/custom-channels/#supported-streaming-formats

[tovdave]

Hello, I have selected MPEG-TS.

[chDVRuser]

What are the Channels Clients set to for Streaming Quality?
Settings > Playback > Streaming Quality
Try Streaming Quality: Original
and try both Original Quality Delivery: Direct and Stream

[tovdave]

Hi, I tested both the last 2 days and on both settings I have the same problems.

[chDVRuser]

Have you tried Show Stats in the client to look at the stats?

[tovdave]

Thanks, I will check the client stats and post the results.

One thing I am wondering about: could the problem be caused by extra tracks in the raw stream? For example, could additional audio tracks or non-primary streams such as teletext/subtitle/data streams be included and causing trouble for Channels during live playback?

[tmm1]

@tovdave

Channels starts an HLS live session / encoder, and I get messages like:

Why does this happen? If you're at home you should change your settings to avoid re-encoding.

@tovdave

One thing I am wondering about: could the problem be caused by extra tracks in the raw stream? For example, could additional audio tracks or non-primary streams such as teletext/subtitle/data streams be included and causing trouble for Channels during live playback?

Yes it could be

[tovdave]

Thx for ne answer, re-encoding is diabled.

My guess is that the issue is not necessarily that Channels does not support the other audio tracks themselves, but rather that the original TS stream likely contains additional tracks/streams, and at least one of them seems to have bad or missing timestamps.

That would explain the behavior I am seeing:

• the raw 8001 stream appears to include multiple PIDs/tracks, such as additional audio tracks, teletext, subtitles, or other data streams
• one of those extra streams may be malformed or have broken timestamps
• Channels seems to be more sensitive to that during live playback / remuxing
• the transcoded 8002 stream is probably much cleaner and simplified, which is why it plays fine

So my current theory is that the problem is not simply “unsupported audio tracks,” but rather a problematic extra stream in the original TS that is interfering with Channels during live playback.