The log set includes both the log of the crash/freeze - kodi.old.log - and the log after the reboot - kodi.log (which has no bearing as it is not the log when the crash happened but logging cannot be turned off until the system is rebooted and the “grab-logs -A” script uploads both logs).
It can be clearly seen (kodi.old.log) that on 5-20-2024, at, or immediatley after, 11:30:05.533 [EDT] the Vero V was no longer operational.
When I realized the system had stopped working I rebooted, verified by the start of kodi.log at around 11:35:43 [EDT].
I have seen many of these logs, and when the system freezes is cannot write to the log files, no matter how many of them or how they are named.
You still haven’t provided any technidcal proof that “persistent logging” would supply any new information in this regard.
If you create a journal directory at /var/log the journal/kernel log information will be stored there and by that becomes persistent. Currently this information gets lost on any new boot and so we do not know what happened before this freeze/crash. With some luck there will be some information about a crash if that happened at all.
Is that a different archtecture than the Vero 4k+'s that work flawlessly?
Also I never autoupdate the library, I do it manually only when I’ve made changes and wait for the scan to stop; maybe 5 file adds in a week. The library database is not local it’s via a mariadb on the network. Why would local storage be stressed under these conditions?
Fresh installation. Problem not resolved.
Still pausing when shelled in, also sometimes remote button pushes are ignored (might be same pausing issue).
Here’s the debug logs: https://paste.osmc.tv/yazalewolo
No, I meant when I was setting up the new install the Vero V was doing the same thing as previously - arbitraily slow to respond to keyboard input at times. As well as not always respomding to the remote.
It’s a full freeze/crash during playback; no ping, no shell, no remote. The logs were sent after the power cycle reboot after the crash.
I picked up a 100ft cat 6 cable and laid it across the floor to connect to the Vero V. It played 2 UHD rips in row, no issues, and there were no pauses when I shelled into the unit.
The wifi access point (whichever one was being used at the time) is in the same room (no walls or obtacles) less than 10 feet away from the Vero.
I have regularly repeated this failure with 3 different access points now - a Unifi AC-Pro, a Unifi U6-Pro and (a few days ago I brought in an Aruba AP-25 in order to verify there wasn’t some strange incompatibility between the Vero V and the Ubiquiti gear. No luck using the Aruba either.
My 2 Vero 4k+'s have none of these issues and play the uhd rips fine with all of the access points.
This is useful to know and rules out a hardware issue. If you experienced problems with Ethernet I would have suspected problematic RAM given the odd hangs.
I have a UniFi AC Lite and haven’t been able to produce problems with it. I’ll take a closer look at your logs and the WiFi state.
Thanks for clarifying. If the radio is defective it should simply not work. I am of course happy to swap the device over but want to narrow down the problem first.
The WiFi module in the Vero V is different to 4K and 4K+ and there might be a quirk or corner case.
I will have a think about it and get back to you tomorrow.
Can you leave the device on with WiFi connected and see if it freezes? Is it only freezing when playing something?