If not, then it still would be really weird that a video file causes the Vero to freeze and get unresponsive, just like these guys here with wifi.
But I am already testing further today and tomorrow and will share the outcome. Then Ill be on leave for a week before I can try further <3
Did some more testing today:
I set the VeroV to log the output of nfsiostat every 5 seconds while playing 2 different source media. One was a 2160p web rip that was downloaded and the other a full UHD rip which is known to freeze this VeroV. The web rip is of course compressed, so less data and a file size about 1/8 of a full UHD rip.
The web rip did play all the way through, the UHD rip lasted longer than usual (many times the freeze happens within minutes) but it eventuallt froze.
See: https://chrissmith.org/files/nfsio.tar.bz2
There are two files in the above tar. One is the nfsiostat of the web rip - nfsio_web.log (which didnāt freeze), and the other of UHD rip - nfsio_rip.log, which did.freeze. Note that the last line in nfsio_rip.log is when the freeze occured (the header was written but not the data).
The data being transferred is about twice as much for the UHD rip than for the web rip. Also near the end, before the freeze we start seeing 15 re-transmits for every request.
Not sure if this will help but itās another piece of the puzzle.
Chris
Didnt experience the problem yet again with some other episodes or movies so farā¦ maybe its the file itself, causing the Vero to get stuck, instead of just stopping the playbackā¦
Again ā the users reporting an issue here are using WiFi; not Ethernet, so the problem you reported isnāt related. It sounds like a problematic file.
Iāve grabbed the latest driver from the AMLogic Git repositories; updating from version:
#define DRIVERVERSION āv5.14.0.2-0-g4c549b2.20210914_COEX20230106-1700-FiexDPPā
to
DRIVERVERSION āv5.14.0.2-0-g4c549b2.20210914_COEX20230106-1700-20240507ā
Iāve compile tested the driver, but not had a chance to look for significant regressions or perform major tests yet.
You can test the new driver by updating to the staging repository. Please note that doing so will update your device to Kodi v21 however.
To test this update:
- Login via the command line
- Run the following command to add the staging repository:
echo 'deb http://apt.osmc.tv bullseye-devel main' | sudo tee /etc/apt/sources.list.d/osmc-devel.list - Run the following commands to update:
sudo apt-get update && sudo apt-get dist-upgrade && reboot - Your system should have have received the update.
Please see if the issue is resolved.
I also recommend you remove /etc/apt/sources.list.d/osmc-devel.list after updating.
This will deactivate the staging repository. You can do so with the following command:
sudo rm /etc/apt/sources.list.d/osmc-devel.list.
Please note that we will automatically disable this update channel after 14 days on your device in case you forget to do so to ensure that your system reverts to the stable update channel.
Sorry to report that that does not resolve the issue.
Same symptoms, frozen video, no response to remote, no reponse via network (ssh, ping).
I didnāt run it with logging enable, can do that tomorrow if you would like.
A log would be great to check that your device is up to date.
At this point though we could consider swapping the device out to save you time.
Itās still behaving the same way. Workaround with the speed limiter on the router also works.
This morning I set up logging and had the typical freeze within minutes but for some reason the new kernel log was not written.
After rebooting and starting the playback I got a slightly different symptom. The video froze with Bufferingā¦ displayed and the logging display still showed some activity even though the Vero did not respond to network activity (ping or ssh). It did possible respond to the remote as once I hit a button the logging display froze.
Log at: https://paste.osmc.tv/xilubudiyi
This log is useful, I can see the problem now.
Thatās great. Iāll hold off on a swap for a bit if you think a fix is in the works.
Sam,
Hereās another log for you.
I updated the staging-repository, same freeze, but it looks like some info was logged.
https://paste.osmc.tv/puwamawalo
Any update on a possible fix? Or is it time to swap this puppy out (it sill has that delay in response every so often when Iām shelled in)?
Chris
Will give you an update shortly.
I now have a conclusion, will give you one more thing to test shorty and explain my findings.
Iām building a potential solution now. From your logs it looks like a memory allocation problem.
I look forward to testing it.
However my suspicions are that this unit is somehow defective.
My concerns are:
- the fact that you havenāt been able to recreate the issue
- this unit still has those random hesitations when Iām shelled in (even when not playing any media) - Iāll be shelled in and suddenly the data I type is not echoed, then a few seconds later it appears and the terminal becomes responsive again until the next hesitation. Again, I donāt have to be doing anything else, no playing of media, etc. The Vero 4k+'s (2) I have never had those issues.
You are welcome to swap the device over then, thatās fine. If you were the only user reporting this issue, Iād suspect a hardware fault.
It could be faulty memory (and that the WiFi driver) is triggering a stall when trying to allocate a chunk of it.
Sam
If your upcoming next potential solution doesnāt fix it, weāll swap it out.
