episode oddity

Vangelis forthnet northmedia1 at the.forthnet.gr
Thu Aug 4 20:54:35 PDT 2016

On Wed Aug 3 15:54:50 BST 2016, Jim web wrote:

> I'm currently using the linux gip (Jan develop version 2.95)
> Should the current release version accept the same options?
> I'll get it and give it a try, but am wondering
> if I'll need to change the way I specify getting the
> best hdtv via hls.

Hello Jim and other list company :-)
Back after a short trip, I am now catching up
on list threads - heatwave isn't helping, though :-(

Jim please, if you come here seeking for help,
at least (as you said you are planning to) migrate
to the latest released version of GiP, i.e. 2.95 final,
so we can compare like for like...
"(Jan develop version 2.95)" is as vague as it can ever get!

If you browse the develop repo,
you'll find that no less than fourty one (41) different
commits for the main script were pushed to that repo
on the month of January 2016, so it's practically
impossible for us to tell which specific January 2016
2.95dev snapshot you are on currently!

Develop snapshots are unsupported, but if you or
anybody else is willing to try them, here is a tip:

1.Always visit the develop repo first:
2. Note down commit hash of latest snapshot.
At the time of writing, it is "782f04a" and this belongs
to a 2.96dev snapshot.
3. The following URI will always fetch latest dev snapshot:
Latest get_iplayer-dev (main perl script)


I would save this (on Windows) as


so I already have an indication of its identity.
But should you use it to replace your original script,
then open it up in an editor and search for

my $version_text = "2.96-dev";

Edit this to

my $version_text = "2.96dev-g782f04a";

or similar; that way, whenever your dev
snapshot is run, you can easily tell its "version"
in time because it's printed out in the Command
(The above was mainly geared for Win users;
I realise Jon Davies is maintaining a separate
PPA for the develop version, I suspect if you
installed from that you can easily tell its git-version...)

A plethora of further commits/changes were
pushed to the 2.95dev repo since Jan 2016,
all these ended up in final 2.95 and have significantly
changed the behaviour you are currently
experiencing in your "Jan 2.95dev" version.

After you have upgraded to 2.95-final,
have a thorough read (and re-read) of the
Release Notes
and the FAQs
(the FAQs are being constantly revised, so do
bookmark them for future re-visits!)

While those links already contain all the answers
to your questions, in relation to what concerns you
the most:
1. "--type=tv" needs not be specified, as the tv.cache
is searched by default.
2. "--type=radio" can be omitted in 2.95, but in reality shouldn't...
3. HLS (tv|radio) modes are now the DEFAULT -
this change was brought on by
in Feb 2016, so not present in your 295dev snapshot!

With 2.95-release, YOU DON'T HAVE TO SPECIFY
--modes=hlshd ; this is now the default.
(NB --tvmode & --modes are valid, --mode is not,
according to longhelp).

In your 2.95dev snapshot,
would fetch the flashhd tvmode (the default then).
To specifically request flashhd in 2.95-release, issue:

On Thu Aug 4 10:22:29 BST 2016, Jim web wrote:

> The problem for me with the alternative fetching method
> (which here only states it is RTMPDump, but that may be a mislabel)
> is rather slower than HLS. This is an minor irritant,

The "alternative fetching method" is, as explained already,
the downloading of the RTMP stream (via the RTMPdump
helper utility, I'm sure you already know it) that corresponds
to the FLASHHD tvmode.
Do not compare downloading speeds between the two,
it's a clear case of apples vs oranges.
1. Different protocols (rtmp vs http)
2. Different streaming method (HLS uses file segmentation)
3. Different CDNs, many miles apart possibly.
4. Add to the above all sorts of random factors
that may control DL speeds, as I recall I discussed
in a previous thread of yours earlier in the year
(where you were comparing DASH to HLS).

> However it seems clear there *is* an 'intermittent' problem of some kind.

The issue that started this thread (and possibly
related to the report made at
http://lists.infradead.org/pipermail/get_iplayer/2016-July/009264.html )
appears to be attributed to a glitch
at the Akamai CDN server hosting/serving the HLSHD tvmode
(1280x720p, ~ 2400kbps, 25FPS) of iPlayer TV programmes.
It has manifested itself the last 4-5 days and is more
pronounced on new/recent iPlayer additions.
Over time, some faulty PIDs are fixed, others
are not. There is also discussion over at the Support Forum:




Sadly, there is ONLY ONE CDN for the hlshd tvmode.
I don't know whether all the hundreds of thousands (millions?)
of GiP 2.95 users all pounding that CDN by default now
has had any role to play in the manifestation of this issue (?),
but things to try are:
A. If you're not in a hurry, retry a week after - most probably
your affected programme has been corrected.
B. If you are in a hurry,
1. Give the (deprecated) option "--hls-ffmpeg" a try;
that one delegates the HLS stream recording to
ffmpeg (the case used in GiP 2.94) rather than
the native perl downloader - who knows,
maybe ffmpeg willl fare better (doubtful, doesn't
hurt to try, though...).
2. Try another HLS tvmode; you'll be surprised
how good hlsvhigh and/or hvfvhigh look,
especially on a regular computer monitor;
hvfvhigh is also acceptable on a 42in TV monitor,
last time I checked (and there exist 2 CDNs
for hvfvhigh)...
3. The consensus is to switch to the (deprecated)
FLASHHD tvmode; only drawback somewhat slower speeds;
but people, that is the speed you were downloading
HDTV-on-demand with a month ago,
prior to 2.95's release (if not asking for hlshd).

Let's hope it is fixed with time, sadly
nothing more can be done at GiP's end...

Kind regards all,

More information about the get_iplayer mailing list