[Mut@nt] HD51 Crash at end of recording, when end margin starts

[Mickkie]

I've noticed a few times so far following an update to 5.3.015 the following malfunction.

I start watching a recorded programme while the recording is still taking place. When the recorded programme reaches its end time and the tail end margin timer starts, the Mut@nt crashes. The GUI restarts and continues recording (I have set the end margin to 5 minutes). After that event I end up with two recordings present, the main programme and the a separate tail end 5 minute recording. When it restarts following the crash it reverts to any settings I had when I first switched on the Mut@nt, rather than the settings at the time it crashed (e.g. selected channel, volume level).

I've enabled the logs and will keep an eye on this tomorrow, but I am wondering if anyone else has observed the same thing? This did not happen with any version prior to 5.3.015.

 

[Sicilian]

Not experienced this issue on any of my receivers.

 

[Mickkie]

OK, it happened again this morn. I couldn't find anything immediately obvious in the logs, but will post them if you think they could be useful. Nevertheless, I had a quick look in dmesg and it seems the ext4 fs on the root partition was corrupted at some point:

[Warning!  /dev/mmcblk0p3 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
/dev/mmcblk0p3 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  +(393217--397344) +(401409--401667) +(524289--524303) +(524305--524319) +(524321--528160) +(655361--655371) +(655377--655387) +(655393--658208) +(663553--663811) +786433 +(786436--786
437) +(786440--786696) +(787209--787464)
Fix? no
Free blocks count wrong for group #48 (4064, counted=8192).
Fix? no
Free blocks count wrong for group #49 (7933, counted=8192).
Fix? no
Free blocks count wrong for group #64 (4064, counted=7934).
Fix? no
Free blocks count wrong for group #80 (4064, counted=6902).
Fix? no
Free blocks count wrong for group #81 (7933, counted=8192).
Fix? no
Free blocks count wrong for group #96 (7160, counted=7676).
Fix? no
Free blocks count wrong (480867, counted=500920).
Fix? no
Free inodes count wrong (191182, counted=191180).
Fix? no
Padding at end of block bitmap is not set. Fix? no

/dev/mmcblk0p3: ********** WARNING: Filesystem still has errors **********
/dev/mmcblk0p3: 13618/204800 files (0.7% non-contiguous), 338333/819200 blocks

What is the recommended way of repairing this fs?

 

[twol]

OK, it happened again this morn. I couldn't find anything immediately obvious in the logs, but will post them if you think they could be useful. Nevertheless, I had a quick look in dmesg and it seems the ext4 fs on the root partition was corrupted at some point:

[Warning!  /dev/mmcblk0p3 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
/dev/mmcblk0p3 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  +(393217--397344) +(401409--401667) +(524289--524303) +(524305--524319) +(524321--528160) +(655361--655371) +(655377--655387) +(655393--658208) +(663553--663811) +786433 +(786436--786
437) +(786440--786696) +(787209--787464)
Fix? no
Free blocks count wrong for group #48 (4064, counted=8192).
Fix? no
Free blocks count wrong for group #49 (7933, counted=8192).
Fix? no
Free blocks count wrong for group #64 (4064, counted=7934).
Fix? no
Free blocks count wrong for group #80 (4064, counted=6902).
Fix? no
Free blocks count wrong for group #81 (7933, counted=8192).
Fix? no
Free blocks count wrong for group #96 (7160, counted=7676).
Fix? no
Free blocks count wrong (480867, counted=500920).
Fix? no
Free inodes count wrong (191182, counted=191180).
Fix? no
Padding at end of block bitmap is not set. Fix? no

/dev/mmcblk0p3: ********** WARNING: Filesystem still has errors **********
/dev/mmcblk0p3: 13618/204800 files (0.7% non-contiguous), 338333/819200 blocks

What is the recommended way of repairing this fs?

I seem to remember this is a standard error because of the way that the 1st Emmc partition is built (and truncated) - so not your issue and nothing you can do about it.
You need to supply crash logs

 

[Mickkie]

I've mounted the / partition ro and run a fsck.ext4 on it, fixing whatever errors it came up with. I rebooted, reflashed the latest openvix image and we'll see what this gives.

I attach the logs of the crash from this morning. Timestamp 57430.552 shows where I suppose the box woke up to start recording '20200207 0827 - BBC NEWS HD - Worklife'.
Then at 57433.153 the recording starts. The crash happened towards the end of this 30 minutes recording, as I was playing back a previous recording of Newsnight. Not sure when the crash happened exactly.

Log pasted here: REMOVED LINK

 

[ccs]

That link has a trojan according to my virus guard - you should post them as attachments via advanced options.

 

[Sicilian]

I've removed the link, as above post the crash log.

 

[Mickkie]

Apologies, I don't know why it says there's a trojan, it's just a pastebin service and the log is plain text. Regardless, please see attached log (I hope it's not too long).

 

[ccs]

.... that's a debug log, there doesn't appear to be a crash, just the power button being pressed.

 

[Mickkie]

Oops! Sorry ... here is the crash log.View attachment Enigma2_crash_2020-02-07_09-52-20.log

 

[ccs]

Looks like the root partition (from your earlier post #3) is still (partially?) read-only

< 62538.824>   File "/usr/lib/enigma2/python/RecordTimer.py", line 1125, in saveTimer
< 62538.824> IOError: [Errno 30] Read-only file system: '/etc/enigma2/timers.xml.writing'

 

[twol]

You have a multiboot system, so assume you have backed up your settings use ImageManager to flash latest image into another slot and try again!!

 

[Mickkie]

Hmm ... the plot thickens.

At the time I had not yet run fsck on the / fs. For whatever reason the crash took place, inc. the state of the fs, it seems it was remounted as ro when it errored out.

This is what it looks like presently:

root@mutant51:~# mount
/dev/mmcblk0p3 on / type ext4 (rw,relatime,data=ordered)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
devtmpfs on /dev type devtmpfs (rw,relatime,size=190260k,nr_inodes=47565,mode=755)
tmpfs on /media type tmpfs (rw,relatime,size=64k)
/dev/mmcblk0p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
tmpfs on /var/volatile type tmpfs (rw,relatime)
/dev/sda1 on /media/hdd type ext4 (rw,relatime,data=ordered)
/dev/sdb1 on /media/usb type vfat (rw,relatime,fmask=0000,dmask=0000,allow_utime=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000)
/etc/auto.network on /media/autofs type autofs (rw,relatime,fd=6,pgrp=2100,timeout=5,minproto=5,maxproto=5,indirect)

However, the file it is looking for above is no where to be found?

root@mutant51:~# ls -la /etc/enigma2/timers.xml.writing
ls: /etc/enigma2/timers.xml.writing: No such file or directory
root@mutant51:~# ls -la /etc/enigma2/timers.xml 
-rw-r--r--    1 root     root         32952 Feb  7 14:05 /etc/enigma2/timers.xml

 

[twol]

I would give up looking and just either reflash the slot or preferably flash another slot vis IMageManager

 

[Mickkie]

Thanks guys,

Since I've fsck'ed the partition and reflashed the image, the Mut@nt seems to be OK again. I hope the problem was an one off rather than a eMMC hardware failure. I guess time will tell.

 

[Mickkie]

Thanks guys,

Since I've fsck'ed the partition and reflashed the image, the Mut@nt seems to be OK again. I hope the problem was an one off rather than a eMMC hardware failure. I guess time will tell.

Sadly there was another crash last night, but looking at dmesg after a clean reboot there are no fs errors. What else might it be causing this? Power supply gone wrong?

 

[ccs]

…. maybe the crash log will give us a clue?

 

[Mickkie]

…. maybe the crash log will give us a clue?

Thanks ccs, I have enabled logs and rebooted. Will keep an eye out for subsequent crashes and report back.

 

[twol]

@Mickkie - if its a crash, then the crash log is there - probably in flash if you never set up Debug logs.

 

[Mickkie]

Ohh! I wasn't sure if a log would be created unless I had enabled the capture of debug logs first. This is interesting: there were no crash logs present, when I looked immediately after the 'crash'. Am I misinterpreting the phenomenon as a crash? This is what happened last night.

I was watching a film from a live transmission, no recording taking place. Suddenly the TV screen went dark and for no longer than 2-3 seconds the VIX spinner showed up at the top left corner of the screen, before the picture returned. This is a much shorter duration than when rebooting the STB or restarting the GUI. If this is not a crash, what could it be?

At previous instances when this occurred while a recording was taking place, the recording stopped and restarted a few seconds later, resulting in two recorded files stored on the disk.