On 18/04/2012 21:51, Andy Bircumshaw wrote:
--pvrqueue clearly *isn't* a "delayed search" mechanism, because it *always* converts the search results into a PID.
It may look up the PID for programmes to construct the pvr search params, but the search itself isn't handled differently for a queued pvr entry. get_iplayer still searches the cache all over again when the pvr runs.
If the programme doesn't exist in the cache, using --pvrqueue won't add it to the queue.
I suppose that's the nub of issue. It does seem strange to have something called a cache that contains references to things that don't yet exist. I guess I'm coming around to your point of view.
To me --pvrqueue should reflect the same results that the same search does (without --pvrqueue).
I say go ahead and change it. It would certainly be easier to explain that behaviour. I think all you'll need to do is remove that forced option setting in Pvr::queue(). I would expect very few people, if any, to notice. For one thing, --refresh-future is broken for anyone who doesn't have the Git version of get_iplayer.
I'm not trying to be bullheaded here, I just don't understand the logic that would support the current behaviour.
Who knows? That was already in get_iplayer when Phil Lewis dropped it. It still makes sense to me that someone might want to queue up a download for the following week, but in the end it should be up to the user to set --future for both searching and pvr queuing.
_______________________________________________ get_iplayer mailing list [email protected] http://lists.infradead.org/mailman/listinfo/get_iplayer
