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 <paulphillipsdidsb...@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 <paulphillipsdidsb...@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 <dinkypump...@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@lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/get_iplayer >> >> >> >> -- >> Paul Phillips > > > > -- > Paul Phillips -- Paul Phillips _______________________________________________ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
