Thanks, that’s useful. I’ll check that shortly.
1 Like
Here are my post-power-cycle logs after crashing: https://paste.osmc.tv/esifunocim
Interestingly, while the audio/video was crashing and my terminal was unresponsive, the debugging counters shown at the top-left of the screen were still running.
I can certainly notice that hangs happen more often with newer movies. For example, 28 Years Later: The Bone Temple will pretty much guaranteed crash at some point. Two days ago, I watched Glory (a 1989 film) in 4K, and it didn’t crash at all. As I’m assuming newer movies require more bandwidth, could it be a congestion issue?
Here’s a crash from today with “persistent logging” enabled.
Via journalctl -o short-full -b --no-pager|paste-log
Via grab-logs -A
1 Like
Cheers.
To my wife’s dismay, I’ve connected the Vero V to the closest WAP via a network cable and disabled its WiFi.
This achieves two things:
- Totally removes the Vero V’s wifi chip & driver from the picture, meaning that if the Vero V still crashes, it doesn’t have anything to do with it
- Keeps the WiFi backhaul (i.e. there’s still WiFi from eero to eero), meaning that if my WiFi would be crap, it’d still be a possible cause
Then I put on 28 Days Later: The Bone Temple 4K rip (streaming from my Jellyfin server), which previously always crashed the Vero V within the first 15 minutes.
I’m happy to report that the movie has played from beginning to end without a single crash. If anything, this is one of the clearest indications that something’s wrong with the Realtek Wi-Fi chip or its driver.
Again, echoing Oberon, I had a spare Asus wifi router lying around, so I enabled the router’s “media bridge” mode. In this mode, the wifi router connects as a client to the Wifi network and any device physically connected to its ethernet ports gets appropriate Wifi access.
I then disabled the Vero V’s wifi and connected it via Ethernet to the media bridge router. This has cured all crashing problems during seeking. I can seek and replay juicy action scenes to my heart’s content. The problem is of course that because the Vero V is now connecting to the wifi network behind this router, it’s impossible to directly SSH into the Vero V to “do stuff”. But I guess I will need to do less stuff if there are no crashes.
1 Like
That’s a pity. FWIW I have a similar setup - a ZTE router running OpenWRT configured as a bridge. That talks to my main router via WiFi and 4 devices are connected to the ethernet ports. But they all have their own IP addresses, set by the main router’s DHCP so there’s no loss of access for SSH.
It should be fixed in the latest staging build. Sorry – I thought I posted this earlier but clearly missed this.
Hi
Hopefully the issue is now addressed
I’d appreciate it if you could test this and provide feedback before we potentially release this as an update to other users. 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 - Go to My OSMC → Updater → Manual Controls → and select Check for Updates now. When prompted to do so on screen, please choose to install the update.
- 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.
Latest staging - didn’t make it 15 minutes before a solid freeze.
Sorry to hear that. Can you please upload a log?
I want to check you indeed updated correctly and the error.
Sam
Sorry, did not enable persistent logging and it was a hard freeze.
Just crossed my fingers and started a playback.
And yes, I updated correctly. Been doing this a long time.
You don’t need to enable persistent logging.
The kernel freezes are what we need and if you just reboot (don’t pull the plug); you should give us what we need. Device should reboot after a few seconds after a kernel panic
Keep me posted.
Sam
Hi Sam, the problem is that when this sort of crash occurs (at least in my case), the Vero does not respond to the remote and terminal (SSH) connections time out, i.e, there is no way to soft reboot - the only thing I can do is a hard power cycle.
If you are on the latest version of OSMC it will hard reboot if there is a panic. Otherwise your device hasn’t likely crashed
Sam
Device did not reboot, was a hard freeze. No response to remote, no ability to shell in, no answer to ping.
uname -a
Linux zztime 4.9.269-97-osmc #1 SMP PREEMPT Mon Jun 8 19:31:31 UTC 2026 aarch64 GNU/Linux
The same for me, no reboot, just freezing and audio looping. No SSH or anything, only option is to pull the power plug.
Only happens on WIFI.
Please update again (same update instructions apply). You won’t need to do anything if you set the repository within the last 14 days.
Things will still crash.
This update does not fix the WiFi freezes but it should capture the issues now. Over the past couple of months we’ve been building out infrastructure to improve how we handle hard crashes. There’s further improvements in this kernel.
When a freeze hits, the device should now detect it and save a crash log that survives a reboot. While we did this previously in the last update, we weren’t handling every situation where this could occur.
Your device can take up to 30 seconds to restart. Just wait instead of pulling the power.
So please update again via My OSMC and if you get another freeze don’t pull the power, wait for the reboot and upload the logs.
This will let me nail the real fix.
Cheers
Sam
Here’s my logs with the Vero running on the latest staging version: paste.osmc.tv/obitosesat
Indeed, it rebooted itself now after approx. 30 seconds.
And for good measure, another one: paste.osmc.tv/lexicocodo (although this one looks quite different from the log above from a diagonal perusal, so there might be two different issues causing crashes at play here)
Thanks, this is exactly what I needed.
Good news first: the capture is working. That ~30 second freeze-then-restart is the device catching the crash and rebooting itself instead of hanging which is the whole point of this update
On your two logs, only one of them is actually a crash. lexicocodo is the real one. obitosesat isn’t a crash at all: the WiFi driver shut down cleanly and the system did a normal reboot, no kernel panic in it. So it looks like just one issue.
The crash itself confirms the last update fix the freeze which was expected. The build was about capturing it, not fixing it.
To nail down exactly where it’s getting stuck I need a bit more detail than this log carries. I’ve turned on fuller crash logging, so please update again (same as before). The next freeze just let it reboot and send me the log. With any luck this should point me straight at the cause
Sam