Since updating to 2.95 and having HLS the default download mechanism, I don't seem to be able to resume downloads any longer. Worse: get-iplayer appears to overwrite the original mostly-downloaded file and restarts from scratch.
Have observed this both when I ctrl-c'd to continue downloading another time (as I could under rtmpdump), and when my connection dropped. The latter failed to auto-continue, too, with the following error:
WARNING: Retry recording for '[...]'
INFO: File name prefix = [...]
INFO: Subtitles not available for version(s): original
Can't locate object method "new" via package "Streamer::" (perhaps you forgot to load "Streamer::"?) at /usr/local/get_iplayer-latest/get_iplayer line 9097.
Resuming downloads from previous sessions is not supported with HLS or DASH streams. rtmpdump can do it for RTMP streams because it parses the structure and content of the partially-downloaded FLV file to find a resume point. However, it is unreliable and somewhat dependent on which build of rtmpdump you happen to have. That sort of functionality would be massive overkill for get_iplayer.
Alternative approaches are no good so long as ffmpeg is in the mix since get_iplayer can't control how it processes HLS playlists, and it doesn't yet support DASH. Once I get rid of ffmpeg as a downloader option, I may revisit this. However, I don't see any way to automate the resume process. You would have to feed several pieces of information from the previous run back into get_iplayer, and that would be overcomplicated for virtually all users.
There is limited capability for resuming HLS and DASH downloads after an interruption, but it can be thwarted if garbage data is retrieved when the retry is being initialised. There isn't anything get_iplayer can do about that, though I will improve that error message a bit.
Ah, that's a shame - rtmpdump's resume worked fairly reliably for me (...but I'll still stick with HLS rather than try the fla fallback you provide). If you ever are in a place where you can look at this, could the data required from the previous run to resume for future runs be associated with the cache record for the episode, to prevent the user having to supply it? Or store a metadata file along with the file (ala youtube-dl)?
Anyway, thanks for letting me know it's not just a borked install on my end, it's instead a limitation of the tools and formats that get_iplayer is forced to work with. It was just unfortunate that the first time I observed the behaviour was on a 10GB stream!
Love the program, even if it has cost me terabytes of space.
Cache is not an option. Dumping to a separate file might be feasible, but that would require a bunch of housekeeping faff that I'm not willing to implement or support. If I were able to make this work, it would just print some options to tack onto the subsequent command line. But, I'm dubious about trying to support that as well. It seems like a bad idea to implement something that: a) will be difficult to explain; b) has a risk of producing glitchy output files.