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.
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.
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!)
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?