Hi Vangelis,
> > With 3.00, programme PID b08nyc9z has no `available' field when I
> >
> > ./get_iplayer --no-purge --future -e 31536000 -i --pid b08nyc9z
>
> Can't repro here
...
> I get the same when omitting --future switch.
$ ./get_iplayer --no-purge --future -e 31536000 -i --pid b08nyc9z | grep
available
$ ./get_iplayer --no-purge --future -i --pid b08nyc9z | grep available
$ ./get_iplayer --future -i --pid b08nyc9z | grep available
$ ./get_iplayer -i --pid b08nyc9z | grep available
$
Is the programme in your cache? It isn't here.
$ wc -l /home/ralph/.get_iplayer/tv.cache
6183 /home/ralph/.get_iplayer/tv.cache
$ grep b08nyc9z /home/ralph/.get_iplayer/tv.cache
$
With `./get_iplayer --debug -i --pid b08nyc9z' I see many JSON and XML
being fetched, but the only mention of `available' is when the "Cache
format from existing tv cache file" is INFO'd.
> BTW, AIUI, --future should be only used for those programmes affected
> by known issue 3:
>
> https://github.com/get-iplayer/get_iplayer/wiki/issues
But why should I debug the lack of download each time and realise
--future is needed because of a future repeat? Instead, I've long used
--future and it hasn't caused problems.
> And why the -e switch? in GiP 3.00 the cache is only refreshed once
> weekly...
Because 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 manually and regularly refresh when I'm happy to
walk away and leave it going. BTW, the help still says four hours.
expiry => [ 1, "expiry|e=n", 'Config', '--expiry, -e <secs>',
"Cache expiry in seconds (default 4hrs)"],
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
_______________________________________________
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer
