More Sophisticated Retries
#1
I'm running get_iplayer 3.07.0 from a Windows 7 command prompt.

When re-trying a download would you consider adding a feature that checks the internet connection before changing modes?

It may be the case that a download problem requiring a re-try is not caused by the content supplier, but by losing your internet connection. Before re-trying a download, a simple ping of bbc.co.uk should suffice. If no response is received from the ping, it should be re-tried, say every minute for the first 5 minutes then every 5 minutes with an option for the user to abort the download. These attempts to connect to the internet should not be counted as download attempts since it is impossible to download without an internet connection, nor should get_iplayer move on to the next download since that would be futile without an internet connection.

One quirk springs to mind. Consider the scenario where you're in a coffee shop using their free Wi-Fi to run some get_iplayer downloads. A staff member resets the router causing you to lose the connection temporarily, but due to their set up,  you're required to go to a login page and re-enter the password before you can continue. With this in mind, when checking for an internet connection the response headers should be checked to confirm they came from bb.co.uk and not, for example, great.coffee.net/login.

I've had a couple of occassion where I've ended up with lower quality downloads because of this. Most recently, when downloading a BBC Proms programme that was over 2 hours long in hlshd mode, I noticed my download was at over 90% and went off to make a cup of tea. When I returned to my computer I found it had done a few re-tries because the internet connection was lost temporarily and it was now downloading at a much lower quantity. What had happened was that a household member was having connection problems and had switched off the router, waited a bit, then switched it back on. I interupted get_iplayer and was able to re-do the download at a mode I selected. Unfortunately, because the programme was very close to expiry, I only had time to download it at a non-hd quality. It was frustrating that get_iplayer had discarded all the 90%+ hlshd data and was writing lower-quality data to the .ts file.
#2
(18-12-2017, 12:01 AM)User 04 Wrote: When re-trying a download would you consider adding a feature that checks the internet connection before changing modes?
It's a no from me. I'm not willing to support such functionality. If you or anyone else should wish to implement this in get_iplayer yourself, I'm obliged to caution you: If you want to add such new features, you must take over as maintainer.

A successful request to a BBC web site may tell you that your connection is alive, but it says little about whether or not a subsequent download attempt will be successful. Only you would know if the connection actually dropped, and the download may have failed for other reasons, as is far more often the case. Sure, you waste a few cycles if get_iplayer goes through failed download attempts after your connection drops, but that doesn't do any harm if there is no connection. Still, I would entertain a pull request for a --download-abortonerror option that would force get_iplayer to exit after the first failed mode. People who cycle their routers or use sketchy cafe wi-fi could avoid unnecessary screen churn, and people who know they have dodgy connectivity might prefer to bail out quickly and try later if upstream isn't behaving.

If you don't want get_iplayer to fall back to lower-quality streams, then configure it to only attempt the mode(s) of interest, either permanently in preferences or for a single download via command line. If your connection drops you'll then be left with a partial download of the desired quality. Downloads are resumable, so once the connection is restored, just re-run the same get_iplayer command to complete the download.  You have the means to run get_iplayer automatically with the PVR function. Downloads that fail during one run should be picked up in the next.
#3
My suggestion was way overly-complicated. The --download-abortonfail option introduced in 3.09 is the ideal solution.

Thanks.