Stuttering and glitching

Hi Sam,

This is a continuation from the topic Unstable vero5, random reboots, crashes, freezes? Replace power supply! - #26 by sam_nazarko

I followed your suggestions, no change, still stutters, again regardless of file.

I also did a bandwidth test against the mount
osmc@verov:/tmp$ dd if=/mnt/tyrellcorp_movies/Barry.Lyndon.1975.CC.iNTERNAL.BluRay.2160p.UHD.REMUX.HEVC.10bit.DV.DTS-HD.MA.5.1-Aisha.mkv of=/dev/null bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB, 1000 MiB) copied, 8.06117 s, 130 MB/s

Again, the Apple TV has no issue playing the same files.

Whenever glitching occurs, this appears in the logs. Here’s an example of a number of glitches happening in a short space of time:

2025-08-04 12:28:27.616 T:3210 debug : CPtsTracker: detected pattern of length 1: 41701.03, frameduration: 41708.333333
2025-08-04 12:28:28.615 T:3210 debug : CPtsTracker: pattern lost on diff 166884.000000, number of losses 3
2025-08-04 12:28:37.197 T:3210 debug : CPtsTracker: detected pattern of length 1: 41712.03, frameduration: 41708.333333
2025-08-04 12:28:43.709 T:3210 debug : CPtsTracker: pattern lost on diff 167108.000000, number of losses 4
2025-08-04 12:28:50.797 T:3210 debug : CPtsTracker: detected pattern of length 1: 41708.33, frameduration: 41708.333333
2025-08-04 12:29:07.688 T:3210 debug : CPtsTracker: pattern lost on diff 417732.000000, number of losses 5
2025-08-04 12:29:13.068 T:3210 debug : CPtsTracker: detected pattern of length 1: 41708.33, frameduration: 41708.333333
2025-08-04 12:29:20.496 T:3210 debug : CPtsTracker: pattern lost on diff 208720.000000, number of losses 6
2025-08-04 12:29:26.458 T:3210 debug : CPtsTracker: detected pattern of length 1: 41708.33, frameduration: 41708.333333
2025-08-04 12:29:36.696 T:3210 debug : CPtsTracker: pattern lost on diff 250100.000000, number of losses 7
2025-08-04 12:29:41.969 T:3210 debug : CPtsTracker: detected pattern of length 1: 41708.33, frameduration: 41708.333333
2025-08-04 12:29:44.122 T:3210 debug : CPtsTracker: pattern lost on diff 167000.000000, number of losses 8
2025-08-04 12:29:49.269 T:3210 debug : CPtsTracker: detected pattern of length 1: 41708.33, frameduration: 41708.333333
2025-08-04 12:29:51.842 T:3210 debug : CPtsTracker: pattern lost on diff 167000.000000, number of losses 9

Mounting via fstab / nfs. Tried protocol 3,4,4.1 and upping caching, size of blocks etc. Zero difference. Have also restarted Synology NAS.

Also, when the glitching occurs - the video intermittently pauses, but the audio continues perfectly.

Edit: Just had severe video and audio glitching, the audio cut out and flashes of colours on the screen.

I just re-installed OSMC, which was a PITA, and the problem persists. Man. I just don’t understand what’s going on.

Is it possible that there’s a hardware issue? It’s fair to say that I live on this thing - not having it working affects me greatly, so I’m simply prepared to buy a new one if that will fix it.

I have had a look into the full log in the previous thread before this here was splitted:

...
Aug 03 13:18:35.021417 verov kernel: EARC fe333800.earc: HDMITX cable is plugin
...
Aug 03 13:18:40.100875 verov kernel: EARC fe333800.earc: HDMITX cable is plugout
...
Aug 03 13:18:40.718059 verov kernel: EARC fe333800.earc: HDMITX cable is plugin
...
Aug 03 13:18:40.935543 verov kernel: EARC fe333800.earc: HDMITX cable is plugout
...
Aug 03 13:18:41.621962 verov kernel: EARC fe333800.earc: HDMITX cable is plugin
...

This is unusual to see such messages. Is there any chance that you connect the VeroV just for tests to another device like a TV using another HDMI cable?

Thanks Jim. Yes, I should try your suggestion to see if that helps isolate the problem.

1 Like

This will cause problems for sure. Good spot.

Egads, I think I’ve found the issue.

I was using NFS mounts at the OS level (/etc/fstab). I have now switched to mounting via SMB through the OSMC interface and it’s behaving itself.

I am not sure why this is the case - I have been using NFS without issue until recently.

Let’s keep an eye on things – you shouldn’t have those constant HDMI in/out messages

Sam

FYI - Some interesting things trying different ways to get to the NAS:

  1. Added the SMB mounts in fstab and used them from the local file system /mnt points (as I used to do with NFS) - immediately glitches returned
  2. Mounted the NFS shares directly - immediate glitches
  3. Returned to mounting SMB shares directly - no glitches

So NFS doesn’t reliably work anymore at all, and SMB only reliably works if mounted directly from OSMC and not via fstab /mnt points.

This was also true if I moved the Vero V to the TV in the lounge, so I don’t think HDMI is the culprit.

I’m tentatively OK with the current setup, but something has clearly changed recently which makes me a bit nervous.

Likewise. I’d check the NAS.

Have you tried playback from local storage or an attached USB drive?

I bought a new Vero V, and everything is as it should be again running off fstab mounted NFS shares. Rock-solid playback and just overall it feels solid. I could tell the difference immediately.

I have no problems buying a new one. I also do not blame one for going bad - I have a suspicion that it was slowly cooked over time by being placed on a glass shelf directly above an extremely hot Cambridge Azur amplifier. Seriously the heat this thing belts out is ridiculous - but the sound quality makes it worth it :crazy_face:

Thank you Sam for your attention to people’s issues and always making time.

I’d be surprised if you’ve cooked the device… it wouldn’t explain why one protocol works and one doesn’t for starters.

Why not update the working device to the latest version of OSMC, reinstall OSMC from scratch on the other device and restore a backup from the working device to the newly formatted (but older) device and see how things go? I know you’ve already reinstalled… but one final time could be useful.

Sam

1 Like