• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

Stuck at START SYSTEM even with no hard disc

Owen Smith said:
Boxes that only see one region probably set the same thing automatically. I wonder where that setting is stored in the Humax?
Click to expand...
I'm not sure it is, I think RS deduces it from the mux list. So far as I can see, the region is only relevant to RS deciding whether to use your EPG data as a contribution to the overall RS EPG cache. The view of the EPG RS presents for any particular registered 'Fox is dictated by the relevant channel list.
 
Black Hole said:
I'm not sure it is, I think RS deduces it from the mux list.
Click to expand...
I had muxes manually tuned, I got the tuner up first because there was something I wanted to record. Then I had time so I put in the USB stick to put custom firmware 3.13 on. Then it was time for the recording so I let it record that while I had dinner, and then after the recording I did fix-flash-packages which restored the packages. This being a transplanted hard disc from the dead box the disc portions were all still there. RS had to be registered though because it's a different box.

So there were definitely manually tuned muxes at the time I first registered this new box with RS, yet it didn't set the region in RS.
Black Hole said:
So far as I can see, the region is only relevant to RS deciding whether to use your EPG data as a contribution to the overall RS EPG cache. The view of the EPG RS presents for any particular registered 'Fox is dictated by the relevant channel list.
Click to expand...
I didn't want to take the risk of strange behaviour. You believe that is all the region setting does, but you don't sound 100% certain. I decided better safe than sorry.
 
Black Hole said:
So far as I can see, the region is only relevant to RS deciding whether to use your EPG data as a contribution to the overall RS EPG cache.
Click to expand...
Not even that. It'll use the Network ID.
Owen Smith said:
I wonder how many boxes have been moved over the years and are still reporting their old region to RS?
Click to expand...
Not many because you need to retune to get it to work properly or even at all.
 
prpr said:
Not many because you need to retune to get it to work properly or even at all.
Click to expand...
But unless you de-register the box from RS and then re-register it, RS will still see the box as being in its old region when it was first registered. I did a full auto tune and it did not fix my RS region even after the schedule sync'd.
 
Something annoying I've found with this new vertical tuners HDR Fox T2: if I have custom firmware reboot the box, it never manages to tune into a channel after the reboot. It always claims the signal is scrambled or some such, I forget the exact wording but it's what happens when the box loses its encryption key I believe. If I put the box into standby and bring it out again then it is fine. This might sound trivial but it means I daren't use the RS feature Schedule Reboot as the box will then be stuck in a state where it can't receive anything until it goes back into standby. OK at 4:20am but not necessarily OK if you're trying to schedule a last minute recording.

Is this a common feature of vertical tuners boxes? I wouldn't know as it is the only one I own, but I've never seen this with the 4 horizontal tuners boxes I've used. One thing is for sure, given this behaviour and the different power supply if I buy any HDR Fox T2s on eBay I'll be avoiding vertical tuners boxes. I'm using this one because I have it but that doesn't mean I like it.
 
Black Hole said:
No. Encryption keys are not involved in live reception.
Click to expand...
It did seem odd to me, I agree they shouldn't be involved. Is the timeshift buffer not encrypted for HD channels? The box has definitely lost something though and putting it into standby and coming back out fixes it.

I had a quick look on eBay. There are a hell of a lot of HDR Fox T2s for sale for quite reasonable prices, and looking at the front panel VFDs being quite bright (even with the orange filter present) and the lack of wear on the remote buttons shows many of them haven't had much use. Every single one that shows the rear panel has horizontal tuners so it looks like vertical tuners are in the minority. I think I'm safe for future supply without even needing to buy one. It wasn't like this just over 10 years ago when Humax discontinued the HDR Fox T2 and I bought my spare boxes, no-one was selling them second hand.
 
Owen Smith said:
Is the timeshift buffer not encrypted for HD channels?
Click to expand...
It's encrypted whether HiDef or StDef, but it doesn't matter what the key is so long as the same key is used for decryption as encryption! The "scrambled" message is what you get trying to play a recording with the wrong key.
 
