Forum › Forums › Freesat HD › FOXSAT HDR › "Out of index" error messages all over Humax Foxsat-HDR menus
Tagged: firmware, foxsat-hdr, out of index
- This topic has 10 replies, 3 voices, and was last updated 5 years, 1 month ago by
Anonymous.
-
AuthorPosts
-
October 5, 2020 at 2:43 pm #13381
Anonymous
InactiveA few days ago, the menus on my Humax Foxsat-HDR suddenly started displaying “Out of index” on almost every field of the menus and displays although, not entirely surprisingly given the architecture of this device, all of the satellite channel data and other functionality is working properly. I’m (still) running Raydon’s “Media and File Server Bundle for the Foxsat HDR” version 4.1.3 and the unit still boots up properly, displaying that on the front panel display whilst booting.
I found an old thread on here about the display of these messages on the same model so I was fairly convinced that re-flashing this firmware (I never delete anything from my hard drives if it might be useful at some time in the future!) would resolve this and I happily fired up a FAT32-formatted USB stick and successfully re-flashed the Humax.
Wrong! It’s still exactly the same and despite a third re-flashing (“hope springs eternal”) nothing has changed. Perhaps some aspect of date processing means that 4.1.3 will no longer work?
October 5, 2020 at 2:50 pm #32946grahamlthompson
ParticipantStill working fine on my box. I was using the Webif earlier today. Have you reserved the box IP address to it’s mAC adress on your router. If not it may be using a different ip address.
A quick google suggests it might be terminal.
October 5, 2020 at 3:13 pm #32947Anonymous
InactiveThanks for the prompt answer, Graham, strangely I hadn’t found as many relevant posts on the Internet on Google as you did on Yahoo.
A change of IP address wouldn’t cause this problem as it’s being displayed on the HDMI display, not the WebIf, but knowing that it’s not firmware-specific helps with the debugging. I wouldn’t be too bothered if no-one had ever fixed this but spotting that a firmware re-flash fixed it for one affected user drives me on! Does anyone here have the .hdf file for the “latest” (ha!) official Humax firmware that I could use to see if anything changes?
By the way, as I couldn’t remember whether or not a firmware re-flash formats the hard drive, just in case I swapped out the one with all my yet-to-be-watched recordings on it and replaced it with another… so the hard drive isn’t likely to be the culprit.
October 5, 2020 at 3:30 pm #32948Anonymous
InactiveGreat news! (For me, anyway…!)
The factory reset, performed “blind” as described here after the re-flashing, apparently did the trick.
I’m just going to replace the correct hard drive and sort out all of my sat channels and scheduled recordings, and I will post again here to confirm that all is well.
October 5, 2020 at 3:48 pm #32949Anonymous
InactiveI wonder, statistically, what percentage of firmware reflashes actually fix the problem the user is having? Nearly all the threads that I have read report “still the same”. But a mains cycle or factory reset seems to work more often than not.
Similarly “I have upgraded the firmware but it’s no different”. Unless the upgrade actually addresses the problem that the user is having (despite the fact that others don’t have the problem), I fail to see what that will achieve either, as it frequently doesn’t achieve anything.
October 5, 2020 at 4:30 pm #32950grahamlthompson
ParticipantGraceCourt – 1 hour ago »
Thanks for the prompt answer, Graham, strangely I hadn’t found as many relevant posts on the Internet on Google as you did on Yahoo.
A change of IP address wouldn’t cause this problem as it’s being displayed on the HDMI display, not the WebIf, but knowing that it’s not firmware-specific helps with the debugging. I wouldn’t be too bothered if no-one had ever fixed this but spotting that a firmware re-flash fixed it for one affected user drives me on! Does anyone here have the .hdf file for the “latest” (ha!) official Humax firmware that I could use to see if anything changes?
By the way, as I couldn’t remember whether or not a firmware re-flash formats the hard drive, just in case I swapped out the one with all my yet-to-be-watched recordings on it and replaced it with another… so the hard drive isn’t likely to be the culprit.
Check your PM’s
October 5, 2020 at 4:40 pm #32951grahamlthompson
ParticipantGraceCourt – 1 hour ago »
Thanks for the prompt answer, Graham, strangely I hadn’t found as many relevant posts on the Internet on Google as you did on Yahoo.
A change of IP address wouldn’t cause this problem as it’s being displayed on the HDMI display, not the WebIf, but knowing that it’s not firmware-specific helps with the debugging. I wouldn’t be too bothered if no-one had ever fixed this but spotting that a firmware re-flash fixed it for one affected user drives me on! Does anyone here have the .hdf file for the “latest” (ha!) official Humax firmware that I could use to see if anything changes?
By the way, as I couldn’t remember whether or not a firmware re-flash formats the hard drive, just in case I swapped out the one with all my yet-to-be-watched recordings on it and replaced it with another… so the hard drive isn’t likely to be the culprit.
A firmware flash doesn’t format the hard drive. The firmware is held in NVRam. Some data is stored in the hard drive video partition.
October 5, 2020 at 5:21 pm #32952Anonymous
InactiveGraceCourt – 42 mins ago » … I will post again here to confirm that all is well.
Interesting point, Trev, thanks. To address this, and to provide as much diagnostic information as possible for anyone in future who has a similar problem, I’m going to list here everything that was tried.
I did try the “blind factory reset” quite a few times before the re-flash, without any luck, but TBH I wasn’t 100% sure whether or not I had the correct “PIN” that I had set many years ago. However, I could see that each key press for the PIN didn’t change the mess of lettering on the screen. On the basis that a firmware re-flash would reset the PIN anyway, I progressed to that and – as reported above – that didn’t seem to cure the problem.
I then went on to the “blind reset” again, and this time I could see that there were four asterisks on the screen, each of which changed as I typed the zeroes on the remote, and again as reported, this time the reset was successful.
However, on booting up, the firmware wanted to re-format the hard drive… and I don’t presently know why. As I don’t want to lose my recordings if possible, and an offline check of the partition table didn’t reveal any issues, I swapped it out for a spare one and I will investigate the original when I can.
Back to the Foxsat-HDR, after re-scanning for available channels and the associated usual set-up procedure, all is well. Thanks to those who responded to my original post.
Graham – taking that into account, it suggests that corruption of the video partition containing the non-NVRAM information is what causes this issue. So, the fix protocol seems to be:
(1) swap out the hard drive for a spare (either in case of hardware failure, or to protect existing recordings, or both);
(2) perform a factory reset (blind, if necessary);
(3) if that doesn’t work, perform a firmware re-flash and repeat (2).
Good luck!
October 5, 2020 at 5:29 pm #32953grahamlthompson
ParticipantGraceCourt – 5 mins ago »
GraceCourt – 42 mins ago » … I will post again here to confirm that all is well.
You can connect the hard drive to a PC booted into linux by slotting it into a usb drive cradle and copy the entire video recordings partition to a PC connected high speed drive as fast as your PC can run.
If you connect that to one of your Foxsat-HDR usb ports then you do not need the CF to play these back provided you have the original motherboard. Encrypted HD will still play back from a USB connected drive. You can even bring out the internal sate connections using a esata kit to record to a external drive in a cradle.
Interesting point, Trev, thanks. To address this, and to provide as much diagnostic information as possible for anyone in future who has a similar problem, I’m going to list here everything that was tried.
I did try the “blind factory reset” quite a few times before the re-flash, without any luck, but TBH I wasn’t 100% sure whether or not I had the correct “PIN” that I had set many years ago. However, I could see that each key press for the PIN didn’t change the mess of lettering on the screen. On the basis that a firmware re-flash would reset the PIN anyway, I progressed to that and – as reported above – that didn’t seem to cure the problem.
I then went on to the “blind reset” again, and this time I could see that there were four asterisks on the screen, each of which changed as I typed the zeroes on the remote, and again as reported, this time the reset was successful.
However, on booting up, the firmware wanted to re-format the hard drive… and I don’t presently know why. As I don’t want to lose my recordings if possible, and an offline check of the partition table didn’t reveal any issues, I swapped it out for a spare one and I will investigate the original when I can.
Back to the Foxsat-HDR, after re-scanning for available channels and the associated usual set-up procedure, all is well. Thanks to those who responded to my original post.
Did you get my PM to download the file for future safe keeping ? Incidentally it is also possible to reset a forgotten pin.
October 5, 2020 at 9:00 pm #32954Anonymous
InactiveThanks Graham, I’ve PM’d a reply.
Final wash-up… examination of the original hard drive revealed that it was not corrupt, but it had been shut down “uncleanly”, and there were four files with corrupt names in the “Video” directory that would have been recording when it crashed.
So, just “one of those things”. There are four partitions on the drive, all of type ext3, which is a journaling filesystem, so running ext2fsck (on FreeBSD) on each of the four partitions cleaned up the journals, and deleting the four corrupt files on partition 3 meant that the original drive could be returned to the Foxsat-HDR, which is now running smoothly with no loss of recordings except the programme that was being recorded at the time of the crash. All of the recording schedules were also intact.
October 6, 2020 at 3:39 pm #32955Anonymous
InactiveGraceCourt – 22 hours ago »
Interesting point, Trev, thanks.
Just to point out that my post was in no way a ‘pop’ at you, just a general observation having read numerous posts on the subject.
-
AuthorPosts
- You must be logged in to reply to this topic.