Further to the assistance provided in the discussion above, please feel free to peruse a summary of the full process I used to restore both recordings and the recording list, which I am pleased to say was successful. I posted this summary of the steps in the following thread, in case they might be of use to others at some point (and in case I ever need them again!)
https://myhumax.org/forum/topic/restoring-recordings-and-list-to-humax-pvr-9200t
Thanks very much
Sorry for the late reply, I have only just come across these two threads. I have not had time to fully digest the long thread yet but here are some thoughts about how recovery might be done.
The normal method of running humaxrw when the disk is assumed to be fine is to run it without the -r option. This will create .hre files containing all the data from the recoding list which will be restored when put back onto a new disk. In this mode the filenames are typically named as "YYYYMMDD HHMM Title.ts". The utility ts2hrw also understands this name format and will create a new .hre with the correct timestamp and title based on the filename.
If the recording list appears corrupt in the machine but you can get a sensible output from 'humaxrw n: -l" then it is likely that you will not need to use recovery mode to extract the files. It should be possible to use 'humaxrw n: -b' to get all the files with their filenames containing timestamp and title. Then if the assumption is made that some or all of the .hre files are corrupt, they can be deleted and then recreated using ts2hrw. It should then be possible to put the files back onto the Humax disk. The only data lost in this process is likely to be the channel name and number.
Hello
If the recording list appears corrupt in the machine but you can get a sensible output from 'humaxrw n: -l" then it is likely that you will not need to use recovery mode to extract the files.
I'm pretty sure this was unfortunately not the case for my situation: if I remember rightly, humaxrw would only copy files in recovery mode, but it is not impossible that I am mistaken or I was just unlucky. Maybe it was a consequence of the way my crash occurred, i.e., the box freezing just as I was editing the recording list? Although apparently this may well have just been a symptom of accruing corruption reaching a critical mass!
Regards
Just to clear up an omission which might have led to a misunderstanding, the references to use of the -l for the scenario described in the procedure from the other longer post I provided should have explicitly specified the use of -l in combination with -r, e.g. humaxrw n: -r -l
In my scenario, use of -l alone generates only an error complaining that the record list is empty/not found. I have added a clarification at the end of the other procedure (as linked to previously) in order to draw attention to this omission.
You must log in to post.
