The following is an AI analysis - do with this what you will, but this sounds logical:
Your wired-vs-wireless correlation is consistent with the evidence, and points to a contributing mechanism rather than contradicting the DV finding. The likely interaction:
The 8822cs SDIO Wi-Fi driver runs its RX/TX and scan work in softirq/interrupt context on CPU0 — the same CPU and the same softirq path that the DV parse failures are saturating. Throughout all three logs the wireless stack is continuously busy on CPU0: repeated cfg80211_rtw_scan ... scan abort!! BusyTraffic, OnAction_back, block-ack (addba) churn, and scan deny ... need sleep 500ms — the last of these appearing at t≈11124s, ~12s before the lockout.
The most probable model: the DV metadata failures already push CPU0’s softirq/timer load to the edge (ratio:23). When Wi-Fi is active, the rtl8822cs SDIO interrupt + scan workload adds sustained softirq pressure on the same core, tipping it past the point where the per-CPU softirq loop can yield. CPU0 then cannot make progress for 22s and the watchdog panics. On wired Ethernet, that additional softirq/IRQ load on CPU0 is absent (the MAC/PHY path is lighter and differently routed), so the DV-stressed core stays just under the lockup threshold and playback survives. This is why the same DV file crashes on Wi-Fi but not on wired.
In short: two interacting factors. The DV dual-layer metadata fault is the underlying stressor; the rtl8822cs SDIO Wi-Fi softirq load is the additive trigger that turns a degraded-but-surviving state into a fatal CPU0 soft-lockup. This reconciles the two DV panics — under a common theme of CPU0 softirq/interrupt-path contention.
Mitigations that reduce CPU0 softirq contention while you keep Wi-Fi:
Disable Wi-Fi power management / power-save on wlan0 (reduces scan/wake churn).
Disable background Wi-Fi scanning where possible (the recurring cfg80211_rtw_scan events are a steady softirq source).
If your kernel exposes IRQ affinity, moving the SDIO/Wi-Fi IRQ off CPU0 (/proc/irq/*/smp_affinity) would directly test the same-core contention hypothesis.
I don’t think it’s related to DV at all. The issue existed before we even implemented it. I suspect you see those failures because data stops coming in, so the decoder chokes.
Another update is up — please update again (same as before).
This one’s different from the last: the previous build was about capturing the freeze, and it did its job — the crash logs you sent pointed me at the actual cause.
Short version: it’s not Dolby Vision. The DV errors in the logs are the decoder running out of data, not the cause — and the freeze only happens on WiFi, never wired, which puts it squarely in the WiFi driver’s receive path. This build changes how that path hands received data to the system, so it shouldn’t be able to lock the CPU up the way it has been.
I’m not going to call it fixed until you tell me it is. So please update, carry on as normal, and let me know either way:
if it stops freezing — brilliant, tell me how long you’ve been running.
if it still freezes — let it reboot itself and send another log (same as last time). The extra logging from the last build is still on, so the next log will tell me whether I’ve nailed it or there’s a second layer to this.
Thanks again for the quick turnaround on those logs — that’s what got us here.
But to your point, I also experienced this freezing with another SDR movie. The only issue there is that it’s not a great movie for testing, as it doesn’t crash reliably, and when it does, it appears to be at random spots. Whereas with the current movie I’m testing, I’m sure I can reproduce it within the first 15 mins, which makes it a great test file.
While I was typing the above, I thought “heck, why not just try testing with the SDR movie as it might provide additional data points”, and behold, I’ve got a crash: paste.osmc.tv/esezowepor
Also, it definitely confirms it has nothing to do with DV.
I spent time tracing where this WiFi driver actually comes from.
The driver makes assumptions about how received WiFi data is passed up to the system, and on the Vero V those assumptions don’t hold. This build routes that traffic through the system’s own standard path instead.
What I need:
Update via My OSMC and carry on as normal.
If it freezes, don’t pull the power — let it reboot itself (~30s) and send the log.
If it stays up, let me know how long — ideally after a few hours, or a film or two.
Two honest caveats: you may lose a sliver of peak WiFi throughput (you won’t notice it streaming), and if it still freezes, that tells me the cause is somewhere other than the driver’s receive path — which is itself useful. The crash logging stays on either way, so the next freeze still teaches me something.
In all my testing it was very rare for the unit to make it through one full UHD rip, I’d guess on the order of 5%, and if it did I would start another right after and it would always fail.
With this latest devel update it played 3 full UHD rips back to back today (~7 hours of video). I think you may have finally slain the monster, or at the least, put him on his heels.
I didn’t watch at all. Just started playback and checked in every now and then to see if a freeze, crash, or reboot had occurred.
Two of my normal “acid test movies” are UHD rips of Lost Highway (1997) and Mulholland Drive (2001).
Well, I think you’ve smashed that bug @sam_nazarko. The movie that would guarantee to freeze in the first 15 minutes (28 Days Later: The Bone Temple) played from start to end without a hitch. Similarly, for the SDR movie (No Other Choice), for which I previously provided a crash log, has run fully without freezing. Looks like anything I throw at it works.
