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