New firmware Version 1.03.12 for HDR-FOX T2

Still not working for me. The WebIF doesn't even show a new download starting to replace the previous buffer contents. "Exit" doesn't restore normal operation (out of the stalled play operation), have to reboot or wait for it to give up and become responsive.

Just tried that and it's the same for me.


If you want to avoid OTAs the reminder should be 0420-0440.

Yes I knew that but can't remember now why I changed it! I will correct this.

Re internet radio, I find this a good feature when it's working, but when it's not it's a pain. One glitch and all the favourites disappear and then it's too time consuming to reinstate them given the number of station options.
 
I confess to skipping a little of the thread... I'm planning on downgrading to an older OFW, as the EPG lag is bugging me!

I wanted to check my steps -
Uninstall CFW
Install required OFW
reinstall correct CFW

Is this right? do I need to uninstall the latest CFW first?

cheers!
 
You never need to "uninstall" the CF, loading whatever you want writes over it. In some cases it is necessary to load the target standard firmware before adding the appropriate CF, and in some cases one needs to prepare the custom software (or sort it out afterwards), but in this case all you need to do is load CF 2.21/1.02.32.

The relevant information in the Wiki HERE (click) is cautious because if somebody with "new" hardware downgrades to pre-1.03.xx firmware the unit could become unusable, but we have a fix for that now. "Old" hardware (which has previously been perfectly OK with pre-1.03.xx firmware) would not have a problem going from (say) 1.03.12 to 1.02.32 (or even 1.02.20) - and appropriate CF if desired.
 
cheers BH!

One thing I wanted to check - and I feel I should really know the answer already, and its probably clear somewhere, but I blame baby brain! Does the single zip file
HDR_FOX_T2_1.02.32_mod_2.21.zip
from the wiki contain BOTH the OFW and CFW? In the past, I've probably downloaded the OFW separately, but not sure if I need to!
 
That's not the whole answer. I think I'm right in saying the file mentioned contains enough of the differences between 1.03.12 and 1.02.32 to cover the bases. It would not be enough if there was no operating firmware present at all (or the differences in the existing standard firmware were too great).

Thus: installing CF2.22/1.03.12 over and existing 1.02.32 is sufficient to update the standard firmware to 1.03.12, and installing CF2.21/1.02.32 over and existing 1.03.12 is sufficient to "downdate" the standard firmware to 1.02.32. (The only reason I specify CF2.21 is that CF2.22/1.02.32 has not been released yet).
 
I have to agree with Dave_G that I find the naming rather confusing/ambiguous. I have to spend some time working out what I really need each time.
Couldn't, for example, HDR_FOX_T2_1.02.32_mod_2.21.zip be called HDR_FOX_T2_CFW_2.21_for_1.02.32.zip instead, or is there a technical reason why that couldn't work?
 
You can call the zip file anything you like, it makes no difference, because the unzipped hdf file MUST always have the same name i.e. hdr_fox_t2_upgrade.hdf and as you can see the hdf file has no reference to an official version number or a Custom version number
 
I don't see this as a problem. The sections are clear in the Wiki downloads page, so anyone downloading knows what they are downloading. After that it is only a question of getting used to the terminology.

We do not query that 9/3/14 means the ninth day of March in the year 2014, and "HDR_FOX_T2_1.02.32_mod_2.21.zip" is just another three fields which specify HDR-FOX T2, CF version 2.21 for standard firmware 1.02.32 (or however you would prefer to express it).

However, for the sake of adding two characters the suggested alternative adds clarity (CF not CFW - firmware is one word, and eliminating an underscore):

HDR_FOX_T2_CF2.21_for_1.02.32.zip

...but the rearrangement of fields like this also makes the file names not sort properly in a list. The original format is just an extension to the existing Humax download file names.

What I don't like is the inclusion of dots within the file name and not just reserved for the prefix to the file type, but I'm probably being old-fashioned.
 
We do not query that 9/3/14 means the ninth day of March in the year 2014, .
We could quite easily. It could be interpreted as the third day in September in the year 1914., especially in the context of Americans in WW1 . In contrast to that, I suspect that the totally ambiguous date 9/11 would in the main be interpreted as the eleventh day of September in the year 2001.
 
