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

Restoring recordings and list to Humax PVR 9200T

(9 posts)
  1. User has not uploaded an avatar

    ergolargo

    member
    Joined: Nov '16
    Posts: 17

    offline

    This post is a follow-up to the thread I started here:

    https://myhumax.org/forum/topic/procedure-for-creating-recording-list-in-humaxrw?replies=1#post-53778

    containing my query about salvaging the recordings from a Humax PVR9200T, after the recording list was lost when this Humax box crashed while the recordings list was open.

    Just for the sake of completeness, and in case it might help any other Humax novices who experience the 'logical' disk corruption that causes the recordings list to disappear, I should like to report back with a summary of the process that I successfully used on a Windows system to restore the recordings onto the list in the Humax menu system, based on the advice received in the above thread, but also incorporating the changes necessary to include the original program titles. Be warned though, it is quite a long read, but this is because I wanted to include everything to make it a full comprehensive procedure that can be followed from start to finish! Of course, this advice is provided on an advisory basis, with all the usual disclaimers in the unlikely event that something goes wrong with your Humax disk! I documented the procedure as I went along in case I needed to remember it myself in future, and I thought that it might be useful to post the procedure in a separate thread in case others might ever want to find it.

    Just to clarify, my original query was about finding a way to restore the names that appear in the recordings list, which are omitted when following the default restore procedure with the humaxrw and ts2hrw tools, during which procedure the original program names are replaced by a list of 'recover' type names, which are impossible to distinguish without going in to view the recording. This is because unfortunately, when the ts2hrw tool is used to create the new set of hre files, it does not automatically update each hre file with meaningful program titles, the idea being that this must be done manually using the Humax interface and remote control after the restore is completed. My motivation was to do the renaming during the restore process, to avoid having to use the Humax interface, which you may or may not agree would be an extremely tedious way of doing the renaming. It should be said that my method is also still relatively tedious, and would probably take at least a whole day to carry out, not even including all of the transfer times back and forth from the disk, but I am sure this is much quicker than the extra time required for doing it all by Humax remote control, especially while people are nagging you for hogging the telly for so long! It was definitely more practical in my case anyway: for my box, which turned out to have a 320GB disk nearly full of over 300 recordings, I think I just would not have bothered otherwise - but I appreciate that many would just not bother doing my procedure either, which as I present it here probably has scope for improvement with further automation, especially at the last hre file stage, as will be clear later.

    The only info I was unable to restore was the original dates of the programs, which I believe must be determined in the Humax simply from the date stamp given to the original file when it is recorded - obviously, as salvaged files are copied from the original Humax disk, before the restore can then take place to a newly formatted disk, the recordings files are all new files that are stamped with a new creation date/time, and so all show the same date: the original date info is unfortunately lost.

    Restoring the program titles is a bit more complicated than the default procedure, and involves extracting the program information provided by the humaxrw -l or -i options, organizing the lists in a spreadsheet application, and ultimately, the key stage involves some elementary 'hacking' of the hre file for each recording: the set of hre files appears to be the source from which the Humax box will extract each entry in the restored recordings list. This answers my question in the original thread about regenerating the list: as far as I can tell, the list is recreated by the box only when files are copied back onto a newly formatted disk - I was unable to determine the exact location of this list in terms of a file on the disk, and as it stands, I believe that any such file cannot be accessed or edited directly through humaxrw anyway - it seems possible that the list may simply be created 'on the fly' by the box the first time that the Humax menu or recording list is accessed, as explained by the behaviour of the box at the end of the procedure provided below.

    The process is not as difficult as the long length of these instructions might suggest. Much of the process given is just the standard procedure you would use anyway; it's just that I have included the modifications needed to regenerate the recording names in some detail, because otherwise there are 'gotchas' that could disrupt the success of the procedure. As I mentioned already, the biggest problem is really the time taken up by the steps towards the end of the procedure, so if anyone plans to go through with this process like I did, it is best to read through all the steps in full to make sure you feel it is worth the effort involved!

    Feel free to offer any corrections, but my version of the procedure, hopefully detailed enough for the Humax uninitiated (though I am assuming a certain level of experience with file management and text file editing), is tried and tested to success, and is as follows:

    | Tue 22 Nov 2016 10:17:29 #1 |
  2. User has not uploaded an avatar

    ergolargo

    member
    Joined: Nov '16
    Posts: 17

    offline

    IMPORTANT DISCLAIMER NOTICE: Under no circumstances should you open the Humax box while it is still connected to the mains or the TV. Also, if your box is still under guarantee, opening the case of the box, as in this procedure, will invalidate your warranty - when my disk first crashed while the box was still under warranty, I decided not to risk using humaxrw, waiting
    until recently to experiment with it. Discharge yourself of static before starting this procedure, and do not touch any other part of the interior of the box apart from the disk connectors. Avoid touching any capacitors, especially!! Follow this procedure at your own risk.

    1. After putting the Humax box into standby, turning off the power and disconnecting it from the mains and the TV, open the case of the Humax box and unplug the power and IDE connectors from the hard drive within.
    2. Plug the Humax disk into power connector provided with the USB-IDE adaptor but do not switch on yet.
    3. Plug the Humax disk into the USB-IDE adaptor cable, but do not connect cable to computer yet.
    4. Switch on power to the Humax disk and allow it to spin up.
    5. Connect the USB end of adaptor to the computer - ensure that the disk has not been provided with drive letter, and do not initialize the disk in an attempt to do so.

    6. Navigate to a new, empty folder into which you want to copy the salvaged files, and make sure it has enough free space to accommodate the capacity of the files on your Humax disk, e.g., if a 320GB Humax disk is about half full, make sure you allow an adequate ceiling of closer to 180GB.

    If you can allow double that amount of space, this will also enable you to make an optional additional backup copy of the Humax files (see later).

    7. Using humaxrw n: -l, specifying the location of humaxrw elsewhere on the computer system as necessary, determine the humax disk number n. E.g. 1: 2: etc. The correct number will give a disk capacity matching that of your Humax disk.

    8. Use humaxrw n: -l > filenameslist.txt (example filename) to create a cleartext file listing the titles of all the salvageable recordings.

    9. Use humaxrw n: -i > fileinfo.txt (example filename) to create a cleartext file of all the program info for each of those recordings, as contained in the set of all the epg files, one for
    each recording. On my box, I found that, especially for the output of the -i option, which extracts the epg info, this output included the names of deleted programs, or the names of the
    programs that were broadcast immediately after the recorded programs - I believe both of these issues are just cosmetic glitches, to do with, respectively, the way that the Humax recycles disk space, and recognizes the start and end of programs as it records them, and I suspect it is best not to attempt to tidy up the epg files: generally the first item is the correct one matching the recorded content, and the other information is generally ignored by the box, although occasionally it does trip up and get confused, and so displays incorrect program information, in which case the correct info is not the first option. If you can be bothered, this procedure allows you the opportunity to note down such problems so that you can address
    them later.

    10. Use humaxrw n: -g *.ts to copy salvaged recordings data from the Humax disk. On my Win7 laptop, it took about 3 hours to copy around 300MB onto an external USB drive, and that was with the USB policy setting in Device Manager changed to 'Better Performance' on both USB devices (the disk and the adaptor) - I believe the default 'Quick Removal' policy setting could have
    taken twice as long, but obviously I didn't test this theory! Also I disabled virus checking to stop any AV program trying to monitor the content of the files, though possibly this was
    unnecessary. The new copies of the files are given new 'recover_nnnn' filenames. Please note that when using USB devices in the 'Better Performance' mode, you need to make sure you always unload the device manually (e.g. using the system tray USB device icon), before you physically disconnect a USB device, otherwise there is apparently a risk of corrupting the data just copied on a disk.

    11. Do an inital 'exploratory run' with ts2hrw.exe *.ts to see if there are any *.ts files which will hang ts2hrw. I had half a dozen, but ts2hrw can only find one of these at a time before hanging, obviously. I don't know why this happened with my files, perhaps it was damage as a result of a different logical corruption, but possibly it is just a bug in ts2hrw, as I found
    that the ts files in question can be retained and played on a laptop with no problems. However, when ts2hrw hangs on a particular ts file, this means it will be unable to generate a new hre file for that ts file, and therefore the recording cannot be restored back to the Humax disk; instead the ts file for that recording must be cut and paste elsewhere, and removed from the
    working directory, to be viewed at your leisure another way, e.g. VLC Player. The other files for each of those recordings can probably just be deleted, I don't think they are relevant to a
    desktop video player application like VLC Player etc. The hre files that are successfully generated at this stage are unfortunately not too useful if we want to restore the lost names to the recorded list, which is the whole point of this procedure; they just contain a generic label instead of the program title, an issue which we must work around later by creating hre files
    again and editing their content - but at this stage it is essential that we use the ts2hrw for an initial run in order to eliminate all the ts files that will hang ts2hrw, so that the procedure will now run through a batch of all the remaining ts files without hanging.

    12. An optional stage here is to make a backup copy of all the remaining files, which we are about to subject to a renaming procedure. I did this because I was unsure that the renaming
    procedure would work, and needed to be able to fall back to the originals in case of a problem with the processing I carried out. Of course, I found that the renaming procedure was successful, so you may consider that such a backup is unnecessary. But if you are not entirely confident with the procedure at this stage, I would recommend making an entire copy of the folder containing the salvaged Humax files, to make sure you retain these original files in the state you had them immediately after you copied from the Humax. Then if something does go wrong during the rest of the procedure (unlikely), you only have to return to this step in order to try again, without having to copy all the recordings over again. Obviously, this does mean that you have another wait of several hours, especially if you have to make the copy on the same disk, which will take significantly longer than the original copy process, but you can at least get on with the next step in the meantime, while the copying is ongoing.

    | Tue 22 Nov 2016 10:25:35 #2 |
  3. User has not uploaded an avatar

    ergolargo

    member
    Joined: Nov '16
    Posts: 17

    offline

    13. The next step is in preparation for automatically renaming all the salvaged files with names that are more useful and easy to tell apart. Use the program list file (and the info file where
    it proves to be useful) created earlier to generate a list of new filenames to be used later in the procedure. The Humax box doesn't actually need anything else other than the default 'recover' filenames, but it makes working with the files a lot easier later if you can first change them - this can be done automatically with a batch renamer application such as 'Bulk Rename Utility' (free download). This utility includes an option to import a list of 'before and after' filename pairs, in the format 'old_filename|new_filename' with a pipe character in the middle of each pair, and each pair on a new line. This file can be created by amalgamating in a spreadsheet the following two lists of data:

    a) the old names: created from a directory listing of the new 'recover' *.ts files, sent to file output, i.e., dir *.ts > filedirlist.txt (example filename)
    b) the new names: constructing a list of the program titles extracted from filenameslist.txt (with crossreferencing from fileinfo.txt (created earlier) where necessary, in case additional info from this second file is important (season or episode no, for example))

    The list of these pairs is processed by importing each of the two above sets of names as a delimited file into a spreadsheet, allowing the extraneous data, and in the case of the new filenames, any illegal characters to be removed. The list of new program titles will probably need to be exported again as a CSV, and turned back into a TXT file in Notepad or any cleartext
    editor a few times before it is ready to be added as a column to the final paired list - I found a few cycles of this processing were necessary before the renaming file was 'moulded' into the
    correct paired format, as given above, but this is not so difficult, and doesn't need to take a massive amount of time to get right. The hardest part is just keeping in mind which filenames to use for each new version of the CSV file as you create it, and which delimiter is best for splitting columns. My spreadsheet only allowed a single custom delimiter to be specified, which was a bit of pain, but maybe yours is more flexible.

    I am uncertain as to the set of illegal characters for the Humax filenames - to be safe I edited out occurrences of everything not part of the standard alphanumeric set, i.e., exclamation marks etc, that would not be allowed in a Windows/DOS filename - space characters can be left in though. No doubt other characters could have been too, but there were not too many of these changes to make so it was hardly worth experimenting further. Importantly, I retained the 'nnnn' values from the recovered filenames, appending these 'sequence numbers' to the new filenames - this is also very helpful later in the process, allowing files to be distinguished by yourself, and ultimately they can be used to
    denote the default sequence used by the Humax when it is ready to list the restored files through its own interface - the numbers are not as good as having the date for each recording, but it will allow some sequencing of recordings to be worked out, even if you just note down the order of programs as you go along, when watching them, at a later date. You may prefer to have this number at the start of the restored filename, e.g., have renaming pairs as follows:

    recover_0001.ts|0001_A Film Called This.ts

    There may be other fringe benefits to this format during the 'hacking' process below, but I decided to opt for:

    recover_0001.ts|A Film Called This_0001.ts

    as this would enable the final set of films to ultimately be sorted alphabetically back on the Humax box, making things easier to find (remember that, for these restored files, you will no
    longer be able to sort by their original recording date, as this data is unfortunately lost.)

    14. When you have constructed the completed version of the paired filenames listing, check the paired *.ts file names carefully against the directory listing of ts files, to make sure you haven't inadvertently missed out or added one or two names during the copy and paste processing in the spreadsheet, and to make any other manual changes. For example:

    recover_0001.ts|A Film Called This_0001.ts
    recover_0002.ts|A Film Called That_0002.ts
    recover_0004.ts|A Documentary Called Something Else_0004.ts
    .....

    In this example we needed to lose file 0003 because it was one of the files that ts2hrw refused to process, as explained above. So we needed to ensure it was removed from this paired list of filenames. It is worth checking this list of filenames carefully, as a mistake at this stage can cause confusion later on.

    15. Using a simple search and replace in the text editor, create equivalent matching lists in separate files which substitute the file endings .elu and .epg for the .ts filenames you worked with in the previous step, so that you have three separate files, one for each of these three file extension types, finalrename_ts.txt, finalrename_elu.txt, finalrename_epg.txt (example filenames).

    Also create a separate text file, e.g., finalnamesonly.txt (example filename) containing a 'single column' list of all the final names, without file extensions. This will involve importing one of the files from step 15 back into a spreadsheet to strip out all the old names and file extensions. The finalnamesonly.txt file produced here is useful in the final stages below, when we get around to our basic 'hack' of the hre files.

    16. In our working directory, which will probably still contain the hre files that we experimentally created in step 11, cut and paste those hre files to a different location, so that the directory again holds only the ts, elu and epg files. Don't discard the hre files though, as some of them might be useful for practicising with before we carry out the final hre file hacks.

    17. Use the Bulk Rename Utility (or similar) to commit all these changes to the filenames. In Bulk Rename Utility itself, you have to do the following for each set of paired names, i.e., for each of the three rename files from step 15:

    a) Import the list of pairs using the Actions menu
    b) Select the working directory containing the ts, elu and epg files
    c) Select all the files in the directory
    d) Choose the Rename button at the bottom of the window.

    This has the effect of renaming all the files matched in the list provided, i.e., for each pass, it renames all the files with a particular extension. The changes are marked in a different colour. I restarted the utility each time to see the changes coloured fresh each time, but this was probably unnecessary. After carrying out the substitution through each of the three lists, check the directory listing to make sure you have a complete set of renamed ts, elu and epg files, and that there are no extraneous files that might cause confusion later.

    18. Now we are the stage where we can create the hre files proper, using the ts2hrw.exe *.ts process to create the hre files from the renamed sets of recordings. Because we eliminated any problematic files earlier, the process should complete without any problems, but double check the directory listing afterwards to make sure a full set of hre files is created, one for each
    ts file. To summarize, we should now have four files for each recording: the ts file (the actual video file for the recording), and the elu, epg and hre info files. The hre files are used by
    the Humax box to construct the recorded list viewed in the Humax interface. At the moment though, the hre file only contains a generic label, as unfortunately the ts2hrw tool does not automatically update the hre file with meaningful program info, as explained at the start of this post, and which is in fact the cause of all this extra work we have to do in the following
    final steps.

    19. The hre files are binary files, and so to 'hack' them so that they will feature the names of the recordings, we need to use a Hex Editor application for directly editing the hexadecimal data in binary files: so you need to now make sure you have a good hex editor installed. I used the free program HxD, which presented no real problems at all. I believe the key to success at this stage is to always start the edit using the Paste Write option in the Edit menu, as explained below, as this ensures that the hre file does not change size. In other words, to change the content of the hre files, you need to always make sure you are overwriting the original data created by the TS2HRW process, and avoid adding or deleting any data that would change the file size. HxD warns you repeatedly each time you do inadvertently make such a change, though, so it is easy to avoid making this mistake: I admit I didn't actually test the effects of changing the hre file size, as I would assume such changes could easily be problematic for the Humax box, and I would therefore not be surprised if the restore failed as a result, but of course I may be wrong about this, as I didn't dare test the theory! I understand that the prospect of directly editing binary files in this way may not exactly be fascinating for most of us, and it is indeed the most tedious part of the process, but it proved to be not at all difficult once you have the hang of it, and with a bit of judicious cutting and pasting, I found it was possible to get through a whole disk's worth of hre files in about 3-4 hours,
    including several short breaks, completing the edit of each file in less than 30 seconds most of the time. Certainly no longer than a minute would be necessary on average, if that helps in making an estimate of the time required.

    20. If you create a copy of one of the hre files you produced in step 18, you can open it to see that the file data includes a section beginning 'Recovered unknown ... ' and ending with
    'TS2HRW'. For each recording, this will be the info displayed in the final recorded list that the Humax box constructs, the first piece of info being the program name, and the last being a substitute placeholder for the TV channel. I'm not sure if there needs to be any space left between the two pieces of data, so in the process below, perhaps it is sensible to do what I did, and make sure that the new program name is shortened if necessary so that it does not extend onto the line occupied by the 'Channel Name' - this is probably similar to the measures taken by the box itself when it makes a recording of a program with a long name. I didn't bother changing the text 'TS2HRW' text to a channel name, as for me it was not worth the effort, but this is probably possible if you feel you would like to. But it might be best to keep it as 'TS2HRW' anyway, so you can easily distinguish these recovered recordings from new recordings that you go on to make afterwards. You also have the extraneous hre files copied out of the working directory in step 16 that you could practice with first if you are not confident about using a hex editor yet, before you go on to start the edit of the hre files proper.

    | Tue 22 Nov 2016 10:36:26 #3 |
  4. User has not uploaded an avatar

    ergolargo

    member
    Joined: Nov '16
    Posts: 17

    offline

    21. In Notepad or similar text editor, open at one side of the screen the list of program names that you created at the end of step 15: i.e. the finalnamesonly.txt file containing only the list of the file names in sequence number 'nnnn' order. This is in a different order to the alphabetical order in which files are listed when you open the directory listing in the Hex Editor, unless you chose to rename them with the 'nnnn' sequence number first, e.g., 0001_A Film Called This.ts, in which case you may want to sort them automatically in any text editor or spreadsheet that supports this function. I didn't bother with this though, and just used the text editor to search for the sequence number of each program name that I wanted to use.

    22. Open HxD, the hex editor, on the other side of the screen: we are ready to start our 'hack' of the hre files:

    23. In HxD, Choose File > Open, and navigate to the working directory. You can type 'a' straight away to get a list of the file names beginning with a. Choose the first hre file, and the
    hexadecimal code for this file will be displayed.
    24. Copy the new program name from the list you opened in step 21.
    25. Click on the ANSI display of the data on the right-hand side. You need to position the insertion point/cursor immediately before the 'R' of 'Recovered' - it is VERY IMPORTANT to get the cursor in the correct position, otherwise you will be overwriting the wrong data in the next step.
    26. Choose Edit > Paste-Write, and you will see the pasted title of the recording now displayed in red.
    27. For short titles, you may need to tidy up the hexadecimal by adding a few extra 00 codes to blank out any remaining characters left over from 'Recovered unknown'.

    The important thing to remember is to always make sure the 'TS2HRW' text has not been displaced to a new position, and that you fill in any corrections by overtyping, rather than trying to
    edit with the delete and backspace keys, as in a usual text editor. Always blank out any extraneous 'left-over' characters by overtyping with new '00' hex characters (just type 0 then 0, as many times as you need to.) The edited section of data should always look similar to this:

    i7A Fi
    lm Called This_0
    001.............
    .............TS2
    HRW

    where the 'i7' at the start remains always unmodified, and in my case, I always left 'TS2HRW' unmodified too. Using HxD, this left 13 blank '00' characters before the start of 'TS2HRW', padding out the space before it on the same line. As mentioned earlier, the data is probably more flexible than this, but I erred on the side of caution so I did not introduce any unnecessary problems. I calculate this to be an allowance of 36 characters for the recording title itself, including the salvage sequence number nnnn, but if you don't have as many recordings to plough through as I did, you may feel comfortable experimenting with a) trying longer titles that extend right up to the start of the 'Channel Name' = 'TS2HRW', or b) changing the channel name itself if this is relevant to you. But whatever you changes you make, the requirement to keep the file size the same means that there should always be a total of 49 characters from the first character of the title ('A' in the example above), to the start of the channel name, which defaults to 'TS2HRW' as the source of the recording after you use the TS2HRW tool during the Humax restore process. The first section will be the name of the recording, followed by padding of '00' characters up until the 49 character limit is reached. The 'TS2HRW' text should never move from its original location.

    28. Save the hre file (you will notice the red modified text reverts to the default colour), and then close it (or just close it and remember to choose save when the dialog queries you about unsaved changes.)

    29. You can then repeat the process from 23-28 for every program beginning with 'a', and indeed every other letter of the alphabet! You can speed scroll down the list until you reach the last bak file created - the next hre file to edit will be the next hre file below it. Of course the File > Open box displays the entire list of all the ts, elu and epg files in the same directory, so don't waste time opening up the wrong type of file by mistake. Once you get into the routine of it though, you can probably go even quicker, using the appropriate command key combinations as appropriate: eg, CTRL + C to 'Copy' from Notepad, and CTRL + B to 'Paste-Write' into HxD.

    30. You will notice that HxD creates a 'bak' backup file for each hre file you modify. Of course this is useful if you realise you have recently made a mistake, but I found that at the end of the process, I was ready to just delete all the bak files without needing to cross check back to the originals. You may prefer to move them all to a temporary location at least until you have seen the entire process through to completion, when the Humax box is restored and proven to be displaying all the recordings properly.

    31. I found that for me it was often quicker to just type the new name directly into the hre file in HxD, rather than doing the 'Copy from Notepad, Paste-Write in HxD' step. Conversely, if there are a number of programs from a series all with the same name, it is quicker to copy and paste the standard section of the name, and then type in the changing section of the name, e.g., an episode subtitle, series number, or sometimes just the sequence number nnnn, which of course always should be included. For me, working in this way was quicker than always pasting in the
    new title. However, this does mean you have to pay more attention. If you prefer to just 'zone out' of what is already a very boring process, you may just prefer to continue with the mechanical cutting and pasting while listening to something on the radio!

    | Tue 22 Nov 2016 10:45:41 #4 |
  5. User has not uploaded an avatar

    ergolargo

    member
    Joined: Nov '16
    Posts: 17

    offline

    32. At the end of the hre edits, you now have a set of modified hre files that are ready to be processed by the Humax box when the ts files are restored to the box. However you must first attend to the reformatting of the Humax disk. Of course this is done back through the Humax interface, so you need to go through the process of reconnecting the Humax disk to the Humax box connectors, as follows:

    33. Unload the USB-IDE adaptor by using the Remove Hardware tool on the system tray. If there is any difficulty unloading the device, and you have your USB drives in 'Better Performance' mode, it is probably best to shutdown Windows.
    34. Physically disconnect the adapter from the computer, and restart the computer if it was just previously shutdown.
    35. Turn off the power to the Humax disk.
    36. Disconnect the power supply to the disk.
    37. Disconnect the USB-IDE adaptor from the disk.
    38. Reconnect the IDE adaptor within the Humax box.
    39. Reconnect the power adaptor to the box.
    40. Replace the case but leave the screws out just for the moment.

    41. Reconnect the Humax box to the TV etc., and reboot it. Go into the menu system as during usual operation but then go on to choose the format disk option.

    42. Repeat steps 1-5 at the beginning of this procedure, to connect the Humax box back to the computer.

    43. Navigate back to the working folder containing all the ts, elu, epg and hre files, which are ready to be restored back to the newly formatted disk.

    44. Use humaxrw n: -l to check that the humax disk number n is still the same. E.g. 1: 2: etc.

    The correct number will give a disk capacity matching that of your Humax disk, which will now be nearly empty. If the disk number n changed, just use the new number instead.

    45. Use humaxrw n: -p *.ts to start the long process of copying the files back to your Humax disk. At first humaxrw may report that the recording list is empty: this is to be expected on the newly formatted disk. Also agree to the disclaimer warning of disk damage: I found that there were never any such problems using the -p option to put the files back onto the Humax disk.

    46. When the transfer is completed, repeat steps 33-40, replace the case and screws, and then reconnect the Humax box to the TV system again.

    47. I think it is best to be careful when going back into the Humax menus to check the newly restored recordings. This is because I believe that the first time you enter the menus, the Humax box still has to do some work to regenerate the recording list from the new set of hre files it has found, and the box is therefore relatively unresponsive at this stage. I am not sure, but I think it may be necessary to navigate into the list at least once for the box to realise it needs to regenerate the list - it is difficult to test this without starting all over again with a newly formatted disk, which of course I am unlikely to consider for a while! But in any event, I have found that repeatedly pressing controls on the remote when the box is busy recording etc can sometimes trigger a crash, so at this stage, while the box is busy working out the content of a new recording list, it is essential to allow it a minute or so 'breathing space' between each choice of menu selection: it may take a couple of minutes for the box to become fully responsive again, by which time it has become ready to use the fully populated new
    recording list. Allow the box to slowly recognize your choices on the remote, until you open the recorded list, but don't try to navigate through the recorded list even when it first appears.
    Don't switch the box into standby thinking it has crashed, and don't be tempted to reboot it. I exited out of the recorded list quickly when I realised the box was in this 'go slow'/busy mode, and left it to get on with initializing the new list, or whatever else it was doing, but the next time I entered the list everything was as it should, with a newly created list displayed without problems.

    48. You have finished! The only info missing from the list, as explained in the introduction, was the original dates of the recordings, but it appears that the new recordings are listed by
    default in the order in which they are sequenced by 'nnnn' number, which appears to correlate with the order in which the files were originally copied, and therefore their creation time,
    (which is what you would expect really), when using a sort order of date/time. Of course you can always sort them alphabetically if that makes it easier to find things. New recordings will be
    inserted at the start/end of the list as usual, if the list is sorted by date/time.

    | Tue 22 Nov 2016 10:51:31 #5 |
  6. User has not uploaded an avatar

    ergolargo

    member
    Joined: Nov '16
    Posts: 17

    offline

    Possible improvement to the process:
    The point I made in the preamble was that I imagine there will be a better, more automated way to edit the hre files instead of the protracted process I describe in steps 21-31, possibly making use of a 'Find And Replace Text' utility for binary files (yes the standard acronym really is 'FART'), or some such other grep utility. Someone could even write a standalone C#/VB.NET standalone utility, for example, to go along with the existing Humax tools, as the .NET file processing library contains many methods/properties that could do it easily, but on this occasion I judged it was just as quick to do it manually. The trick would be to find or create a utility that could i) find the position of the 'Recovered unknown' entry in each hre file, and then ii) substitute into the hre file at that point the name from the list file created at the end of step 15, i.e., the finalnamesonly.txt file, by finding the entry using the sequence number found in both the new filename for the hre file and the version of it found in the list of names. The utility would just have to ensure that the size of the hre file was not changed.

    Hopefully this expanded version of the standard procedure might be useful to others, if anyone else is prepared to go through this process of recreating the list of recording names. Hopefully I won't have to think about doing it again for a couple of years!

    Regards

    | Tue 22 Nov 2016 10:53:31 #6 |
  7. User has not uploaded an avatar

    ergolargo

    member
    Joined: Nov '16
    Posts: 17

    offline

    CLARIFICATION: The references to use of the -l switch in the steps outlined towards the beginning of this procedure should have emphasised that the -l switch is here to be used in conjunction with the -r (recovery switch).

    e.g. humaxrw n: -r -l

    | Thu 1 Dec 2016 0:53:40 #7 |
  8. User has not uploaded an avatar

    ergolargo

    member
    Joined: Nov '16
    Posts: 17

    offline

    I thought at the time it might come in useful for me if nobody else to have all this procedure documented in full here - I was right! I had to do this procedure again after my recording list got corrupted again during a deletion of a recording - as I may have suggested last time, this issue definitely seems to be more likely to occur as the disk gets into its last 5% of space: my advice is to avoid that last bit of disk space like the plague!

    But after following my own instructions again, I thought I should restate the instructions in steps 7-10, just for the sake of completeness, as there are a couple of inaccuracies in my original text above. The relevant commands should be as follows:

    humaxrw n: -r -l
    humaxrw n: -r -l > filenameslist.txt
    humaxrw n: -r -i > fileinfo.txt
    humaxrw n: -r -g
    (Note that I was incorrect to include '*.ts' in my original text for this last command.)

    Though it does appear that the n: disk number can also be placed at the end of the command instead, according to the humaxrw help file.

    Also I noticed that the automatic text justification is misleading for the ASCII example code shown in step 27. All the lines of the text starting with 'i7' should properly be shown as justified, aligning at both sides, and the first short line not quoted in full should be right justified against the right side of all the others.

    I'll try to have another go but it will probably go wrong - if it is confusing just ignore the justification of the example and focus instead on the contents of your Hex Editor!

    Step 23 example again:

    [Ignoreme]i7A Fi
    lm Called This_0
    001.............
    .............TS2
    HRW

    Hope these additions help to reduce any confusion for any other determined Humax hackers!

    | Wed 12 Jul 2017 15:33:01 #8 |
  9. User has not uploaded an avatar

    ergolargo

    member
    Joined: Nov '16
    Posts: 17

    offline

    Of course I managed to miss something else out from the -i and -g commands.

    These commands need you to include the range of the recording entries you want to process, as listed in the original -l command.
    So the full set of commands at the start of the process should be:

    humaxrw n: -r -l > filenameslist.txt
    humaxrw n: -r -i x-y > fileinfo.txt
    humaxrw n: -r -g x-y

    where x is the 'l' number of the first valid recording, and y is the number of the last recording. (I usually get a couple of 'buffer' entries at the start of the '-l' list, which I assume represent some kind of system only placeholder for the Humax system, not recoverable recordings, so your 'x-y' entry will probably be something like '3-203' if you have 200 recordings, missing out the buffer entries of 1-2.

    humaxrw n: -r -i 3-203 > fileinfo.txt
    humaxrw n: -r -g 3-203

    | Tue 14 Nov 2017 19:06:46 #9 |

RSS feed for this topic

Reply

You must log in to post.