9300-T drive corrupted, recordings invisible

My Humax Forum » Freeview SD » PVR 9150T, 9200T, 9300T

9300-T drive corrupted, recordings invisible

(15 posts)

CobaltUK

junior member
Joined: Nov '16
Posts: 8
offline

Struggling with Humaxrw and unsure what things can be tried safely, leaving other attempts still available if not work.

What happened. Unlucky that some glitch caused a re-boot (happens now and again) just at the very moment I was deleting a recording. I assume the write in progress but unfinished has left the contents corrupted and unavailable. Shows no recordings in menu.

Connected 500gb sata drive to win7 pc and humarw in -r -l shows the 430+ recordings. Though strangely there are 2 recording names given to each one and the -i option indeed describes appropriately the description for both. How this can be I don't understand beyond the fact that the 2 programmes have been repeatedly recorded/erased over the years as part of a long running tv series. Both named recordings would have been similar size. Typically 2hrs or so.

I see there is an option to swap a backup recording list.
Can this be swapped back and forth if gives no benefit in restoring the drive to use ? (so something else might next be tried)
Will a backup of a recordings list ever restore the drive to use in the circumstances I am in ?

I have successfully used the -r -g to move a sample ts file onto pc drive so maybe if all else fails there is some hope to save/watch recordings BUT that has to be a LOT less desirable than somehow getting the drive recording list/index restored to good health if it can be done ???

This subject seems to be now historic as most people seem to have moved on long ago to other products and software tools abandoned maybe.

If anyone in the UK can or knows of someone who can do a fix beyond what I can attempt myself then I would be happy to outsource the fix.

| Sat 12 Nov 2016 12:35:23 #1 |
Martin Liddle

special member
Joined: Feb '11
Posts: 4,685
offline

CobaltUK - 12 hours ago »
Connected 500gb sata drive to win7 pc and humarw in -r -l shows the 430+ recordings. Though strangely there are 2 recording names given to each one and the -i option indeed describes appropriately the description for both.

This bit I don't understand what is going on.

I have successfully used the -r -g to move a sample ts file onto pc drive so maybe if all else fails there is some hope to save/watch recordings BUT that has to be a LOT less desirable than somehow getting the drive recording list/index restored to good health if it can be done ???

I think the only way to restore the drive to health will be to copy off all the recordings, then format the drive in the Humax. On a 9200 you could copy the recordings back but this doesn't work on a 9300.

| Sun 13 Nov 2016 0:49:57 #2 |
xyz321

member
Joined: Jul '11
Posts: 34
offline

CobaltUK - 20 hours ago »
Connected 500gb sata drive to win7 pc and humarw in -r -l shows the 430+ recordings. Though strangely there are 2 recording names given to each one and the -i option indeed describes appropriately the description for both.

The reason you are seeing two (or more) different recording names in recovery mode is due to padding. In recovery mode it does not use the recording list, instead it builds a list using the epg data.

If padding is applied a recording may have say 5 minutes of a previous programme, the actual programme and the following programme. Each of these will have a description stored in the epg file with a timestamp for their respective lengths.

The listing you see in recovery mode lists each of these entries for a particular recording.

I see there is an option to swap a backup recording list.
Can this be swapped back and forth if gives no benefit in restoring the drive to use ? (so something else might next be tried)

It does just swap the main and backup lists. If you put the disk back into the machine it may overwrite one or both of these lists so swapping back may not be useful.

I would suggest running "humaxcheck" before replacing the drive. It will not fix your recording list but may find and fix other problems in the file system.

| Sun 13 Nov 2016 9:05:39 #3 |
CobaltUK

junior member
Joined: Nov '16
Posts: 8
offline

Thanks both for your advice. Ordering new drives both for copying to and in case unit drive defective.

| Sun 13 Nov 2016 9:57:08 #4 |
CobaltUK

junior member
Joined: Nov '16
Posts: 8
offline
Decided to try Humaxcheck as suggested.
Attachments
1. Humax_drive.PNG (35.8 KB, 4 downloads) 8 years old
| Sun 13 Nov 2016 17:03:19 #5 |
CobaltUK

junior member
Joined: Nov '16
Posts: 8
offline

Which of the available fix options would be best/safest to try ??

Various allocation errors, cross linked block, improper file termination in FAT

6 corrupted files plus blocks allocated to orphaned chains seems to be the factors in Partition 0
Unsure but Partition 1 and 2 Ok ??

Any options that SHOULD NOT be used ? Thanks

| Sun 13 Nov 2016 17:09:16 #6 |
xyz321

member
Joined: Jul '11
Posts: 34
offline

Try a dry run with the '-a' option (which will not make any changes to the disk). If that looks good then repeat with '-a -w' options to save the changes.

BTW the recording list is saved on partition 1, so it is very unlikely to fox that.

| Sun 13 Nov 2016 17:57:24 #7 |
CobaltUK

junior member
Joined: Nov '16
Posts: 8
offline

Ok just tried the -a option (sounds like nothing actually gets done to drive without the -w ? )

Result not clear to me so not yet risked a write.

PARTITION 0
81.elu : Err Frag 3, size: 1531392 Alloc fat 3760, dir 3760
Warning - File size error

80896 blocks allocated in orphan chains taking up 31146901504 bytes
Humax calculated free space count: 6087614464 bytes

| Sun 13 Nov 2016 18:27:44 #8 |
xyz321

member
Joined: Jul '11
Posts: 34
offline

I think the "file size error" problem is something that is not handled by "humaxcheck". In this case it means that the actual space reserved on disk for a particular file is larger than it needs to be. This shouldn't cause a problem. This would have been fixed if the space resereved was less than the file size.

If you want to release the space allocated to orphans then add the "-c" option. Orphans are areas of the disk which are marked as being in use but are not actually used by any file.

| Sun 13 Nov 2016 20:52:03 #9 |
xyz321

member
Joined: Jul '11
Posts: 34
offline

I forgot to mention that the cross linked files are likely to be corrupt. The listing above indicates that two or more files share the same area on disk. Humaxcheck "fixes" this by truncating the files at the point just before they become joined.

You may wish to run "humaxrw -r -l -x" to identify which recordings are likely to be corrupt/truncated.

| Sun 13 Nov 2016 21:06:56 #10 |