Signed programmes not downloading

[dinkypumpkin]

On 23/02/2012 14:49, Rob Dixon wrote:

> OK, but it seems counterintuitive that if I enter
>
>    get_iplayer Horizon
>
> without specifying any specific version, I get
>
>    328:    Horizon - 2009-2010: 4. Who's Afraid of a Big Black Hole?, BBC Two, Audio Described,Factual,Science&  Nature,Science&  Technology,TV, default,audiodescribed
>    329:    Horizon - 2011-2012: 7. Playing God, Audio Described, Audio Described,Factual,Science&  Nature,Science&  Technology,Sign Zone,TV, audiodescribed,signed
>
> but then I use
>
>    get_iplayer 329 -g
>
> and it tells me
>
>    WARNING: No programmes are available for this pid
>
> So I have to notice that the listing is of a signed version and say so
> when I ask for the download, when get_iplayer knows the version is has
> displayed is a signed one all along! The fix I made was just to modify
> the URL if the programme selected from the match list happened to be signed.

It's not counterintuitive given the default behaviour.  To be fair, that 
default behaviour isn't explicitly referenced in the help screen, a 
situation which I can remedy when I have a moment.  I should also point 
out that if you always want signed programmes when they're available, 
just use --prefs-add to make --versions=signed a permanent setting, or 
add it to your options file directly.

As to whether the default behaviour should be changed to automatically 
fall back to an alternate version if the default version isn't 
available, some questions immediately arise:  If both audiodescribed and 
signed versions are available, which one do you download?  What if the 
user wants audiodescribed but only signed is available?  It seems to me 
like this is a place where the user needs to explicitly declare a 
preference based on availability, as shown in the search output listing. 
  FWIW, such a fallback mechanism would affect a tiny number of 
programmes (26 out of 905 in today's count), so the utility would be 
limited.

If you want to pursue this, I would suggest surfacing the issue in a new 
thread on this list to see if any other useful input emerges.  If you 
take it as far as proposing a patch for get_iplayer, your fix referenced 
above is not the way to go.  All you've done is silently force an 
override of the expected behaviour, which isn't a good idea.  The task 
you're trying to accomplish should be done earlier in the processing, 
e.g., by manipulating the version list based on cache contents.