• The forum software that supports hummy.tv will be upgraded to XenForo 2.3 on Wednesday the 20th of November 2024 starting at 7pm

    There will be some periods where the forum is unavailable, please bear with us. More details can be found in the upgrade thread.

[CFW 3.03] Customised Firmware version 3.03 released.

af123

af123

Administrator
Staff member
Version 3.03 of the customised firmware has now been released and is available for download via the Wiki at http://wiki.hummy.tv/wiki/Firmware_Downloads

The main change in this version is an updated kernel for the HDR model to resolve a rare problem with disk initialisation.

There is no special upgrade procedure required for this version - it can be safely installed on top of any previous CFW version, or on top of any official Humax version in a single step.

Note that as it includes a kernel, it takes longer to programme into flash with a prolonged pause around the 90% mark and there may be a second programming phase on the HD-Fox T2.

Full release notes:

3.03 (03.03.2015)
  • Updated kernel:
    • Updated SATA driver to overcome a rare problem with disk initialisation;
    • Support USB drives that automatically spin-down when idle.
  • Improve web page shown during system initialisation on HDR;
  • Available for the Humax HDR Fox-T2 versions 1.02.20, 1.02.32 and 1.03.12;
  • Available for the Humax HD Fox-T2 versions 1.02.20, 1.02.31 and 1.03.02.http://wiki.hummy.tv/wiki/Firmware_Downloads
 
We know that lockups are an occasional fact of life, but I seem to have two or three times as many since moving from 3.02 to 3.03. The latest was today when it did a complete factory reset.

Is anyone else experiencing this?

I don't particularly need the updated kernel, so reverting back is not an issue - that is until the next exciting development!

I understand what the latest version was fesigned to fix, but I must confess, I don't recall why the latest versions include a custom kernel.



Sent from my GT-I9505 using Tapatalk
 
Other than being able to make our own changes to the kernel going forward, the main reason was to add firewall (ipfilters) support so fix the DLNA crash problems.

I've added the original 1.03.12 kernel that Humax released to the Wiki downloads page at http://wiki.hummy.tv/wiki/Firmware_Downloads so if you're having problems and don't need to the extra functions, then you can load this on top of CFW 3.03.
 
Note that applying the 1.03.12 kernel patch on to 3.0x versions will make the HDR-FOX stop functioning with a wireless dongle connected. It is fine if you are using Ethernet. Reverting to version 3.02 custom firmware from 3.03 will work with WiFi as you will install version 3.00 of the custom kernel in the process.
 
Last edited:
Black Hole said:
@4ndy: has your issue been resolved?
Click to expand...

I am still on 3.02 on the main box, while I monitor the situation before posting on here.

Certainly I have experienced fewer lock ups since reverting. Last night it locked while copying an HD recording to an ExFAT usb, when an HD recording started. The status showed it was also playing another recording, which I interpreted as a shrink process.

I have no data to back this up, but my observation is that while copying to or from a USB stick, generally USB3 FAT32 or NTFS, webif is very unresponsive and much slower through the remote. Not getting quite the same degree of tardiness when using a powered external HDD. I wonder if the new kernels (Humax and CFW) are giving too much resource to the USB speed demands.

I have had the odd factory reset, the latest about 3 weeks ago and on each occasion I reverted to stock firmware, before installing the CFW and running fix disk. The internal HDD was replaced last summer and reports OK.

Sent from my GT-I9505 using Tapatalk
 
Surely if the box is still unreliable with the Humax stock kernel, it's not a custom firmware kernel problem?
 
Owen Smith said:
Surely if the box is still unreliable with the Humax stock kernel, it's not a custom firmware kernel problem?
Click to expand...

As I said, I am still monitoring.

It seems more reliable with 3.02. I suspect that both kernels may be prone to overload, by too many tasks or fast USB sticks.

I am not in IT, so this is just my rationalising of what I have observed. There could be something else going on, as my other boxes are not showing the issue to the same degree , but they are in another room and used far less. I should swap them around, but that involves moving a lot of furniture.

Sent from my GT-I9505 using Tapatalk
 
.
...Hi all.
Just a little confused as to why there are three versions of Custom Firmware available for HDR-Fox T2 (3.03) ??
[ie. which one am i supposed to use? - thanks]

