U4 Frequently crashes / reboots / freezes

[Pat]

For the past week I've been having various issue, I'm thinking the HDD is dying. A few months ago I had an issue with the HDD:
viewtopic.php?f=42&t=14270

But this time the symptoms are different. I ran fsck.ext4 and it didn't find any issues.

Sometimes when I turn on the U4 I find it is on the boot screen, saying loading 100% on the front panel but never loads. I turn it off and on again and it usually boots fine. It seems to be in this state after a timer was scheduled to record.

I try to manually start a recording and it fails, asking if the disk is full, but there is 148 GB.

Timeshift sometimes works and sometimes doesn't.

Sometimes when I go to play a recording it will crash with a screen of white text then reboot. Sometimes it will reboot fine and other times it will get stuck at the loading screen. If I then try to play the same recording it may work fine.

Recording playback may get part way through then freeze. It might keep playing a minute later, or it might crash, or it might just stay frozen until I restart manually.

Sometimes when it starts up I try to go to my recordings but it is empty, I try to change the location but it says it can't find the path. Reboot and sometimes it may or may come back good.

Sometimes just scrolling through recordings will cause it to crash with the white text.

I reinstalled the firmware from USB and set up everything from scratch (didn't restore a backup). I've use the file system check from the UI, and fsck.ext4 -f and fsck.ext4 -c from telnet. They didn't seem to turn up any errors.

However, I did see this when running -c. It is saying "badblocks: command not found" so does that mean it's not actually able to check for bad sectors?

Code: Select all

root@beyonwizu4:~# fsck.ext4 -c v/sda1
e2fsck 1.44.3 (10-July-2018)
sh: badblocks: command not found
U4: Updating bad block inode.
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

U4: ***** FILE SYSTEM WAS MODIFIED *****
U4: 2327/357744 files (18.2% non-contiguous), 208065741/244190208 blocks

Attached are the most recent crash logs. I'm seeing errors like this, so I'm guessing HDD:

Code: Select all

<3>blk_update_request: I/O error, dev sda, sector 88367456

Anything else I can do to try to repair it?

[peteru]

I don't know who advised you to use the -c option to fsck.ext4, but don't.

What you want is fsck.ext4 -f /dev/sda1 (or whatever the correct device for your HDD is).

On the surface, a flaky HDD is the most likely cause. However, it could be something else than the HDD itself. For example bad cabling/connectors between the HDD and motherboard. Simplest test is to replace the HDD and see if the replacement behaves. Even if it is an old and small HDD, just for testing purposes. If the replacement HDD also exhibits problems, you need to start looking at the cables & connectors and maybe the components on the motherboard itself.

Given the crash logs, a file system check is prudent because of all the errors you are getting, but it won't fix the problem. If the HDD operates intermittently, there's not much that a filesystem check can do. The problem will be back.

[Pat]

Thanks peteru. I did a -f a couple of times already, but didn't see anything indicative.

Code: Select all

root@beyonwizu4:~# fsck.ext4 -f/dev/sda1
e2fsck 1.44.3 (10-July-2018)
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
U4: 2327/357744 files (18.2% non-contiguous), 208065741/244190208 blocks

The HDD is 2 years old (so is the PVR), it is a Seagate Barracuda 1TB. Any recommendations on a drive that is going to be more reliable?

[peteru]

In small quantities, choosing a HDD is a lottery. Go with whatever appears to be reasonable value at the time you purchase. Maybe a 2TB WD Blue? Although, you could get a 1TB SATA SSD for about the same amount of money.

[Pat]

Can I plug the drive into a USB enclosure and run everything without an internal drive? I.e. can I change the recording and timeshift location to USB? That way I can rule out cable and motherboard while I'm waiting for a new drive.

[Grumpy_Geoff]

Can I plug the drive into a USB enclosure and run everything without an internal drive? I.e. can I change the recording and timeshift location to USB?

Yes, but you shouldn't need to change any settings as the sole USB HDD should mount as /media/hdd (even though the device attachment may be /dev/sdb1 or /dev/sdc1, for example).
I wouldn't boot with more than one USB storage device attached though, as the device assignment may change and all of a sudden a thumbdrive may be mounted as /media/hdd and your USB HDD may be mounted as /media/usb!

[Grumpy_Geoff]

The HDD is 2 years old (so is the PVR), it is a Seagate Barracuda 1TB. Any recommendations on a drive that is going to be more reliable?

What model is it?
If it's a ST1000LM048, I wonder if this is a sign of shingle-pox (SMR) issues? Do the issues happen when the box is busy with concurrent recordings?

[Pat]

What model is it?
If it's a ST1000LM048, I wonder if this is a sign of shingle-pox (SMR) issues? Do the issues happen when the box is busy with concurrent recordings?

Yes, that is the model number. Is there anything I can do to fix it?

I have the timeshift turned on, so it is usually recording something via that. But even with timeshift turned off, just scrolling through the recordings list can trigger a crash. Maybe reading the info from lots of different recordings?


Took the drive out, plugged it into USB, booted it up and started a recording... 2 minutes later it crashed.

The error log looks different, but I'm assuming this is the USB version of the same issue.

Code: Select all

<6>sd 2:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00
<6>sd 2:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 5e 8a 78 d8 00 00 08 00
<3>blk_update_request: I/O error, dev sda, sector 1586133208
<6>sd 2:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00
<6>sd 2:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 01 8e 3f 00 00 01 00 00
<3>blk_update_request: I/O error, dev sda, sector 26099456
<4>EXT4-fs warning (device sda1): ext4_end_bio:314: I/O error -5 writing to inode 14093 (offset 54288384 size 1925120 starting block 9139654)
<3>Buffer I/O error on device sda1, logical block 9139142
<3>Buffer I/O error on device sda1, logical block 9139143
...

[Pat]

As I don't have a working HDD at the moment. Is there any way to set the recording location to a NAS share?

[peteru]

That's s fairly solid indication that the drive is faulty.

[Paul_oz53]

As I don't have a working HDD at the moment. Is there any way to set the recording location to a NAS share?

I haven't tried it myself but others do. The main issue with NAS shares is to use a version of SMB that works ok for both. Have a user account and password ready if your NAS requires them.

Use the network browser to setup a CIFS share on the NAS. It should work with the autofs mount type but if it doesn't, try fstab instead.

You may need to delete the mount option vers=2.1 if your NAS doesn't support version 2.1.

You should tick the "use as HDD replacement option" too.

[Pat]

You should tick the "use as HDD replacement option" too.

Is that it? Once I do that it will automatically start recording there?

Edit: never mind, I found the setting. Thanks for your help.


I've plugged the HDD into my Windows PC and loaded up the drive using ext2fsd. Seems I can copy a couple of shows before it stops. I cycle the power on the USB and then hit 'retry' and it will copy a few more shows. It's painstaking, and will probably take a week, but looks like I'll be able to save my recordings.

[Paul_oz53]

You should tick the "use as HDD replacement option" too.

Is that it? Once I do that it will automatically start recording there?

Edit: never mind, I found the setting. Thanks for your help.


I've plugged the HDD into my Windows PC and loaded up the drive using ext2fsd. Seems I can copy a couple of shows before it stops. I cycle the power on the USB and then hit 'retry' and it will copy a few more shows. It's painstaking, and will probably take a week, but looks like I'll be able to save my recordings.

You may need to change the recording location in Menu >> Setup >> TV >> Recording settings after a restart or reboot.

I had no problem creating a share on my pc but I am recording so can't restart ATM.

[Pat]

I don't think the NAS was working as a recording device. I think it might be going into low power mode, then when a scheduled recording is supposed to start the NAS takes too long to wake up.

I'll disable HDD hibernation on the NAS and see if that helps.

[Grumpy_Geoff]

I'll disable HDD hibernation on the NAS and see if that helps.

Yes, required for you.
The beta firmware has code in it that retries the storage at 5 second intervals for up to 4 times if the drive isn't ready. The production/general release f/w doesn't have that.

[prl]

The beta firmware has code in it that retries the storage at 5 second intervals for up to 4 times if the drive isn't ready. The production/general release f/w doesn't have that.

... up to 3 times ...

[Grumpy_Geoff]

The beta firmware has code in it that retries the storage at 5 second intervals for up to 4 times if the drive isn't ready. The production/general release f/w doesn't have that.

... up to 3 times ...

Yes, of course silly me, as written, less than 3 means, well - if tried less than 3 times, then try again -
https://bitbucket.org/beyonwiz/easy-ui- ... mer.pyT485
I blame the beer.

[prl]

[Pat]

So is that only for NAS? Or would the same retry apply to local disk errors? Or if I stuck this faulty drive into USB?

Looking at the merge log it seems to only be for writing, or is there something similar to retry on read errors?

I'm thinking if the Beta is a bit more robust for reading from flaky drives, it might save me from having to (painfully) transfer all the recordings to my NAS. If I can at least watch them off the bad drive, albeit with a few interruptions, it might be worth the hassle of running Beta.

P.S. (off topic), has anything been added to the Beta to workaround my other issue?

[MrQuade]

P.S. (off topic), has anything been added to the Beta to workaround my other issue?

From a quick review of those issues, I would say that many of them could be explained by........a failing harddisk.

It's likely all related to your current issue.

[Pat]

P.S. (off topic), has anything been added to the Beta to workaround my other issue?

From a quick review of those issues, I would say that many of them could be explained by........a failing harddisk.

It's likely all related to your current issue.

The timeshift issue has been there since day one. Whereas the failing hard drive only started 6 months ago, I managed to repair it then, but the past week it packed it in.

The other issue seemed to indicate a problem with the broadcast.

Sounds like you might have a regional broadcaster with dodgy operating practices. In particular, they may have lots of PTS discontinuities, which could imply they are broadcasting a signal that does comply with the standard...

If you look at the screenshots in this post, it doesn't seem like they would be caused by a faulty hard drive. At minimum the playback needs some out of bounds validation.


Back on topic. Scheduled timers still weren't recording to the NAS, even after disabling hibernation. Long story short, it turns our the timers were still trying to save to the internal HDD. I had changed the Timer Location and Instant Recording Location to the NAS, but left the Default Movie Location on the original setting. It seems like the scheduled timers from IceTV and and manually created timer were using Default Movie Location rather than Timer Location. Once I changed the Default Movie Location, all the timers then updated. I'll have to wait until tomorrow to see if it all works after a few hours idle.

[MrQuade]

The timeshift issue has been there since day one. Whereas the failing hard drive only started 6 months ago, I managed to repair it then, but the past week it packed it in.

If suggest that the harddisk had probably been intermittently dicky the whole time but probably only got bad enough in the last 6 months to become an obvious problem.

I agree though, that the other stuff looks like garbage data from the broadcaster. Not much you can do about that other than to get them to fix their end though. The Wiz can only act on what it receives.

[peteru]

If the failing HDD locks up the kernel long enough while the drivers deal with error retries on the media, then there could be secondary issues, such as lost packets from the DVB drivers. This could then present as errors and discontinuities in the stream.

My advice would be to replace the faulty HDD, reflash firmware with the most recent beta available at the time and setup from scratch, without restoring settings. You may find that doing this cures all your problems.

If it does not help with the other issues, you will have increased confidence that those issues are caused by something else, such as dodgy broadcaster practices. It's always a good idea to ensure that the fault is not at your end before asking others to look into their systems.