Vero V freezes playing UHD rips (any of them). Starts playing fine and then at some point the video freezes and the audio goes into a short loop.
The device no longer communicates with the remote or the network (does not answer an arping) requiring a power on reboot.
On my nfs server I see:
[195346.110827] rpc-srv/tcp: nfsd: sent 1020908 when sending 1048680 bytes - shutting down socket
Logs are at: https://paste.osmc.tv/pagedawomo
Hi
Can you try playing from a local storage?
Do you experience this with other streams?
Is this only unique to UHD files or does it occur with say 1080p content too?
Is this a new issue or did it occur from the beginning with Vero?
Sam
Hi Sam,
So far I have only seen the issue with UHD rips, and it is consistent - it will happen, just exactly when is unknown.
It’s a new issue although I was previously able to watch a UHD rip with no issues with my Vero 4k+. Besides using a different device (4k+ vs V) the other change is that the Ver0 4k+ was connected to an Oppo 105 and the Vero V is connected to a Sony HT-A7000.
I will do some more testing. Anything of note in the logs?
Thank you,
Chris
Long time but finally getting back to this issue, as I’ve set aside some time to try and track the problem down.
Basically my Vero V cannot succesfully play any of my UHD rips. At some point in the playback everything will freeze, the audio may sound a very short loop. The Vero V is unresponsive, remote buttons do nothing, one cannot be SSH into it and it does not answer a ping.
If I enable logging (and I’ve done so several times now) the logs show nothing. However my nfs server always logs something like:
rpc-srv/tcp: nfsd: sent 32876 when sending 1048680 bytes - shutting down socket
The actual sent number will change but the error logged is always essentially the same.
I’ve also noticed that when I’m shelled into the Vero V there will be short pauses where the unit is unresponsive and then a few moments later it is resposive again.
What I can gather from the server logs is that the Vero V simply stops acceptiong data and that’s why the socket gets shutdown.
To help determine where the problem lies I connected my old Vero 4k+ the exact same way, to the same WiFi ssid and the same hdmi cable. The old Vero 4k+ can play the UHD rips all day long with nary a burp,
Note that I’ve also tried foricng the Vero V to both 2.5GHz and 5GHhz and it fails on both.
Chris
1 Like
Hi Chris,
I’ll get back to you about this tomorrow.
Sam
Hi Chris, reading your posts carefully, it looks like VeroV is halting/crashing for some unknown reason.
The log set you posted last year is no longer available, so current logs with active debug would be very helpful.
It’s not clear to me whether you’re using Kodi’s built-in NFS stack or kernel-based NFS using the Autofs or fstab method.
For more information, you can try enabling persistent kernel logs (see below). Just to set expectations right, there is no guarantee that useful information will be logged in a timely manner in the event of a crash, as critical time races here could prevent such information being dumped fast enough. It’s worth a try after all. Don’t forget to remove the journal folder afterwards as explained in the last 2 steps!
After activating the debug option in the GUI (then boot twice) and the persistent logs, it should be enough to upload the logs via GUI or ‘grab-logs -A’ after the crash and post the URL here.
To activate and provide persistent kernel logs, please, follow the steps below:
- login via SSH to the OSMC device, user
osmc, passwordosmc cd /var/logsudo journalctl --rotatesudo journalctl --vacuum-time=1ssudo mkdir journal- (from now, kernel messages are written to new directories for every boot)
sudo shutdown -r now- now wait for the issue/event which is the problem of this topic
- once it happens again and you are forced to reboot the OSMC device or it rebooted automatically, you’ve to identify the right kernel message log:
9.a) login via SSH and invoke
sudo journalctl --list-boots --no-pager
9.b) the lines start with an index id like 0, -1, -2, etc. and contain the date and time when log was started - also, upload the appropriate full log using
sudo journalctl -o short-full -b <identified index> --no-pager|paste-log
(replace<identified index>with the real index id, see above) - provide the returned URLs here
- don’t forget to remove the created
journaldirectory otherwise your system’s root file system gets filled
12.a) login via SSH
12.b )cd /var/log
12.c)sudo rm -R -f journal && sudo reboot(repeat this line if you get a ‘cannot remove’ error until it works and your ssh connection gets lost by the reboot)
We hope that this catches more helpful information and enables us to help you, soon.
Hi Jim,
I have had logs enabled many times trying to troubleshoot this and I can assure you there’s nothing of note in them - the system simply hard crashes and therefore is unable to write anything useful to the log after that point.
This is the tail of such a log:
2024-05-10 13:46:44.315 T:3032 debug : ffmpeg[0xb057cd88]: [swscaler] No accelerated colorspace conversion found from yuv420p to bgra.
2024-05-10 13:47:14.280 T:3045 debug : Thread JobWorker 3606569216 terminating (autodelete)
2024-05-10 13:47:14.295 T:3026 debug : Thread JobWorker 3818799360 terminating (autodelete)
2024-05-10 13:47:14.306 T:3018 debug : Thread JobWorker 3905933568 terminating (autodelete)
2024-05-10 13:47:14.317 T:3032 debug : Thread JobWorker 3766468864 terminating (autodelete)
I’ve enabled the nfs client a couple of different ways - via fstab and via systemd units. I’ve also tested with both nfs3 and nfs4.2. All configurations work without issue with my old Vero 4k+'s (I have 2).
My 4k+'s also have no pause issues when I’m shelled into them, which has me thinking there is defintely something wrong with this unit.
The wifi access point 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 just yesterday 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.
Chris
I’ve pretty much narrowed it down to a wifi issue. 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 no pauses when I shelled into the unit.
I’ve now reconnected the wifi and these ping times are awful:
$ ping verov
PING verov (192.168.77.101) 56(84) bytes of data.
64 bytes from verov (192.168.77.101): icmp_seq=1 ttl=63 time=2167 ms
64 bytes from verov (192.168.77.101): icmp_seq=2 ttl=63 time=1161 ms
64 bytes from verov (192.168.77.101): icmp_seq=3 ttl=63 time=137 ms
64 bytes from verov (192.168.77.101): icmp_seq=4 ttl=63 time=2.68 ms
64 bytes from verov (192.168.77.101): icmp_seq=5 ttl=63 time=2.59 ms
64 bytes from verov (192.168.77.101): icmp_seq=6 ttl=63 time=3.10 ms
64 bytes from verov (192.168.77.101): icmp_seq=7 ttl=63 time=2.50 ms
64 bytes from verov (192.168.77.101): icmp_seq=8 ttl=63 time=3698 ms
64 bytes from verov (192.168.77.101): icmp_seq=9 ttl=63 time=2691 ms
64 bytes from verov (192.168.77.101): icmp_seq=10 ttl=63 time=1667 ms
64 bytes from verov (192.168.77.101): icmp_seq=11 ttl=63 time=643 ms
64 bytes from verov (192.168.77.101): icmp_seq=12 ttl=63 time=2.51 ms
64 bytes from verov (192.168.77.101): icmp_seq=13 ttl=63 time=2.65 ms
64 bytes from verov (192.168.77.101): icmp_seq=14 ttl=63 time=3.31 ms
64 bytes from verov (192.168.77.101): icmp_seq=15 ttl=63 time=2.47 ms
^C
— verov ping statistics —
16 packets transmitted, 15 received, 6.25% packet loss, time 15101ms
rtt min/avg/max/mdev = 2.474/812.333/3697.792/1162.442 ms, pipe 4
Note that I live in a suburban single family house, not an apartment building with a competing wifi unit on every adjoining wall. I only run one access point, no mesh, no expander, etc.
What router are you using, there are a crapton of bad ones out there and they make a big difference.
Are you running on the 2.4Ghz or 5Ghz band ? I agree that those are terrible ping times unless you are running them while playing the file, in which case the playback is being prioritized over the ICMP pings. I have 3 Vero V units and have no problem steaming full UHD rips over WiFi on the 5ghz band.
Jeff
Three different access points have been tried (this was documented above) - Unifi AC-Pro, Unifi U6-Pro, and recently (in order to eliminate the Ubiquiti gear as the problem source) Aruba AP-25.
All work just great with my other devices, including 2 Vero 4k+'s.
1 Like
I’ve tried both. Which is why I think it’s a problem with the wifi on this unit. I have no issues with my Vero 4k+'s, they both work fine.
@chris8 Just to get a confirmation: You already tried to activate persistent logging + debugging and took a log set after the issue occured?
I have had this problem as well, at some point it was very often many times every day where the Vero V froze and the audio lopped, and had to pull the power plug. but not the last couple of weeks.
My Vero is connected via WiFi as well.
I have a addon installed, which prevent me from getting help in here, that’s why i haven’t made a post about it, so it is nice to see it is not only me, and hopefully the problem can be fixed.
Thanks Jim,
Again I have turned logging on many times in troubleshooting this (turn it on, boot twice). Outside of doing some autorotating I see nothing in your “persistent logging” instructions that would cause the unit to actually log more information on a freeze then what I’ve already seen many times.
What, exactly, in your set of instructions will cause the unit to log more information than it already does (when properly enabled), when it’s frozen solid, does not respond to a ping, nor any remote input?
With the persistent journal logging the actual journal survives a reboot. Without it starts always with every new boot (after a freeze/crash) and the previous information is lost.
If you spent so much time, it would at least mean some chance to get more information from that freeze/crash.
Regarding wifi: When this happens, what are the system events on your wifi router, access point, bridge, etc.?
Any special actions like a search for new channels, radar detection, etc.?
From what I can see the log does survive the boot - it get’s renamed to kodi.old.log and the new/current log is named kodi.log. The timestamps, both of the logs and in the logs, seem to verify this.
Is this not correct?
Logs of the last crash:
https://paste.osmc.tv/napiyirizo
Some snaps of top while uhd rip is playing:
top - 11:27:04 up 6 min, 1 user, load average: 2.33, 1.74, 0.89
Tasks: 173 total, 2 running, 171 sleeping, 0 stopped, 0 zombie
%Cpu(s): 4.1 us, 12.3 sy, 0.0 ni, 83.6 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 3764.0 total, 2496.1 free, 943.2 used, 324.6 buff/cache
MiB Swap: 0.0 total, 0.0 free, 0.0 used. 2617.7 avail Mem
top - 11:30:10 up 10 min, 1 user, load average: 2.38, 1.92, 1.11
Tasks: 173 total, 1 running, 172 sleeping, 0 stopped, 0 zombie
%Cpu(s): 4.2 us, 12.6 sy, 0.2 ni, 81.4 id, 0.0 wa, 0.0 hi, 1.7 si, 0.0 st
MiB Mem : 3764.0 total, 2485.7 free, 947.8 used, 330.5 buff/cache
MiB Swap: 0.0 total, 0.0 free, 0.0 used. 2613.2 avail Mem
top - 11:30:47 up 10 min, 1 user, load average: 2.58, 1.99, 1.16
Tasks: 169 total, 1 running, 168 sleeping, 0 stopped, 0 zombie
%Cpu(s): 3.2 us, 11.5 sy, 0.3 ni, 83.4 id, 0.0 wa, 0.0 hi, 1.7 si, 0.0 st
MiB Mem : 3764.0 total, 2490.0 free, 950.3 used, 323.6 buff/cache
MiB Swap: 0.0 total, 0.0 free, 0.0 used. 2610.6 avail Mem
top - 11:32:01 up 11 min, 1 user, load average: 2.32, 2.00, 1.23
Tasks: 168 total, 2 running, 166 sleeping, 0 stopped, 0 zombie
%Cpu(s): 3.7 us, 11.8 sy, 0.3 ni, 82.0 id, 0.0 wa, 0.0 hi, 2.1 si, 0.0 st
MiB Mem : 3764.0 total, 2481.5 free, 944.7 used, 337.7 buff/cache
MiB Swap: 0.0 total, 0.0 free, 0.0 used. 2616.1 avail Mem
Maybe it’s overheating?
There is only one active journal in your log set … means persistent journal logging was not activated.