I have to agree with Dave_G that I find the naming rather confusing/ambiguous. I have to spend some time working out what I really need each time.
Couldn't, for example, HDR_FOX_T2_1.02.32_mod_2.21.zip be called HDR_FOX_T2_CFW_2.21_for_1.02.32.zip instead, or is there a technical reason why that couldn't work?
I think that would cause even more confusion because it would imply that you must have the stated official firmware version loaded before loading the CF. Also it would suggest that the hdf file does not contain any parts of the official firmware. Neither of these is necessarily true.
 
What I don't like is the inclusion of dots within the file name and not just reserved for the prefix to the file type, but I'm probably being old-fashioned.
I think the main reason for this is that in the *nix world there is no real distinction between file type and the rest of the file name (i.e. there is no real concept of a distinct file "type"). Some files are named that way but the file system does not store the file type in a separate field as it does on Windows systems.
 
Some files are named that way but the file system does not store the file type in a separate field as it does on Windows systems.
It's not a separate field at filesystem level. It's all part of the filename. It was only ever a convention to specify type in the 'extension', not a requirement, but it seems to have become worse over the years with each generation of more and more brain dead software pushed out from Redmond.
I tried to rename a file to .automp3 this week and Exploder (XP) told me I had to type a file name and refused to do it. Er why exactly? I had to do it from the command line where no such stupidity has been coded in.
 
It's not a separate field at filesystem level. It's all part of the filename. It was only ever a convention to specify type in the 'extension', not a requirement,
It is certainly a separate field in FAT and, IIRC, other filesystems like Acorn DFS. Not sure about NTFS.
 
I've spend the last 24 hours troubleshooting the loss of the web interface on my box following some changes to my network. I've been doing packet dumps and trying to work out why I am getting "Connection Refused" messages when I try to telnet into port 80, only to realise today that it has because of the OTA and nothing to do with the network reconfiguration. Doh! The first thing I will do when I reinstall the custom firmware is stop OTAs!
 
We do not query that 9/3/14 means the ninth day of March in the year 2014,


As Trev says, we can. And I do.
To this day I nearly always write a date as (eg) 4 Mar 2014, simply because I used to work for an international company and communicated a lot with departments in the USA (mm/dd/yy), Sweden (yy/mm/dd) and of course the UK (dd/mm/yy). Writing the Month and using the four digit year (this was around 2000-20010 so the short year was readily confused) was the only certain way of 'making a date'.
 
But you still understood it.

Which it? Your date example of 9/3/14? Not immediately - in such a case I'd look for the context: Who wrote it - English/American? And if it mattered I'd query it to make sure.

Which is why I questioned the naming of the file - to some of us it is ambiguous or unclear; that is a fact. I can perfectly understand what is said about sorting order (I often date files yyyy-mm-dd myself to keep the order tidy) but I'm puzzled by xyz's comment in #271 since having any official firmware number anywhere in the name suggests you need that loaded (which I thought it did).
It would just be a bit easier for us numpties if the file names clearly identified what they are/contain and therefore which we needed without having to check and double check we've got the right one for 'us'. (And btw what does 'mod' mean?)
 
That's a hang-over from the earliest days when we called it modified firmware.

I think this is daft. It's impossible to put all the information required into a file name, and no reason the users should not need to know something about it. The Wiki page explains all (or if it doesn't it should).

I do have a possible remedy, something I have been considering for a while: there is no reason a "readme.txt" can't be included in the .zip alongside the .hdf file, it would have no effect on the installation process. I will talk to af123 about it.
 
I'm puzzled by xyz's comment in #271 since having any official firmware number anywhere in the name suggests you need that loaded (which I thought it did).
In many (not all) cases you can upgrade both the official firmware and/or the CF by installing a single file from the firmware downloads page. The Firmware Upgrade Path page lists which files are required to upgrade from one specific version to another.

For example, as stated on that page to upgrade from 1.02.32 to CFW2.22/1.03.12, "There is no need to install Official 1.03.12 first, this single step will install the Customised firmware and upgrade the Official Firmware".
 
Back
Top