problem getting 6music program b038zll (Was "No Subject")

Vangelis forthnet northmedia1 at
Wed Aug 28 12:10:17 EDT 2013 was a hard one to solve:

On Wed Aug 28 11:18:09 BST 2013, Mable Syrup wrote:

>No probs with other programmes, but this one refuses to play ball - see 
>other notes
>(1) Will play correctly in browser from iplayer
>$ get_iplayer --type=radio --pid b038zlll --force
>ERROR: Closing connection: NetStream.Play.StreamNotFound
>INFO: Command exit code 1 (raw code = 256)
>WARNING: Failed to stream file 
>via RTMP

(The above error was produced for both flashaacstd1 & flashaaclow1 modes)

Hello Mable Syrup (though I only know of maple syrup, :-) )
At first I thought your problem had to do with the strange characters (@, #, 
: ) in the title name of your audio programme, I soon ruled this out.
I myself am on Windows Vista, I gather you are in a non-MS OS.
The error "NetStream.Play.StreamNotFound" produced by rtmpdump clearly 
stated that the flv file it was supposed to dump and pointed to
by GiP was evidently not there on the FLASH server...
Next step was to try if the audio file streamed normally on the iPlayer 
site - so I navigated to the normal iPlayer URL,

which is also the URL GiP is using to get its info to record the audio 
I first tried from my Greek IP, then tried a UK IP via a VPN - in both cases 
I could not get the stream to play,
the embedded player showed this message:
"This content doesn't seem to be working. Try again latter"
and right click on the player -> copy error message produced this second 

"EMP v.3.0.0.r617463_618125_4
 Playlist URL :
 Error code : CDNRedundancyManagerError [0] : null

I have tried in various browsers and with the latest stable flash player on 
my platform (11.8.800.94), no joy.
This inability to stream said audio file from the page above in fact 
justifies the inability of GiP to fetch the file on disk!

[ I sometime later read Rob Dixon's reply, which further corroborated my 
findings so far... By the way, I strongly beg
Rob Dixon to include in his reply's subject field something more than a 
plain "Re:" - doing so breaks for me the main
list archive ( ) on 
Firefox, which is my preferred
browser - in order to read his post, I have to navigate to the backup 
( ) 
or use Google Chrome browser...
I have post about this issue previously in July, see this thread: ]

 But you did insist that:
>(1) Will play correctly in browser from iplayer
It then dawned on me that you must have meant the "new" iPlayerRadio" page, 
so I went to:

and clicked "Listen now" - much to my amazement, I could stream the file 
both from my Greek IP
(HE-AACv2 @ 48kbps ABR = flashaaclow) and from a UK IP (AAC-LC @ 128kbps ABR 
flashaacstd). I was puzzled!

Warning: Tech stuff coming up!

After some further thought, I realised that for a given PID (=b038zlll), the 
difference between the two iplayer
page versions is that they use different "mediaselector" URLs to acquire the 
actual (rtmp) streams;
for PID=b038zlll, the following playlist URL:

reveals that mediator identifier="b038zll6", or simply vPID=b038zll6.
The normal (older) iplayer page (and the one used by GiP) uses 
"mediaselector4" to get the stream URIs,
in this pattern:
This URL is geo-blocked, returns different results according to whether the 
originating IP is in UK or not.

For a UK IP, the info about the flashaacstd mode is located here:

<media bitrate="128" encoding="aac" expires="2013-09-02T21:02:00+00:00" 
kind="audio" service="iplayer_uk_stream_aac_rtmp_concrete" 
type="audio/mp4"><connection application="a5999/e1" 
kind="limelight" priority="10" protocol="rtmp" 
server="" supplier="limelight"/>

This is the stream that cannot be played in the browser / downloaded by GiP. 
Take note of the "identifier" string, which is actually the "playpath" 
string in
rtmpdump lingo: 

On the other hand, the "new" iPlayerRadio page uses "mediaselector5" to get 
the actual stream URIs,
requesting this geo-blocked URL:

For a UK IP, the info about the flashaacstd mode is located here:

<media bitrate="128" encoding="aac" expires="2013-09-02T21:02:00+00:00" 
kind="audio" service="iplayer_uk_stream_aac_rtmp_concrete" 
type="audio/mp4"><connection application="a5999/e1" 
authExpires="2013-08-28T16:56:14+00:00" authExpiresOffset="6295" 
priority="10" protocol="rtmp" server="" 

