Stable until the kernel got updated…
Not investing anymore time here… I’ll leave the unit on the December built with updated Debian packages. Good enough for me. If Kernel alone one in combination with Kodi triggers something? I dunno and I don’t want to test combinations over combinations. Just something it doesn’t like about my network. It is what it is…
Ok, will check it out.
If I can reproduce it, I can fix it
Sam
Hi Sam,
any updates on this?
Bought my Vero 4K+ six weeks ago (currently on version 2020.03-1). Video playback enters infinite buffering from time to time (about once every week). While digging through the logs I encountered
[133789.091278] CFG80211-ERROR) wl_is_linkdown : Link down Reason : WLC_E_DISASSOC_IND
[133789.091284] link down if wlan0 may call cfg80211_disconnected. event : 12, reason=33 from 98:9b:cb:b7:3f:07
[133789.092412] wl_iw_event: Link Down with BSSID=98:9B:CB:B7:3F:07
[133789.092475] CFG80211-ERROR) wl_is_linkdown : Link down Reason : WLC_E_LINK
[133789.094477] cfg80211: Calling CRDA to update world regulatory domain
[133792.952076] Connectting with 98:9b:cb:b7:3f:08 channel (6) ssid "Hermes", len (14)
[133793.021501] wl_iw_event: Link UP with BSSID=98:9B:CB:B7:3F:08
[133793.021528] wl_bss_connect_done succeeded with 98:9b:cb:b7:3f:08
[133793.081087] wl_bss_connect_done succeeded with 98:9b:cb:b7:3f:08
which led me to this post.
As noted above and here, reason code 33 means “Disassociated because QoS AP lacks sufficient bandwidth for this QoS STA”.
I have no idea what this means in practice (or even if it correctly describes the true problem). Unfortunately, it might be a problem on the Vero4K+, the router/access point or possibly some kind of radio interference on the 2.4 GHz band. The best I can suggest at this stage is to try a different channel and/or see if it occurs at certain times of the day.
@Crossi36 Obviously your AVM router/repeater 98:9b:cb:b7:3f:07 kicked you out and the Vero re-connected to another AVM device 98:9b:cb:b7:3f:08 ?
Is this a wireless mesh network?
The router is right next to the Vero (1m distance, if that). I do have a repeater upstairs, which is connected with a lan cable. I’d be surprised if the signal even reaches the Vero. But yes, router and repeater build a mesh network.
What I don’t understand yet is why the Vero starts buffering infinitely. Apparently it does reconnect to the network (even if it is through a different access point), so the NAS should be reachable?
Well, at least we know now that this action belongs to the AVM mesh steering where the router decided to let change the Vero device from the 2.4 GHz network to the 5 GHz one or vice versa, see here a screenshot of my AVM router with two connected modern AVM repeaters:
Why you’re using a wifi connection for that?
Multiple reasons:
This is at my parents house and they don’t like cables / want to keep visible cables to a minimum.
All the LAN ports on the FritzBox are occupied and my parents don’t want to spend extra money on a switch.
Can’t think of why we shouldn’t.
The 4.9 kernel has a newer WiFi driver - might yield improvements here.
I’m still on the 3.14 kernel and setup a test environment building a mesh network consisting from
All devices have 2.4 GHz and 5 GHz wifi active and are integrated in the AVM mesh network also doing AVM mesh steering.
Logged a Vero4k (AVM router configured to always provide the same IP for this device) into the wifi network (so, wifi enabled and ethernet disabled on the Vero) and let switch the wifi connection by manually disable/enable the specific AVM WLAN interface where the Vero is actually connected to … while playback of a full HD movie with DTS-HD MA audio.
Whatever I did the Vero immediately logged into the next AVM access point and the playback was fine without any buffering message. Even when deactivating all wifi on LAN-connected AVM devices (so only using AVM wifi repeaters in the mesh network) worked like a chap, no error picture.
@Crossi36 From that I think the original issue is not related to your log findings and must be something else.
To get a better understanding of the problem you are experiencing we need more information from you. The best way to get this information is for you to upload logs that demonstrate your problem. You can learn more about how to submit a useful support request here.
Depending on the used skin you have to set the settings-level to standard or higher, in summary:
enable debug logging at settings->system->logging
reboot the OSMC device twice(!)
reproduce the issue
upload the log set (all configs and logs!) either using the Log Uploader method within the My OSMC menu in the GUI or the ssh method invoking command grab-logs -A
publish the provided URL from the log set upload, here
Thanks for your understanding. We hope that we can help you get up and running again shortly.
OSMC skin screenshot:
So they are both also right next to the TV. You haven’t mentioned the TV but many TVs now have WiFi Direct, which might be causing interference on 2.4 GHz.
There is not explicite QoS setting on the AVM router (its setting will be propagated to all other APs and repeaters in the mesh network). But yes, here is a flag active which means to optimize the wifi for Live TV. I think this is the default and the only setting which correlates to QoS and/or WMM.
The TV is a “Telefunken XH24G101”. As far as I can tell it can barely do anything. Didn’t find any mention of WiFi Direct.
I’ll do that. Bear in mind that it could take a few days before the problem appears again.
Perhaps, you should do a reboot (twice!) of the Vero on a daily base otherwise the logs could get too large in size,
Tried to use the SSH method, but the connection timed out (couldn’t connect to the Vero). Tried to do it on the Vero itself, but it was unresponsive. Had to pull the power plug. After reconnecting the power plug I could control it like normal and also SSH into it.
https://paste.osmc.tv/emedoqavan
Error appeared today (24th April).
If the device is unresponsive then I don’t think it’s losing signal. It could be going in to very low power mode or crashing.
