iPlayer stopped working?

Black Hole said:
For information: the iplfix package is now available in the standard (not beta) repo, available for CF users to install: WebIF >> Package Management >> Check for updates >> Available.

iplfix installs new certificates (at boot time) to replace the expired ones, so making TV Portal >> iPlayer work again (to the limited extent it actually "worked" before!).
Click to expand...

Is this different from iplhack package? It sounds like it is.
 
Owen Smith said:
Is this different from iplhack package? It sounds like it is.
Click to expand...
It absolutely is:
Black Hole said:
iplfix installs new certificates (at boot time) to replace the expired ones, so making TV Portal >> iPlayer work again (to the limited extent it actually "worked" before!).
Click to expand...
...as opposed to
Black Hole said:
Prior to availability of new certificates, the custom firmware universe for HDR-FOX and HD-FOX came up with a work-around, which is to re-route accesses to BBC iPlayer away from the Humax proprietary portal, to the access mechanisms used by other iPlayer clients instead. Details here: iplhack package.
Click to expand...

Clearly I go to too much bother documenting this stuff.
 
Black Hole said:
It absolutely is:

...as opposed to


Clearly I go to too much bother documenting this stuff.
Click to expand...

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.
 
Owen Smith said:
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.
Click to expand...
You only get repeat emails if you visit the thread again after receiving the email, one of the feechurs of XenForo
 
MymsMan said:
You only get repeat emails if you visit the thread again after receiving the email, one of the feechurs of XenForo
Click to expand...
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.
 
MartinLiddle said:
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.
Click to expand...
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.
 
I agree, but it doesn't matter now - the relevant info has been included. I need to do some patching again...
 
Not unlesseven if they include a new version of OpenSSL (eg like that available here), which I believe they don't.
 
Last edited:
[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')
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=published
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.
 
/df said:
(the lunatics have taken over the asylum).
Click to expand...
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.

/df said:
[Off-topic, but here goes]
Click to expand...
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.
 
Black Hole said:
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! ...
Click to expand...
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.
 
You must log in or register to reply here.
Back
Top