New 1.02.27 firmware

I'm guessing the Loader (ie. a bootstrap) isn't upgradeable... or at least isn't upgradeable as part of a firmware update

I agree - they probably /can/ update it OTA but it would be an unreasonable risk. It would be interesting to know what the differences are between the three versions but they are possibly just updates to the test bench code used in the factory.

More interesting would be to understand the differences in the 2nd stage bootloader on the HD model, although I suspect the main change might have been just the kernel's flash location.

Am I missing something? 1.02.27 isn't an "official" release yet so installing this could effectively invalidate your warranty or cause other problems? Wasn't there a bug in 1.02.026 and that's why it was never officially released? has this been fixed in 1.02.27?

I don't think it would invalidate your warranty but yes it's only posted on the beta site. I would imagine that they will do what they did for the Foxsat which is leave it there for a couple of weeks before pushing an OTA and making it available on their main site.
The bug in 1.02.26 that I saw mentioned on myhumax.org was related to audio description IIRC and the release notes for 1.02.27 do indicate that there are fixes in that area.
 
I'm guessing the Loader (ie. a bootstrap) isn't upgradeable... or at least isn't upgradeable as part of a firmware update - I think what Humax mean is that the new firmware is designed to work on a7.31 and a7.32 only (but fortunately for us, also appears to work on a7.30)
Hang on that can't be right can it? (and admittedly Fmrl does say it's a guess) - "Fortunately it works on a7.30" - surely they can't release something that was dependent on a higher Loader version and leave us old "point-three-oh's" crossing our fingers! Otherwise me (and I presume* many others) wouldn't be able to take this 1.02.27 version?

* Or is that Assume?
 
Hang on that can't be right can it? (and admittedly Fmrl does say it's a guess) - "Fortunately it works on a7.30" - surely they can't release something that was dependent on a higher Loader version and leave us old "point-three-oh's" crossing our fingers!

I think you must be correct, There must be many more a7.30's out there than a7.31's and a7.32's, I suppose if Humax did wan't to discriminate between newer and older purchasers they could look for Loader version but I don't think that is their intention (this time ! !)
 
Yes, the on-screen mode confirmation is annoying. Luckily I don't tend to use the original Humax remote much anyway!
According to the site it's only when you change mode although I'm not sure what problem that is solving given that you'd already know what button you'd pressed by virtue of having just pressed it AND they light up red (albeit while hidden under the finger that just pressed it!!!).

Aaaaanyway - the other bit they've added is "If a mode button is pressed in error when trying to control the Humax product user is informed on screen to press the PVR button" - I still don't get this! Firstly you can't control the Hummy by pressing a mode button, and even if you could how would the Hummy know that was an error? OR what they meant is that if I pressed a function button for the Hummy while in one of the other modes it would tell me to switch it to PVR mode. However - if I'm in TV mode to tweak the volume on the TV then is the remote going to assume that must be an error because I have dared to try and NOT control the Hummy? (Unlikely of course for a multi function remote!)

So this must leave the icon appearing on screen that you should be in PVR mode IF you press a button on the remote that is NOT already mapped to a function appropriate to the device mode you've got the remote in!!

There that clears it up!! Wibble or what! Time for more medication for me please......

Somewhere in there I am hoping somehow that this might just help SWMBO who keeps ringing me at work to tell me that "the TV box is broken because the remote doesn't work" until I ask her to tell me what button flashes red when she presses a button so that she can put the remote in the right mode - hopefully she'll see something on screen while she's looking at it that will save the phone call!!! :rolleyes:
 
All I can presume/assume is that humax support recieve a shed load a queries about the remote not responding..
It's useful, and i presume/assume will have only taken a few lines of code to implement.
 
I'm tempted to stick with 1.02.20 - there doesn't seem to be much added in the update to make it worthwhile?

The onscreen "error" for the remote actually sounds like a bit of a pain in the butt now that I think about it.
 
All I can presume/assume is that humax support recieve a shed load a queries about the remote not responding..
It's useful, and i presume/assume will have only taken a few lines of code to implement.
+ the design of the new images : )
 
i before e except after c, unless sounding like "a" as in neighbour and weigh... (plus list of exceptions)

Yes, the idea that it complains you've pressed the wrong button fairly boggles me too, and I agree it is probably a response to thicko support requests.
 
Assuming the 4GB streaming bug is fixed then that is a compelling reason to update?

I've never come across that bug - is it just that you can't stream a file over 4gb? If I want to watch anything stored on my PC then I usually mount the drive over CIFS rather than DLNA stream it anyway.
 
Assuming the 4GB streaming bug is fixed then that is a compelling reason to update?
It would be unless there was already a way to use your networked drive like a USB drive and bypass the bug, get straight folder navigation instead of that horrible DLNA Video>All Video>Folders... yuk, get file copy functions onto the NAS drive using the Hummy menus, wider file format support and keep trick play and the Resume function...and happily there is a way :)

I think BH posted it somewhere already today the bug has actually driven out a much better way to access files across the network than the standard!! But of course for the non-modded community it does absolutely sort out the bug.
 
I've never come across that bug - is it just that you can't stream a file over 4gb? If I want to watch anything stored on my PC then I usually mount the drive over CIFS rather than DLNA stream it anyway.
But the same problem will stop you removing encryption from a recording by the most convenient method.
 
But the same problem will stop you removing encryption from a recording by the most convenient method.
No, the 4GB bug is (was) only in the DLNA client, the server is fine and will happily stream larger files (=> decrypt).
 
No, the 4GB bug is (was) only in the DLNA client, the server is fine and will happily stream larger files (=> decrypt).

Hmm so just to double check if I use the auto-mount method to get access to my NAS and use the Hummy to copy files onto it, they will get decrypted as per any other USB copy (subject to flags being removed) SD & HD - right?

[EDIT - sorry I realise I'm going a bit off topic]
 
Hmm so just to double check if I use the auto-mount method to get access to my NAS and use the Hummy to copy files onto it, they will get decrypted as per any other USB copy (subject to flags being removed) SD & HD - right?

Seems to work fine for me on version 1.02.20
 
I understand the 'Reliability Improvement' detailed in #4 is to fix a couple of issues found during always-on tests, (over several days). Unfortunately no further details yet
 
Cool - I've been putting loads of stuff onto my NAS while mounted as a USB drive for a while now and suddenly got a panic that it was all still encrypted and hence useless if I ever got another Hummy (or other such device).
 
Has anyone confirm'd that the same old mediaID and dnla server trick works for decrypting stuff? not that there is much they can do ultimately as we'd soon be able to reverse it but would be interesting to see if they have done anything at all even as a token gesture
 
Back
Top