Owen Smith
Well-Known Member
Is this different from iplhack package? It sounds like it is.
-
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.
Is this different from iplhack package? It sounds like it is.
Black Hole
May contain traces of nut
It absolutely is:
...as opposed to
Clearly I go to too much bother documenting this stuff.
Owen Smith
Well-Known Member
On the contrary. I am subscribed to at least one of these threads, but I never got the emails from the forums. They would have told me what I needed to know had I got them.
MymsMan
Ad detector
You only get repeat emails if you visit the thread again after receiving the email, one of the feechurs of XenForo
Owen Smith
Well-Known Member
I know that and I do visit the threads again. However it is impossible to discount the possibility of a lost email since they are not a guaranteed medium.
Humax have now released their fix for the iPlayer problem version 1.03.13 which is available to download from https://uk.humaxdigital.com/support/?product_id=2641&curr_page=sw_release.
Black Hole
May contain traces of nut
PLEASE NOTE: The official Humax download is only a suitable fix if you are not running Custom Firmware.
Owen Smith
Well-Known Member
The above is the HDR Fox T2 version. This is for the HD Fox T2:
https://uk.humaxdigital.com/support/?product_id=2643&curr_page=sw_release
Sorry but I don't understand your point; my post is in the HDR section so it is not surprising that it points to the HDR version. I made a separate post in the HD section.
Owen Smith
Well-Known Member
This is the thread about the Humax iPlayer issue. Why would I go and look for another thread? It's the same issue on both boxes, having two threads makes no sense for this issue.
prpr
Well-Known Member
Because this is in the "HDR-Fox T2 Freeview Recorder" section.
Owen Smith
Well-Known Member
That's being pedantic in the extreme. This is the thread about the issue.
Black Hole
May contain traces of nut
I agree, but it doesn't matter now - the relevant info has been included. I need to do some patching again...
Black Hole
May contain traces of nut
Slim chance: I don't suppose these new official firmwares get YouTube working again?
[Off-topic, but here goes]
My thinking was that the main issue is that YT now required versions of SSL/TLS that weren't supported by OpenSSL 1.0.0, the version supplied with the stock 2010-era firmware. Looking back, when the HD-Fox YT app was withdrawn, the APIs going https-only was given as the reason in these forums. However, the YT APIs used by the Humax app might also have been broken since, as I thought, YT had already cast off the app by requiring TLS1.2.
At least the first part of that thinking was not accurate.
Currently accessing YT with a browser that it doesn't like (eg, Humax UA "Opera/9.80 (Linux 7405b0-smp; U; HbbTV/1.1.1 (; Humax; HD-FOX T2; 1.03.02; 1.0; ); ce-html/1.0; en) Presto/2.10.250 Version/11.60") redirects to a browser-not-supported page on the first attempt, after which it sets the 'hideBrowserUpgradeBox' cookie flag. This works even with only TLSv1.0 enabled. However the site then serves JS that can only be understood by very recent browser versions (the lunatics have taken over the asylum). The pages returned by the YT API that the Humax API used wouldn't have demanded such advanced JS (if any).
What actually happens with the new-portal version of the YT app is that the left-hand menu appears but anything that requires getting data from YT fails with either 404 or a message that execution of an API request failed, quoting ('Most Popular')
In my desktop browser faked to be a Humax HDR, the quoted URL also gives 404.
So I conclude that Humax decided not to upgrade the app to a new version of the YT API and that is why it doesn't work. SSL/TLS versions seem to be a red herring.
As to introducing a newer version of OpenSSL (which would be good even if it didn't save the YT app), in the Humax s/w the settop blob is dynamically linked against OpenSSL 1.0.0, ie TLS <=1.1. The Opera library seems to know about TLS up to 1.2, but isn't dynamically linked against OpenSSL. Introducing a newer version of OpenSSL would at least require a shim layer, which I think is a research problem: I think that's a no.
My thinking was that the main issue is that YT now required versions of SSL/TLS that weren't supported by OpenSSL 1.0.0, the version supplied with the stock 2010-era firmware. Looking back, when the HD-Fox YT app was withdrawn, the APIs going https-only was given as the reason in these forums. However, the YT APIs used by the Humax app might also have been broken since, as I thought, YT had already cast off the app by requiring TLS1.2.
At least the first part of that thinking was not accurate.
Currently accessing YT with a browser that it doesn't like (eg, Humax UA "Opera/9.80 (Linux 7405b0-smp; U; HbbTV/1.1.1 (; Humax; HD-FOX T2; 1.03.02; 1.0; ); ce-html/1.0; en) Presto/2.10.250 Version/11.60") redirects to a browser-not-supported page on the first attempt, after which it sets the 'hideBrowserUpgradeBox' cookie flag. This works even with only TLSv1.0 enabled. However the site then serves JS that can only be understood by very recent browser versions (the lunatics have taken over the asylum). The pages returned by the YT API that the Humax API used wouldn't have demanded such advanced JS (if any).
What actually happens with the new-portal version of the YT app is that the left-hand menu appears but anything that requires getting data from YT fails with either 404 or a message that execution of an API request failed, quoting ('Most Popular')
Code:
Execution of request failed: https://gdata.youtube.com/feeds/api/standardfeeds/most_popular?start-index=1&max-results=10&paid-content=false&embed=allowed&syndicate=allowed&v=2&format=6,1&time=today&safeSearch=strict&orderby=publishedSo I conclude that Humax decided not to upgrade the app to a new version of the YT API and that is why it doesn't work. SSL/TLS versions seem to be a red herring.
As to introducing a newer version of OpenSSL (which would be good even if it didn't save the YT app), in the Humax s/w the settop blob is dynamically linked against OpenSSL 1.0.0, ie TLS <=1.1. The Opera library seems to know about TLS up to 1.2, but isn't dynamically linked against OpenSSL. Introducing a newer version of OpenSSL would at least require a shim layer, which I think is a research problem: I think that's a no.
Black Hole
May contain traces of nut
If they don't call it HTML5, how are we supposed to tell the difference between browser compatibilities? There has to be some kind of indication of revision level! Lunatics indeed.
Not out of the ball park though! Thanks for looking into the issues. "Lack of https" might not be the whole story, but it's a lot easier as an explanation.
It's not stated explicitly in the Living Standard, but many web developers seem to think that HTML5 conformance is synonymous with "(only) works in the latest version of G Chrome" and go to some lengths to achieve this.
Black Hole
May contain traces of nut
Spotted this today, when testing the TV Portal:
