Vero 4k crashes when playing The Commuter UHD Remux

Hi there,

Experiencing an issue whereby Vero 4k stalls at a specific point in time (~1hr 10seconds) into a UHD MKV rip of The Commuter. The video basically freezes at the same exact timestamp with audio carrying on for a few seconds, but then I ultimately see a black screen and the Vero returns back to the file explorer.

Debug logs here: https://paste.osmc.tv/aliqobomow

The file has a video bit rate of 58.6Mb/s, so shouldn’t be too taxing for the Vero 4k. I can play this file over 5Ghz Wifi on my Macbook Pro (using iiNA and it works without hitches at the part where Vero freezes, so the file itself is fine.

Note I also experienced a very similar issue with a UHD remux of The Martian (Vero was freezing at a specific timestamp despite the file working on other devices), so suspect there is some issue with the way the files are being read. When this issue occurs, Kodi’s debug overlay shows that the read buffer falls to 0 B and doesn’t come back up FWIW.

The files are mounted via fstab / SMB and read over Wifi (iperf shows ~150Mb/s between the Vero and my source). Unfortunately I am still waiting on a HDD before I can test whether a direct mount fixes the issue, but given iperf’s result I don’t think it’s bandwidth related.

Vero 4k is running on the April update, though this was also happening with the previous March release (when I got the device). I’ve tried playing around with advancedsettings.xml to test different buffer levels but that doesn’t seem to resolve the issue.

Assistance appreciated!

Definitely 1hr 10sec?

Just tried playing my copy. Not remuxed it yet but playing the m2ts file and it plays past 01:00:10 without a problem.

However I am on wired and using an fstab mounted nfs share. Will mux to mkv next and check again.

Thanks Mevlock.

Yes, it’s they bit when the guitar player is chasing Liam right after he asks him to open them guitar case. As soon as Liam turns around it freezes on his face.

Thanks, that would be great.
I’m guessing my logs don’t reveal anything too telling?

Given I’ve had this issue occur on multiple files, I’m wondering if there is something amiss with my particular set up. I’ve tried clean installing OSMC but no luck.

Can you upload a sample here?

Mkv works fine for me too. Oh and I’m using gigabit usb adapter too.

I created a 1min sample using MKVToolNix and uploaded it to that directory. What’s weird is the sample file plays properly on the Vero now, however there is a strange stutter at the exact spot where the full file was locking up at (33s mark in the sample file).

When I created the sample, MKVToolNix issued the following warning which corresponds with the timestamp of the affected area so maybe Vero’s error handling when reading files is the culprit? Warning below:

Error in the Matroska file structure at position 29073049782. Resyncing to the next level 1 element.
The last timestamp processed before the error was encountered was 01:00:33.668000000.
Resyncing successful at position 29076553800.
The first cluster timestamp after the resync is 01:00:34.214000000.

I can play the sample using iiNA on my Mac and it plays the 33s mark a little smoother than the Vero FWIW. Also as per my original post iiNA plays the full file without issues whereas the Vero locks up at that timestamp.

Thanks for checking, appreciate it. I’m keen on hardwiring too in order to see if that solves the issue but will have to wait for my HDD to arrive (ordered from overseas Amazon, which takes a while to get to me!)

Thanks for the upload, that’s great.

I wonder if your rip is corrupt / problematic.

Sam

No probs. Let me know if I can do anything else to help.
A problematic rip is what I had originally thought, but as per my latest post above it’s odd that Vero plays the short sample and that other players handle the full file without issues, isn’t it?

We may be able to improve the playback situation, but if there’s something wrong with the file, it’s likely it will trip up many hardware decoders.

I’ll keep you posted.

Sam

Makes sense. Thanks @sam_nazarko, appreciate the quick responses.