Programme in Series has `firstbcast' But no `available'.

Vangelis forthnet northmedia1 at the.forthnet.gr
Fri May 5 09:23:31 PDT 2017


On Fri May 5 13:56:01 BST 2017, Ralph Corderoy wrote:

> Is the programme in your cache?  It isn't here.

 Hello there Ralph :-)
Apparently it is:

get_iplayer pid:b08nyc9z =>

=============================================
C:\Program Files\get_iplayer>get_iplayer pid:b08nyc9z
get_iplayer 3.00-windows.0, Copyright (C) 2008-2010 Phil Lewis
  This program comes with ABSOLUTELY NO WARRANTY; for details 
use --warranty.
  This is free software, and you are welcome to redistribute it under 
certain
  conditions; use --conditions for details.

  NOTE: A UK TV licence is required to legally access BBC iPlayer TV content

Matches:
3221:   Homes Under the Hammer: Series 21 - Episode 8, BBC One, b08nyc9z

INFO: 1 Matching Programmes
=============================================

And according to
http://www.bbc.co.uk/programmes/b08nyc9z/broadcasts
pid=b08nyc9z was (only) broadcast on 2017/04/27, 10:00BST,
with no repeats scheduled...
Have you performed --cache-init immediately after you
updated to GiP 3.00? Maybe your tv.cache has gaps.
Might need to rebuild the last fortnight or so...

get_iplayer -f --refresh-limit-tv=15 --index-maxconn=10

> But why should I debug the lack of download each time
> and realise --future is needed because of a future repeat?

Fair point...

> Instead, I've long used --future
> and it hasn't caused problems.

FWIW, with next bug-fix release where "Known Issue" #3
will, hopefuly, be fixed, you need not supply --future
unless you
1. have refreshed the cache to include "future" listings:
 -f --refresh-future
2. indeed are trying to download a prog already
available in iPlayer but is to be broadcast later,
in the "future" (that's how I interpret the --future entry
of GiP's --longhelp...).

> I want the delay of updating the cache to occur when I choose,
> not "randomly" when it happens to be out of date
> in the middle of several queries.

 I see what you're saying, but, TBH, I haven't witnessed
time-consuming tv.cache auto-updates with GiP 3.00
when more than 4hrs have passed since its last run...

https://github.com/get-iplayer/get_iplayer/wiki/release300#cache-updates

says

>> the cache is now updated only once per calendar week
>> (Mon-Sun). The cache will be updated the first time
>> get_iplayer runs during the week.

> I manually and regularly refresh when I'm happy to
> walk away and leave it going.

...Just as long it is at least once a calendar week...
And for radio, I do have to do this manually, too,
because when you start the CLI radio.cache is not
auto-refreshed...

> BTW, the help still says four hours.

...Perhaps this has to be amended...
In GiP 3.00, the switch --ybbcy is internally set
permanently, one of its implications is that
the cache is auto-updated only once per
calendar week, see

https://github.com/get-iplayer/get_iplayer/commit/14d26af

>> The tv programme data will only be updated
>> once per calendar week. However, radio indexing
>> must be performed at least once every 7 days
>> to prevent gaps in the data.

Also see the link above for cache-updates...

Best regards 




More information about the get_iplayer mailing list