Random skipping in recordings

[ballfam]

Thanks Martin....Maybe those missing frames are just lost network packets from the live stream, which was my initial suspicion, although I'm not sure why it started happening recently. I'll enable verbose and see if I can catch it.

[mvallevand]

If there were lost packets continuity counters and sync bytes should be off (assuming this is the raw ts that NextPVR recorded.

Martin

[ballfam]

OK, I caught one. Links to log file and .ts recording below. In the case it is 9New Australia (again).

The recording starts around "2024-04-08 00:58" local time in the log. I noticed that it is starting 2 recordings at the same time; both Seven News and 9News broadcast opposite each other, and I record them both simultaneously. There are missing frames (picture freezes) from about 20-30 seconds in. I'm not sure if it is connected, but the problem seems to happen largely when I am making 2 recordings at the same time. I don't see much in the log between the start time and 02:10, when the recording ends, after it is done, there are several "frame" messages, but it seems strange they are logged after the rerecording has finished. This is my current log setting, not 100% certain it is correct:

<LogLevel>VERBOSE</LogLevel>

I restarted NextPVR after updating config.xml

If you can glean anything useful from the logs, it would be much appreciated.

Recording: https://drive.google.com/file/d/11myGOFH...sp=sharing
nrecord.log: https://drive.google.com/file/d/1H_bixrf...sp=sharing

[ballfam]

BTW: the "Seven News" recording from exactly the same time does not have any issues, it plays back perfectly.

[mvallevand]

Unfortunately I don't see any verbose log messages. I am not sure you can do it via config.xml, you have to enable it with the Ctrl click on logs or with an environment variable. NEXTPVR_FLUSH=true

Martin

[ballfam]

I suspected something like that.....OK, let's try again with real verbose logging, and I'll upload again.

[ballfam]

OK, got one with verbose. The recording of "9News Late" just finished about 20 mins ago. Here it skips much less, the first one seems to happen around 7 minutes in. There is an overlapping recording of "The Latest 7 News" which starts around that time also. Look for a timestamp of "05:50:23" in nrecord.log.1. As you said, the logs roll over quickly, there is also some reference to this recording rolling over into nrecord.log. The recording finishes around "06:30" local time.

nrecord.log.1: https://drive.google.com/file/d/1wet8-8x...sp=sharing
nrecord.log: https://drive.google.com/file/d/1uJm0jWT...sp=sharing
9News.Late.S2024E72.ts: https://drive.google.com/file/d/1nPYTv23...sp=sharing

[ballfam]

I notice quite frequently on the frame messages that speed is less than 1.0; usually between 0.9 and 1.0, but can drop into the 0.8 range. Is that related? If so, what causes it an how do I fix it? I don't really know how to read these logs, so I'm just guessing.

[mvallevand]

So what I see ffmpeg is creating the ts file so any issues would have to be directed to the ffmpeg support. To be fair your Linux is using an old version of ffmpeg 4.2.7 which is now 3 versions behind so you probably won't get any support.

The missing frames can be explained by these messages "skipping 1 segments ahead, expired from playlists"

You don't seem to be getting 25 fps or near 1x recording either which might explain why it has to drop frames. ffmpeg even seems to use two different hls streams trying to adapt which will make a bad ts file.

Also the fact that ffmpeg is building the ts file explains whey there are no continuity errors it is not a direct stream copy.

I don't know if there is a way to force NextPVR to ask ffmpeg to use a low bitrate stream or not.

Martin

[ballfam]

OK, thanks Martin. This helps. It might be no coincidence that this only seems to happen when I am trying to record multiple streams at the same time.

I have been meaning to update my system for a long time, but the fact that it is always in use make it difficult to find a downtime window. I think I may need to bite the bullet and do a full upgrade to the latest version and update ffmgeg in the process.

I'm already using the lower 720p stream that Matt provides; there is a 520p stream, but I don't think Matt supports it, I'll run a streamlink on the web link to see what streams it supports. Talking of which, is there any way to ask NextPVR to use streamlink instead of ffmpeg? I'm guessing I can create an extra to tell it what to do; although I'm not sure it will help; streamlink is probably not any more efficient than ffmpeg.

Can you determine what is causing the less than 1.0 speed? Is it an issue getting the network packets, or an issue with ffmpeg processing the stream and writing it to disk? The latter might be solved by lessening the load on the machine.

If it's a processing/writing issue, is there anyway to force ffmpeg to use a really large buffer so that it does't need to drop the frames?