Unable to download a pid

[Arthur Murray]

On Tue, Feb 10, 2015 at 12:01 AM, Vangelis forthnet
<northmedia1 at the.forthnet.gr> wrote:
> On Mon Feb 9 17:55:07 GMT 2015, Arthur Murray wrote:
>
>> Trying to get this in HD:
>> b04xw2x8
>> (snip)
>> It fails to get (404)
>> (snip)
>> How do I get gip to use it?
>
>
> Your issue has the same root cause as the one
> discussed in recent thread
> http://lists.infradead.org/pipermail/get_iplayer/2015-January/007105.html
>

>
> C:\Program Files\get_iplayer>perl get_iplayer-291.pl --pid=b04xw2x8
> --playlist-m
> etadata --modes=flashhd --force --raw --subtitles

Thanks. I'll try that the next time this happens.


>
> And if you are still after the Level 3 HD version, as per your post:
> http://lists.infradead.org/pipermail/get_iplayer/2015-February/007108.html
> then TOUGH LUCK! (that is if you are accessing L3 from overseas...).
>
> I have solved the "flashhd2" mode "mystery":
> In the previous week, (almost all) L3 streams were failing (if the servers
> were accessed from non-UK IPs) with the infamous:
> "ERROR: Closing connection: NetStream.Failed"
> However, many of those were still failing even from within the UK...
> It has now become evident the Beeb were messing with L3 CDN
> servers configuration...
>
> This week, L3 streams are failing from non-UK IPs with a related error:
> "ERROR: Closing connection: NetStream.Play.StreamNotFound"
> that would suggest the file hadn't been uploaded to the server;
> however, the same L3 streams DO DOWNLOAD FINE from
> within the UK (physically or "virtually").
>
> The Beeb have re-configured the Level 3 CDN servers and have
> implemented some "new kind" of geo-filter; in contrast to the
> geo-block on the Akamai CDN servers, where you are denied
> access to the stream early on in the download attempt
> ([ AccessManager.Reject ] : Access denied!
> shows up in a rtmpdump -V log), with this new geo-filter on
> the L3 CDN you are allowed to connect to the server,
> however "createStream" & "play" error out, hence the
> "StreamNotFound" message...
> This new protection method affects uploads after Feb 1st;
> older ones (while still available) do not suffer from it...

I don't know if that makes sense.  Some streams are not found, but
some die at some random percent. Why send any data? Why cut off at
random times?  No one would deliberately design such a wacky system.

There are multiple IP #s behind the L3 IP name.  Perhaps some servers
have more of the file than others.  If you wait longer, even more of
the file becomes available (sometimes), so it could just be slowly
syncing, and maybe sometimes it fails to sync leaving the file
incomplete.  Prime time shows have a higher percent chance of being
incomplete in my experience.  It is a busy time with limited bandwidth
to L3 perhaps.

I don't know if there is a way to use rtmpdump to see if a file is
complete on the server (force a resume at 99% without having any of
the file?)

I was able to complete a full (recent, >Feb 1st) HD file 5 minutes
ago. (b052tkyt)