Crash: log files attached

[digitl]

M Vu+ Duo 4K SE just crashed for the second time in a few days.

For some time now I've been seeing the rotating ViX logo when changing channels or moving in and out of the recordings list.

Perhaps the collected log files might throw some light on this or perhaps they illustrate some other issue?

 

[twol]

Crash log says it all…..
461527.633833> OSError: [Errno 5] Input/output error: '/media/autofs/PVR/media/20261021 1855 - 5 HD - Fare Dodgers At War with the Law.ts'
<461527.633926> [ePyObject] (CallObject(<bound method Timer.calcNextActivation of <RecordTimer.RecordTimer object at 0x8d9273c8>>,()) failed)

 

[digitl]

Crash log says it all…..
461527.633833> OSError: [Errno 5] Input/output error: '/media/autofs/PVR/media/20261021 1855 - 5 HD - Fare Dodgers At War with the Law.ts'
<461527.633926> [ePyObject] (CallObject(<bound method Timer.calcNextActivation of <RecordTimer.RecordTimer object at 0x8d9273c8>>,()) failed)

Thanks. Assuming I've understood, is there any explanation for why the recording should fail and crash the box?

 

[2stein]

input/output error might mean that the disk is full?

 

[digitl]

input/output error might mean that the disk is full?

No, I've got 33TB free on a 54.5TB NAS.

 

[digitl]

Another crash today when changing channel using the Channel rocker key and with PiP running.

Hopefully, the attached files will provide an insight into why and how to fix. I'm continuing to see the ViX rotating icon with very slow reactions to channel changes and access to and from the recordings list..

 

[2stein]

the first one shows the same disk error as before. if the disk is not full, maybe it has problems... have you checked it?

 

[digitl]

Thanks, I can access it without any issues from my laptop and desktop.

 

[2stein]

i had ai analyse your 2nd log:
It does show a few stalls, mostly caused by one dead storage path on the Duo4K SE.

1. Every channel change stalls about 5 s before tuning starts.

• At 540845.56 I see the CH+ key release and Navigation playing ref, but the tune only begins at 540850.68, 5.1 s later.
• The OK-key zap at 540857.34 doesn't reach the new PMT until 540862.63, 5.3 s later.
• Both stalls show [gRC] Warning: Main thread is busy and a stack trace. The traces put the main thread in Timeshift.py: createTimeshiftFolder → resolveFilename → isdir, and later getTimeshift → timeshiftEnabled.
• The failure messages repeat: [TimeShift] Failed to create /media/hdd/timeshift !! and timeshift /media/hdd/timeshift/ statfs failed: Function not implemented.
• /media/hdd is dead, and it also shows up as drive not accessible … '/media/hdd' at boot. It is probably an autofs or symlink target for the "FrankPVR192168178103" NAS mount, which seems to be unreachable.
• The CIFS mount churn in the netlink lines fits this: cifs-397 appears at 540833.19 and is gone at 540838.50.
• To check this, run ls -l /media/hdd, mount | grep -i autofs and ping 192.168.178.103. Pointing timeshift at the working /media/autofs/PVR mount (or at a local path) or disabling it should remove the stall.

it sounds like there is a NAS mount that does not work.

 

[digitl]

Odd, FrankPVR192168178103 appeared from nowhere and has now gone. Perhaps after some rooting around for a solution last night!

Hopefully, the following makes sense:

root@Vu+:~# ls -l /media/hdd
drwxr-xr-x 2 root root 4096 Oct 23 01:35 backup
-rw-r--r-- 1 root root 10195371 Nov 15 2024 epg.dat
-rw-r--r-- 1 root root 3170874 May 1 11:03 hdmicec.log
drwxr-xr-x 2 root root 4096 Oct 23 01:39 imagebackups
drwx------ 2 root root 16384 Aug 27 2024 lost+found
drwxr-xr-x 3 root root 32768 Oct 23 01:20 movie
drwxr-xr-x 2 root root 4096 Oct 23 14:05 timeshift
root@Vu+:~# mount | grep -i autofs
/etc/auto.network on /media/autofs type autofs (rw,relatime,fd=7,pgrp=1683,timeout=5,minproto=5,maxproto=5,indirect)


root@Vu+:~# ping 192.168.178.103
PING 192.168.178.103 (192.168.178.103): 56 data bytes
64 bytes from 192.168.178.103: seq=0 ttl=64 time=0.343 ms
64 bytes from 192.168.178.103: seq=1 ttl=64 time=0.316 ms
64 bytes from 192.168.178.103: seq=2 ttl=64 time=0.329 ms
64 bytes from 192.168.178.103: seq=3 ttl=64 time=0.284 ms
64 bytes from 192.168.178.103: seq=4 ttl=64 time=0.315 ms
64 bytes from 192.168.178.103: seq=5 ttl=64 time=0.363 ms
64 bytes from 192.168.178.103: seq=6 ttl=64 time=0.329 ms
64 bytes from 192.168.178.103: seq=7 ttl=64 time=0.334 ms
64 bytes from 192.168.178.103: seq=8 ttl=64 time=0.291 ms
64 bytes from 192.168.178.103: seq=9 ttl=64 time=0.312 ms
64 bytes from 192.168.178.103: seq=10 ttl=64 time=0.318 ms

 

[2stein]

looks good to me.