Winter Olympics live stream recording
Paul Phillips
paulphillipsdidsbury at gmail.com
Sun Feb 16 19:13:55 EST 2014
I had a couple of streams die on me today half way through and they
didn't seem to reattempt. Should I be using --attempts=x or --resume
to improve this?
This is a typical command line I'm using at the moment with the head code:
get_iplayer http://www.bbc.co.uk/sport/live/winter-olympics/26037823
--modes=best --type=livetv --fileprefix="<name> - <episode> <pid>
<version> <mode>" --resume
I saw it said "ignoring resume" in the output when it crashed.
On 15 February 2014 17:01, Paul Phillips <paulphillipsdidsbury at gmail.com> wrote:
> New head is working consistently - it always finds the right stream.
> Occassionally it croaks early leaving a FLV filem presumably due to
> internet drop out
> Also sometimes the file is over 4gb and so stops early, so I will try
> your latest RTMPDUMP GB
> thanks
>
> On 12 February 2014 18:55, Paul Phillips <paulphillipsdidsbury at gmail.com> wrote:
>> Pleased to report the new HEAD successfully found the Snowboarding
>> live stream this evening, and recorded the whole thing (2GB). I'll
>> test it further tomorrow.
>>
>> On 12 February 2014 14:59, dinkypumpkin <dinkypumpkin at gmail.com> wrote:
>>> On 11/02/2014 20:55, Paul Phillips wrote:
>>>>
>>>> I think the latest Git Head is picking up the live stream from the
>>>> player page but something wierd is happening at the end when the
>>>> stream finishes. That's my hunch. The player pages seem to have
>>>> things feeding into them - eg the main channel sometimes feeds into
>>>> them. It's as if they are channels in their own right with different
>>>> feeds going into them
>>>
>>>
>>> Seems plausible, but I've no real idea. It still seems strange that a
>>> static resource like one of the event guides would overwrite a live stream.
>>> I don't understand how an output file would be overwritten at all unless
>>> they're monkeying with the streams and rtmpdump gets confused. It's
>>> impossible to tell from the log what is going on.
>>>
>>> I've made another change to HEAD that refreshes the values of <dldate> and
>>> <dltime> for each download attempt for a live stream. Those two parameters
>>> are in the default value of <fileprefix> for live streams, so the effect
>>> would be to create a new output file every time rtmpdump croaks and
>>> get_iplayer restarts the download. That should probably be in get_iplayer
>>> anyway. I don't know if it will completely prevent files being overwritten
>>> on your machine, but give it a try if you're feeling brave.
>>>
>>> Another approach would be to choose a single CDN and quality (e.g.,
>>> --modes=flashhd1) and --retries=1 to prevent additional download attempts if
>>> rtmpdump croaks. But if it chokes in the middle of the event, that will be
>>> the end of the recording.
>>>
>>> Anyway, I'm throwing in the towel on this. I'll leave the changes in HEAD
>>> until the Olympics are over, though. As you said, you can still use the
>>> "olympics" branch version of get_iplayer with playlist URLs picked out of
>>> Firefox web console or similar. For anyone keeping score, that means you
>>> can fall back to the earlier instructions here:
>>>
>>> http://www.mail-archive.com/get_iplayer@lists.infradead.org/msg05225.html
>>>
>>>
>>>
>>> _______________________________________________
>>> get_iplayer mailing list
>>> get_iplayer at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/get_iplayer
>>
>>
>>
>> --
>> Paul Phillips
>
>
>
> --
> Paul Phillips
--
Paul Phillips
More information about the get_iplayer
mailing list