This is the stream that can be played back on the browser, but cannot be 
downloaded by GiP - notice that the "identifier" string is now:


which is different to the one returned by mediaselector4; for the majority 
of audio files, the identifier string is the same regardless of the version 
mediaselector used (and this is why GiP does not fail for other audio 
However, in this case there has been a mix-up in the Beeb's software in that 
only v5 produces a valid stream. I put this down to the fact that this
radio show was simulcast both on Radio 2 & Radio 6Music, hence the c*ck-up.

The more savvy among you can easily concoct a working rtmpdump command for a 
Limelight Server, based on the info provided by the
mediaselector5 page, to download the show in question - NB that the 
"authString" is valid for an hour, perhaps a bit more...

However, I took the gallant aproach of temporarily patching the GiP script 
to use the mediaselector5 URL.
At first I failed miserably, by trying to replace every instance of
in the script with
but the way that worked was:

(Remember I am on Windows, modify my instructions according to your system)
1. Locate the current working copy of the script
(C:\Program Files\get_iplayer\ and BACK IT UP (so you can 
restore it
if you mess things up) - saved mine as .
2. Locate the FIRST instance of

inside the perl script - mine was on line 5895 of a heavily patched v2.82 

5892   # Get authstring from more specific mediaselector if this mode is 
specified - fails sometimes otherwise
5893  if ( $cattribs->{authString} && $cattribs->{kind} =~ 
/^(limelight|akamai|level3|sis|iplayertok)$/ && (grep /^$mode$/, (split /,/, 
$mattribs->{modelist})) ) {
5894   # Build URL
5895   my $media_stream_data_prefix = 

and REPLACE it with the v5 URL, i.e.

- so now my line 5895 looks like this:

5895   my $media_stream_data_prefix = 

Save the modified script and you are good to go!

I used the following command (from a UK IP)

get_iplayer --type=radio -i --pid=b038zlll --modes=flashaacstd --force -w --file-prefix="Darkside 
 - The Ultimate Pink Floyd Playlist - 
Mon_26_08_2013[b038zlll]" --tag-podcast-radio

and the file now downloads OK:

INFO: 1 Matching Programmes
INFO: Checking existence of default version
INFO: flashaacstd1 modes will be tried for version default
INFO: Trying flashaacstd1 mode to record radio: Now Playing @6Music - 
 The Ultimate Pink Floyd Playlist
INFO: File name prefix = Darkside - The Ultimate Pink Floyd Playlist - 
RTMPDump v2.4
(c) 2010 Andrej Stepanchuk, Howard Chu, The Flvstreamer Team; license: GPL
Connecting ...
WARNING: HandShake, client signature does not match!
INFO: Connected...
Starting download at: 0.000 kB
INFO: Metadata:
INFO:   duration              7200.04
INFO:   moovPosition          36.00
INFO:   audiocodecid          mp4a
INFO:   aacaot                2.00
INFO:   audiosamplerate       44100.00
INFO:   audiochannels         2.00
INFO: tags:
INFO:   ┬σalb                 Now Playing @6Music
INFO:   aART                  BBC 6Music
INFO:   ┬σART                 BBC 6Music
INFO:   ┬σcmt                 Tom Robinson invites listeners to compile the 
mate Pink Floyd Playlist.
INFO:   cprt                  British Broadcasting Corporation Copyright 
2013, a
ll rights reserved.
INFO:   ┬σgen                 Podcast
INFO:   ┬σnam                 Now Playing @6Music 26 08 2013
INFO:   ┬σday                 2013
INFO: trackinfo:
INFO:   length                317521920.00
INFO:   timescale             44100.00
INFO:   language              und
INFO: sampledescription:
INFO:   sampletype            mp4a
18577.816 kB / 1136.90 sec (15.7%)

Once the download has completed, you may wish to restore your original copy 
of the script
from the back up, as I am not certain whether my coarse patch breaks other 
aspects of GiP!

>(2) gets very small part of file if  wma specified

This is a very well known and established glitch of MPlayer, the application 
inside GiP
that handles the dumping of the wma streams - there exist other more 
reliable ways to dump
those wma streams reliably (but, sadly, only in real-time speed, meaning a 2 
hr show would
need ca. 2 hrs to save) involving the use of VLC player or recent builds of 
FFmpeg. You can
search the list archives as I've posted about this in the past...

I do hope you enjoy your Pink Floyd special!


More information about the get_iplayer mailing list