Sam,
So far the freezes have only been when I’m playing uhd (4k) rips. Have seen no freezes with 1080 data. Wasn’t much of an issue for me previously but with a new 4k set on the horizon I need to get this sorted.
Chris
Useful to know, thanks.
Hi guys I have exactly the same trouble. Freeze on wifi, no problem with cable. Before Vero 4k+ also no problem on wifi. So it has to be Vero V problem.
I wrote a while ago different ticket about wifi channel width when I use 40 against 80MHz it is better.
Now for a while I have strange but working workaround.
I had to turn on bandwidth limiter for Vero V on my Asus rt-ax57.
Without bandwith limiter I get around 150mbps (no freeze when I measuring) freeze when I playing big movies. I set up bandwith limiter to 100mbps and no freeze. Usually 100,90 mbps is enough for UHD.
This is a useful data point.
Is it possible just to prevent the crashes by lowering the throughput (and keeping 80Mhz enabled)?
Sam
Sorry I forgot. Yes, I have now 160MHz set on router I see Vero V is connected 80MHz and with limiter without freeze.
OK, if you can try that for a few hours and confirm it stays stable that would be very useful
Sam
I’ve had it set up like this for about 3 months now, so I can safely confirm that.
I haven’t run diagnostics, but I can add another data point to the Vero 4K (no +) working fine over wifi and the Vero V requiring a cable in order not to freeze whilst playing UHD rips. I’ve just resigned to running a 50 ft. cat-6 cable. I’ve had playback freeze over ethernet as well, but it’s rare enough that it’s not a big deal.
Hi Roger,
Thanks for the feedback.
This shouldn’t happen either.
I have an idea what the issue might be with WiFi and will have some solutions here shortly.
Sam
Hi
I’ve taken a bit of time to look in to this.
I have a few ideas what the issue may be, but I’ll go for the lowest hanging fruit first.
I’ve produced two new kernels with two slight frequency adjustments that should resolve things. Please try this one first:
wget "https://collab.osmc.tv/index.php/s/YLJsxYTgog7jKYZ/download/vero564-image-4.9.269-64-osmc-freqat1.deb" -O install.deb
sudo dpkg -i install.deb
reboot
If this doesn’t work, please post a log via My OSMC so that I can check you did indeed install it properly, and then proceed to the second test build:
wget "https://collab.osmc.tv/index.php/s/sZkQb9Cr522XRL2/download/vero564-image-4.9.269-64-osmc-freqat5.deb" -O install.deb
sudo dpkg -i install.deb
reboot
There is also a WiFi driver update from the manufacturer but I don’t want to introduce it yet, because it would be largely untested and could introduce significant regressions. So if we can get the current problems reported here solved with the current driver this would be great.
Cheers
Sam
Both kernels failed rather quickly but I’m re-testing as I didn’t have logging enabled.
Here’s the logs from the first kernel:
https://paste.osmc.tv/zimikaquso
Difference is that the Vero V does not go into a hard freeze, it displays Buffering… and is still accesible via ssh.
Here are the logs from the 2nd kernel - had to reboot this time as grab-logs hung up and the system froze
$ grab-logs -A
Grabbing log UNAME …
Grabbing log cmdline …
Grabbing log Debian version …
Grabbing log OSMC Build Information …
Grabbing log GUI Settings (abridged) …
Grabbing log guisettings.xml …
Masking private information …
Grabbing log advancedsettings.xml …
Masking private information …
Grabbing log sources.xml …
Masking private information …
Grabbing log fstab …
Masking private information …
Grabbing log mounts …
Grabbing log OSMC Packages …
Grabbing log All Other Packages …
Grabbing log APT term.log …
Grabbing log APT history.log …
Grabbing log APT sources.list …
Grabbing log APT apt.conf.d …
Grabbing log APT preferences.d …
Grabbing log APT sources.list.d …
Grabbing log System Journal …
Grabbing log lircd.conf …
Grabbing log init.d …
Grabbing log systemd …
Grabbing log Kernel Message Log …
Grabbing log Memory …
Grabbing log Diskspace …
client_loop: send disconnect: Broken pipe
So you can’t freeze the device with the first kernel? That’s interesting…
It didn’t freeze when the playback stopped, just showed Buffering.
I can try again with the first kernel if you think that will provide some better info.
The second didn’t freeze either until I initiated grab-log, and then it finally froze.
Hi
I can confirm that it freezes with both kernels.
Both of those new kernels, besides not solving the issue also cause audio dropouts on a 720p file with this audio track:
Audio
ID : 2
Format : E-AC-3 JOC
Format/Info : Enhanced AC-3 with Joint Object Coding
Commercial name : Dolby Digital Plus with Dolby Atmos
Codec ID : A_EAC3
Duration : 1 h 53 min
Bit rate mode : Constant
Bit rate : 768 kb/s
Channel(s) : 6 channels
Channel layout : L R C LFE Ls Rs
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Compression mode : Lossy
Stream size : 621 MiB (17%)
Language : English
Service kind : Complete Main
Default : Yes
Forced : No
Complexity index : 16
Number of dynamic objects : 15
Bed channel count : 1 channel
Bed channel configuration : LFE
The stock kernel handles the playback fine.
That’s very odd…
Not sure what you mean by stock kernel but we had some playback improvements in the May update.
By stock I do mean the May update kernel. Was running on one of the test kernels when that audio dropout issue occured, so I switched to the other test kernel and had the same issue. Today I reran the update to get the May “stock” kernel back and it handled that file just fine.
Any news on the original freeze issues?