(SHA1: 5bad73d770a2e211f417bf65783ad04097e00c62)
(SHA1: 204c9de2c09f45cc84287596308cd1cf49c4739b)
(SHA1: d8981473b5f377298af7bf98b7a4a2dea6a7b37d

.
 
.
Thank you for taking the time to reply - i understand it better now... three versions of CF-3.03 to work on top of three different Official Firmware types - one of which would of been selected and installed on a users Hummy.

I'm using the latest OF-1.03.12 and subsequently i'll be downloading/using CF....
....(SHA1: 5bad73d770a2e211f417bf65783ad04097e00c62)

One question though, why can't we have the best of everything? ie. OF-1.03.12... why can't we have the faster on-tv guide (EPG) also?

thanks
.
 
prpr said:
Because the Humax developers/testers are a bit rubbish and can't see and/or fix the problems.
Click to expand...

Which begs the question why isn't it something that is already included in the CF? (faster epg i mean). Isn't the CF just additional coding? If the Humax developing team can't see/fix the problem why can't it be done by the guys/girls creating CF?

Apologies if i'm not making sense/and or not being up-to-speed with programming/coding, i'm a complete newbie and don't understand the difference.

thanks

.
 
Yep, you're making sense, but all the CF stuff is 'tagged on to' the OF. The EPG is part of the OF and the OF itself cannot be 'tinkered with'.
 
Des in London said:
If the Humax developing team can't see/fix the problem why can't it be done by the guys/girls creating CF?
Click to expand...
Because the Humax code is one big binary blob. You would have to reverse engineer the Humax code, find where the EPG navigation code is, understand what the problem is and then engineer a fix and patch the binary blob. None of that is trivial. I don't think it is impossible but the amount of effort involved could probably be better invested elsewhere.
 
ahhh... i'm starting to see a bit clearer now. So basically the OF is locked out completely then, and can't be accessed by us/CF developers to speed up the epg? Is it just a case of we're not authorised to or we just simply can't access the OF under any circumstances?

So do you think that Humax developers altered something when they created OF-1.03.12 that has made the epg soooo slow now?

thanks
.
 
Des in London said:
ahhh... i'm starting to see a bit clearer now. So basically the OF is locked out completely then, and can't be accessed by us/CF developers to speed up the epg? Is it just a case of we're not authorised to or we just simply can't access the OF under any circumstances?
Click to expand...

MartinLiddle said:
Because the Humax code is one big binary blob. You would have to reverse engineer the Humax code, find where the EPG navigation code is, understand what the problem is and then engineer a fix and patch the binary blob. None of that is trivial. I don't think it is impossible but the amount of effort involved could probably be better invested elsewhere.
Click to expand...


Thanks Martin for clearing up my confusion regarding access to OF.

I love a challenge.... wish i was a bit more programmer savvy so i could take a look at the binary blob as you mentioned - i would compare the entire code from OF-1.03.12 against OF-1.02.32, that should spot the differences between them and thus help identify which line of commands have slowed the epg.

Des
.
 
Des in London said:
ahhh... i'm starting to see a bit clearer now. So basically the OF is locked out completely then, and can't be accessed by us/CF developers to speed up the epg? Is it just a case of we're not authorised to or we just simply can't access the OF under any circumstances?
Click to expand...
Your questions don't make a lot of sense. Some bits of the Humax software are being accessed by the custom firmware and the custom firmware interacts closely with a lot of databases and other files used by the Humax software. What is difficult is changing the behaviour of the standard software.

So do you think that Humax developers altered something when they created OF-1.03.12 that has made the epg soooo slow now?
Click to expand...
I think it is very obvious that something was changed. I seriously doubt that the change was deliberately intended to slow down the guide navigation but it is unfortunate that Humax have so far not shown any inclination to fix the problem. Personally it isn't an enormous problem once you get used to using the fast forward and back keys to step left and right two hours at a time and the channel up down buttons to move seven channels at a time.
 
Des in London said:
I love a challenge.... wish i was a bit more programmer savvy so i could take a look at the binary blob as you mentioned - i would compare the entire code from OF-1.03.12 against OF-1.02.32, that should spot the differences between them and thus help identify which line of commands have slowed the epg.
Click to expand...
It is a binary blob; there are no lines of commands.
 
You must log in or register to reply here.
Back
Top