playback hiccups

[Allan]

I am trying to figure out the cause of playback hiccups on my system. 

They look like momentary signal loss, but it is happening on local channels, and I have watched a signal meter and it looks like the signal quality is excellent and steady.

Accordingly, I wonder if it may have something to do with writing to storage. My recordings are written to a USB3 external hard drive. Is there any kind of buffer that receives the data before writing to disk? Is it configurable?

[sub]

Is it a playback or recording problem?

Ultimately .NET and your filesystem are taking care of the bulk of the buffering, and it'd be unlikely it's not able to keep up writing the files.

Have you tried playing the recording in a different player to see if there is problems in the same spot?

[Allan]

100% its recording issue. the hiccups are the same, no matter how (or how many times) you watch the recording.

It's not impossible that it could be a reception issue, but it would be surprising. 

I am attaching the log of a sample recording (22:59 to 23:40) if you have time to look at it for clues.

[mvallevand]

The only way to tell this is to provide a sample via an exernally sourced link. However you didn't note the client so as sub says also try a different client.

Martin

[sub]

Yeah, we'll need a sample recording to look at.

[Allan]

The only way to tell this is to provide a sample via an exernally sourced link.  However you didn't note the client so as sub says also try a different client.

Martin

I initially watched with the LG client. I subsequently watched by other means, including VLC locally on the computer running the backend. It's 100% the recording. 

The first 2 minutes of the recording, which includes a hiccup just after 1:10 is here: https://limewire.com/d/lrErt#nh8EGszECP

The entire recording is 5.5 GB, which can also be made available.

[sub]

I can see that behaviour at that spot you mention.

Oddly, there are no Continuity errors, CRC errors, or TEI errors in the file, so there is no indication of any missing or damaged packets. It's almost like we've got everything that was sent, but maybe it's just got some odd timestamps on the broadcast data at that point.

Do you ever see it on other channels?

Ultimately, other than NextPVR doing simple collecting of packets until we've got a 64k chunk ready to write, the main buffering is provided by .NET and your file system, and applications are not expected to provide further buffering these days. That stuff around filesystem reliability is provided elsewhere, because applications will never do it as well as the filesystem guys can.

[mvallevand]

I played it with my future update to yauiclient and the log clearly show two errors in that file that I saw.

Code:

2026-03-12 15:20:07.266 T:15020 [DEBUG] [mpv/cplayer] VO: Description: render API for libmpv [LibmpvPlayer-Event]
2026-03-12 15:20:07.277 T:15020 [DEBUG] [mpv/cplayer] first video frame after restart shown [LibmpvPlayer-Event]
2026-03-12 15:20:07.339 T:15020 [DEBUG] [mpv/cplayer] audio ready [LibmpvPlayer-Event]
2026-03-12 15:20:07.339 T:15020 [DEBUG] [mpv/cplayer] starting audio playback [LibmpvPlayer-Event]
2026-03-12 15:20:07.339 T:15020 [DEBUG] [mpv/cplayer] starting video playback [LibmpvPlayer-Event]
2026-03-12 15:20:07.340 T:15020 [DEBUG] [mpv/cplayer] playback restart complete @ 0.359456, audio=playing, video=playing [LibmpvPlayer-Event]
2026-03-12 15:20:55.298 T:15020 [DEBUG] [mpv/ad] Error decoding audio. [LibmpvPlayer-Event]
2026-03-12 15:20:55.326 T:15020 [DEBUG] [mpv/ad] Invalid audio PTS: 48.631467 -> 49.495467 [LibmpvPlayer-Event]
2026-03-12 15:20:55.355 T:15020 [DEBUG] [mpv/cplayer]  [LibmpvPlayer-Event]
2026-03-12 15:20:55.356 T:15020 [DEBUG] [mpv/cplayer]  [LibmpvPlayer-Event]
2026-03-12 15:20:55.356 T:15020 [DEBUG] [mpv/cplayer] Audio/Video desynchronisation detected! Possible reasons include too slow [LibmpvPlayer-Event]
2026-03-12 15:20:55.356 T:15020 [DEBUG] [mpv/cplayer] Consider trying `--profile=fast` and/or `--hwdec=auto` as they may help. [LibmpvPlayer-Event]
2026-03-12 15:20:55.356 T:15020 [DEBUG] [mpv/cplayer] hardware, temporary CPU spikes, broken drivers, and broken files. Audio [LibmpvPlayer-Event]
2026-03-12 15:20:55.356 T:15020 [DEBUG] [mpv/cplayer] position will not match to the video (see A-V status field). [LibmpvPlayer-Event]
2026-03-12 15:21:19.997 T:15020 [DEBUG] [mpv/ad] Error decoding audio. [LibmpvPlayer-Event]
2026-03-12 15:21:20.030 T:15020 [DEBUG] [mpv/ad] Invalid audio PTS: 74.231467 -> 74.839467 [LibmpvPlayer-Event]
2026-03-12 15:21:34.719 T:15020 [DEBUG] [mpv/ad] Uninit decoder. [LibmpvPlayer-Event]
2026-03-12 15:21:34.719 T:15020 [DEBUG] [mpv/cplayer] EOF code: 4   [LibmpvPlayer-Event]

Martin

[sub]

Interesting those both mention invalid PTS timestamps, like I mentioned as possibility.

[Allan]

I can see that behaviour at that spot you mention.

Oddly, there are no Continuity errors, CRC errors, or TEI errors in the file, so there is no indication of any missing or damaged packets. It's almost like we've got everything that was sent, but maybe it's just got some odd timestamps on the broadcast data at that point.

Do you ever see it on other channels?

Ultimately, other than NextPVR doing simple collecting of packets until we've got a 64k chunk ready to write, the main buffering is provided by .NET and your file system, and applications are not expected to provide further buffering these days. That stuff around filesystem reliability is provided elsewhere, because applications will never do it as well as the filesystem guys can.

In case the app I used to trim the file modified something, I have also uploaded the same data that I simply cut up with the split command in terminal. Here it is: https://limewire.com/d/bTeOi#sW5vbDYUul

I see blips on other channels. I record mostly on this local channel and a non local channel that is less surprising to see a momentary signal issue. I will try another local channel later and see what happens.

The only ideas I have are signal, hard drive and network. Network also seems unlikely (cat 6 wiring, GB ethernet).