Random skipping in recordings

[ballfam]

I'm using a smart DNS (dns4me.net) to record Australian TV through IPTV from the U.S. with Matt Huisman's links, and I have been getting random skips and sync issues in the recordings for the past few months. Some recordings will be perfectly fine, but a few have started having an issue where the video skips a second or two forward, and occasionally, this causes the audio to go out-of-sync. I managed to fix the audio sync issue by running ffmpeg on the recording in PostProcessing, but I'm still left with these random skips. There seems to be no pattern to them, they happen across the board on about 10% or the recordings.

I suspect the stream may be dropping out because of either network issues or streaming issues at the server end (the broadcasting companies servers). I'm running on a very reliable fiber gigabit connection where the ping time to somewhere like Google is a constant 8ms and the download latency is a constant 14-15ms, and this is rock solid, the jitter is never more that a few ms on a 500meg download no matter what time of the day or night I test. But, of course, I'm a very long way from the actual streaming server; I didn't run a traceroute, but I suspect there are several hops between me and the actual streaming server, and any one of them could be causing delays. I'm also using a fast NVME drive, so I doubt it has anything to do with the disk I/O

As I remember, the smart DNS gets out of the way once the stream starts, so NextPVR would be streaming the data directly from the streaming server to my system, so it most likely is not an issue with the DNS.

Is there anything I can do to either debug this problem or mitigate the issues somehow? Since this is a live stream, and NextPVR can't go back in time and try again, I suspect I may have to just live with it if it's a networking glitch of some kind, but just wondering if anyone else has seen anything similar when streaming IPTV, and if they have any ideas about how to resolve it.

[mvallevand]

You forgot to mention the client and platform you are using there too many variable here. I'd like to see a sample that demonstrates the problem before you run post processing too.

Martin

[ballfam]

Thanks Martin. Client platform is Linux Mint (Ubuntu variant). It's not a VM, but actual real hardware. Next time it happens, I'll keep a copy of the pre-processed .ts file and send the link.

[mvallevand]

Kodi then? Wed need Kodi logs too and on Linux this can be an issue since playback is so variable

[ballfam]

Not Kodi. I am recording the live stream directly from https://i.mjh.nz (Matt's links for Australian TV which forward to the broadcasters streams). NextPVR generates a .ts file from this stream, and I'm pretty sure the actual .ts generated from the stream file has the skips in it. I have played back this file in several ways, all have the same results

• Just browse to my NextPVR server page from the Windows client running Chrome, and hit the "Play" button for the file directly from the "Recent Recordings" main page
  
• The file is also visible to my Plex server (but only after PostProcessing copies it). Playing it by either browsing to the Plex server from the same client, or running one of the many Plex Android/Android TV based clients and playing it from there
  
• Converting it to a .mkv in PostProcessing and playing that instead
  
• Converting it to a .mp4 in Plex optimize with "Original Version" setting (which just runs an ffmgeg remux in the background) and playing that
  

All versions in all players always skip in exactly the same place, which leads me to believe that the skip is present in the original .ts file generated by NextPVR. Basically, it just missed a few frames from the recording, but question is, was that a network dropout or something else?

As soon as I have a .ts file that confirms the issue, I'll send the link.

[mvallevand]

I understand the mjh feeds which by the way are not broadcast feeds but feeds designed to be played in a browser. There is no guarantee that they are reliable since browser can adjust to token changes etc. The timestamps don't even have to be valid since a) live tv might not be skippable in the browser or b) they skip by m3u8 segment and time not contents.

Since none of your test are using direct play so I still would like the sample file once you have it. If the problem is frequent enough you can turn on verbose mode logging and it captures which segments that are coming to see if the m3u8 stream is playing correctly.

Martin

[ballfam]

OK, thanks. I actually flip between the raw feeds and Kodi feeds from Matt's site. Most of the time I just use the raw feed (e.g. here: https://i.mjh.nz/au/Sydney/raw-tv.m3u8), but it doesn't seem to make much difference to NextPVR. I notice he changes these up once in a while, I guess because the broadcasters are changing links underneath. It has been working really well with no skips for several years, but over the last few months, I have been getting the odd file that skips.

I'll start by sending an example of a skipping file to see if there is anything to be gleaned from it. If there is nothing interesting, I'll enable verbose to see what I can get. BTW: I currently have DEBUG logging on by default.

[ballfam]

It happened last night. This is a recording of 9 News (channel 9 Australia) from last night. Around 7 minutes in, you should see that the picture freezes for a second or two, but the audio continues playing; this will happen 3 or 4 times between the 7 minute mark and the 9 minute mark.

This is typical of the kind of issue I'm seeing; sometimes this happens (video freezes and audio continues), sometimes the audio goes out-of-sync, and sometimes both video and audio are missing for a second or so and the whole thing skips forward.

It seems like it is happening often enough that I can enable verbose mode for a day if it helps.

https://drive.google.com/file/d/1blQVp3J...sp=sharing

[mvallevand]

I will have a look, you can leave verbose mode on, but you do have to catch the logs soon after the problem as the will roll faster too.

Martin

[mvallevand]

The stream itself seems not to be corrupt and the best effort timestamps seem ok but sparse but I clearly see the video issue your are talking about.

Deeper analysis seems to indicate many lost frames within the stream. Here is an example in the error you are talking about. Look at the video pts timestamps quite an odd timeline. Let's see what the verbose logs show.

Code:

[v01] Video has a gap of 14 frames at playtime 0:06:33.  <WARNING>
[v01] Video has a gap of 2113 frames at playtime 0:06:33.  <WARNING>
[v01] Video has a gap of 14 frames at playtime 0:06:45.  <WARNING>
[v01] Video has a gap of 2114 frames at playtime 0:06:45.  <WARNING>
[v01] Video has a gap of 14 frames at playtime 0:07:03.  <WARNING>
[v01] Video has a gap of 2113 frames at playtime 0:07:03.  <WARNING>
[v01] Video has a gap of 15 frames at playtime 0:07:15.  <WARNING>
[v01] Video has a gap of 2113 frames at playtime 0:07:15.  <WARNING>
[v01] Video has a gap of 14 frames at playtime 0:07:27.  <WARNING>
[v01] Video has a gap of 2114 frames at playtime 0:07:27.  <WARNING>
[v01] Video has a gap of 14 frames at playtime 0:07:39.  <WARNING>
[v01] Video has a gap of 2113 frames at playtime 0:07:39.  <WARNING>
[v01] Video has a gap of 14 frames at playtime 0:07:45.  <WARNING>
[v01] Video has a gap of 2114 frames at playtime 0:07:45.  <WARNING>
[v01] Video has a gap of 14 frames at playtime 0:07:51.  <WARNING>
[v01] Video has a gap of 2113 frames at playtime 0:07:51.  <WARNING>