DVBViewer HLS Downloads fragment multiple times

[SuppaMan]

Hi!
I have a private HLS stream that works fine with all players (web based, android and ffmpeg). In DVBViewer, however, the stream stops and play in loop, jumping from a point to other.
Inspecting the log, DVBViewer download (and play, I assume) already downloaded fragments, unlike other streams in which fragments are correctly downloaded once. I attach a filtered example:

09.04.22 15:33:52.378 TBaseHTTPStream Connecting to https://example.com/hls/stream.m3u8
09.04.22 15:33:52.472 THLSStream Connecting to https://example.com/hls/stream-1635.ts
09.04.22 15:33:52.603 THLSStream Connecting to https://example.com/hls/stream-1636.ts
09.04.22 15:33:52.632 THLSStream Connecting to https://example.com/hls/stream-1637.ts
09.04.22 15:33:52.663 THLSStream Connecting to https://example.com/hls/stream-1638.ts
09.04.22 15:33:58.602 TBaseHTTPStream Connecting to https://example.com/hls/stream.m3u8
09.04.22 15:33:58.698 THLSStream Connecting to https://example.com/hls/stream-1636.ts
09.04.22 15:33:58.838 THLSStream Connecting to https://example.com/hls/stream-1637.ts
09.04.22 15:33:58.869 THLSStream Connecting to https://example.com/hls/stream-1638.ts
09.04.22 15:33:58.970 THLSStream Connecting to https://example.com/hls/stream-1639.ts
09.04.22 15:34:04.833 TBaseHTTPStream Connecting to https://example.com/hls/stream.m3u8
09.04.22 15:34:04.923 THLSStream Connecting to https://example.com/hls/stream-1636.ts
09.04.22 15:34:05.076 THLSStream Connecting to https://example.com/hls/stream-1637.ts
09.04.22 15:34:05.106 THLSStream Connecting to https://example.com/hls/stream-1638.ts
09.04.22 15:34:05.180 THLSStream Connecting to https://example.com/hls/stream-1639.ts
09.04.22 15:34:05.390 THLSStream Connecting to https://example.com/hls/stream-1640.ts

 

I also noticed these line that occurs every redownload of the master playlist:

09.04.22 16:24:46.933 TFileDevice CheckAutoRetune Retuning TS Stream Device
09.04.22 16:24:46.941 TFileDevice StopDevice
09.04.22 16:24:46.941 TFileDevice CloseDevice
09.04.22 16:24:55.221 TFileDevice CheckAutoRetune Retuning TS Stream Device
09.04.22 16:24:55.238 TFileDevice StopDevice
09.04.22 16:24:55.238 TFileDevice CloseDevice
09.04.22 16:25:03.540 TFileDevice CheckAutoRetune Retuning TS Stream Device
09.04.22 16:25:03.556 TFileDevice StopDevice
09.04.22 16:25:03.556 TFileDevice CloseDevice

 

Can anyone help me figuring out this?

[Griga]

For analyzing this I need the m3u8 URL (for receiving the stream myself) or at least the TransEdit debug output (see here, "HTTP Debug Version" section). You can send me a PM, if you don't want to post it publicly.

 

[SuppaMan]

You have a PM

[Griga]

Ok, got it. The stream contains corrupted time stamps, or more precisely, a corrupted PCR (Program Clock Reference, the broadcasted time base for video/audio timing). It's not increasing monotonically, as it should be. That's why the DVBViewer Filter (DVBSource) repeatedly sends PCR/PTS Gap error messages to the host application (DVBViewer), which in return tries to clear the whole thing by stopping and restarting playback. You can see it on the DVBViewer Filter Property Page. It's a consequence of "Check Timestamp Continuity" being ticked.

 

The best way to fix it is to tick "Remove clock reference" in the DVBViewer Channel Editor for the channel in question. It lets DVBViewer simply remove the erroneous PCR, thus forcing the DVBViewer Filter to use the audio PTS (Presentation Time Stamps) as substitute time base, which seems to be ok. With this setting the stream plays continuously here.

 

[SuppaMan]

The fix is working perfectly, thank you very much!
Next I'll try to fix the source stream problem, but for now it's ok