Turns out the "No Signal" on a soft reboot with vertical tuners has been reported before by @everthewatcher. I think for now we should assume it is common to all vertical tuner boxes until we see some counter examples (which since they're working probably no-one will report, why would they).

O

Post in thread 'What To Do with a Dead or Unwanted HDR-FOX, HD-FOX, or DTR-T1000/1010'

everthewatcher said:
The V2/REVised units seem to be pretty rare - I was lucky to find one on eBay when I bought my first. I wonder how many were produced compared to the V1/original.

FWIW the V2 will almost always claim 'No signal' after a soft reboot. Could this be linked to the issue 9200_fan has or is it the same on V1 units?
Click to expand...
Aha it's not just my newly pulled out of the loft and pressed into service vertical tuners box that does the "No signal" after a soft reboot. I think with two reports we should assume they all do this until proven otherwise. My desire to avoid any more vertical tuners boxes...
 
I recently had a similar event to this post. One of my HDR’s stuck at Start System. A few restarts, over a time period and disconnecting the drive made no difference.

I had a dilemma and I’ve no idea why I thought of trying to re-install the custom firmware, after all the USB pen drive was next to the humax and had the custom firmware thereon.
The humax started downloading and eventually had completed.
I removed the USB and restarted the box and after the normal start up sequence, everything was as though nothing had earlier happened.
Over the next few days the recovery was okay. I’ve recently been away from home for six days and feared that when I switched on the box from a cold start that the problem may re-appear. I’m pleased to say that was not the case and all was still well.

I have also since updated the custom firmware from 3.13 to 3.14 without issue.
I’ve no idea if re-installing the custom firmware did the trick or whether it was just a co-incidence.

Horizontal aerial connections.
 
Interesting and thanks for reporting. The only thing I can think of is some flash location was not reading correctly and reprogramming fixed it. Flash doesn't hold its contents forever, what I don't know is whether reading it frequently slows down or accelerates that wear. It might differ for NAND vs NOR flash too.
 
I dug out my failed box to see if this would fix it, only to find that it is now working fine after weeks of not working previously. There are no brown components in the power supply, and when it failed it did so even with the hard disc removed so I know it isn't that problem. I think in the absence of any other evidence I will assume it was probably the flash contents. Indeed I believe @Black Hole suggested that, but I ignored that suggestion due to some of mine and other people's history on this site with him. A clear example of annoying people resulting in good advice being ignored. I have of course re-flashed the box while it is working, with CF 3.13 since that is what it already has on it. It's going back in the loft, the front panel is very faded and the hard disc in it full of bad blocks and I can't be bothered to swap everything over again.

This has prompted me to re-flash all the boxes I look after, I don't want this happening to my parents' or my aunt's boxes. @prpr seems to have anticipated this requirement by releasing 3.14 :-).
 
If this problem with the flash is indeed the case, then why hasn't anybody reported problems with the boot loader?
As I understand it, that is just another segment of the flash (cat /proc/mtd).
This leads to another load of (rhetorical) questions:
  • What happens if the boot loader gets corrupted?
  • Is it worth re-flashing that as well?
  • Can you do it with the same version or does it just read what's there and ignore it if the same?
  • Can you downgrade without killing it?
  • How did the boot loader get in to the flash in the first place?
 
prpr said:
If this problem with the flash is indeed the case, then why hasn't anybody reported problems with the boot loader?
Click to expand...
It is very common for flash devices to have a few blocks either at the bottom or the top of the flash that the flash manufacturer says are more reliable. This is done by building them on larger feature sizes, or using less bits per flash cell (typically 1 bit instead of 2), or using stronger (or any) error correction on these blocks. This is specifically for this issue ie to ensure a boot loader is less likely to go corrupt.
prpr said:
  • How did the boot loader get in to the flash in the first place?
Click to expand...
In development likely over JTAG or other debug interface. In production it is quite common to have the flash parts pre-programmed by the flash supplier before they are even soldered onto the board. This is faster and also has the benefit parts that fail to program don't get used.
 
Owen Smith said:
I ignored that suggestion due to some of mine and other people's history on this site with him. A clear example of annoying people resulting in good advice being ignored.
Click to expand...
If people get annoyed by being faced with truths bluntly stated, that's their problem not mine. Perhaps they need trigger warnings.
 
I should added, re-flashing the boot loader is risky. If there is a power cut or the flashing fails in the middle for whatever reason then the device is likely bricked unless you have access to JTAG and the required files to flash a boot loader into a blank device.

Just programming the existing boot loader on top of itself (without erasing) won't necessarily fix anything. You have to understand how the flash technology works. I don't know the details for NAND flash but I do for NOR flash (I don't know which the HDR Fox T2 uses):
  • Erasing NOR takes all bits from 1 to 0 and then back to 1 again. So counter intuitively, erasing an already erased block is likely to be slower than erasing a block with data in or that is already all zeros. Some flashes however remember that the block has not been written to since last erased and skip the erase, but this is the minority of devices.
  • Writing NOR just changes bits that are a 1 to 0. Bits that are already 0 can't be changed by a write, and bits that should be a 1 in the data aren't actually written. On the plus side this means you can write the same location multiple times without an erase to clear successive bits. On the minus side this means if a bit that should be a 1 is the one reading badly sometimes, just overwriting the data won't help.
  • Erasing NOR is by the block, the sizes of which vary but are often 4K, 32K, 64K or 128K bytes.
  • Writing NOR is by the byte or the 16 bit word, but since you can clear a single bit it is really by the bit.
Before anyone asks how I know this, I've done it for a living at two jobs over the past 20 years.
 
You must log in or register to reply here.
Back
Top