[FIXED] get_iplayer 3.17.0 re-indexes programmes before every download with —refresh-future
I have just installed the newest release.

I ran a search using get_iplayer Gardeners World

get_iplayer indexed the tv programmes, then gave me the expected list

I then input get_iplayer 2507 to download the latest Gardener's World

get_iplayer indexed the tv programmes again, then downloaded the programme.

I tried running my web pvr and it indexed the tv again

When the web pvr completed I immediately ran it again, and again it indexed the tv.
Follow our instructions to provide a proper report so we can see what is happening on your system.

I am running the latest Windows 10 as updated on Tuesday.  3.16 worked fine after that update.

get_iplayer 3.17.0-MSWin32

1. get_iplayer gardeners world --verbose >e:\getiplayersearch.txt  (file attached)
2. get_iplayer 2489 --force --verbose >e:\getiplayerdownload.txt (also attached)

The pid is b0bg73ct and I have now downloaded it successfully twice - hence the --force in the command above

No errors received.

When I sat down to generate the verbose files, I noted that my tv.cache file was timed at 17:39, and the tv.cache.old was 13:29.  I checked and the pvr had just run successfully and had updated the cache and downloaded a programme.

I ran the first command above, and my tv.cache was updated at 17:47.

I ran the second command and the tv.cache updated to 17:50

You can see from the verbose files that both commands updated the cache.

I hope that's sufficient info.

Oh - the P: drive which I download to is a network linked drive in my server PC, but apart from the odd .temp version of a download this has never caused a problem and didn't this evening when I generated the verbose files.

I started the thread with a query to see if anyone else had the problem, it would appear not.

Along with many others I just want to say thank you for maintaining this excellent tool.

Attached Files
.txt   getiplayersearch.txt (Size: 38.56 KB / Downloads: 137)
.txt   getiplayerdownload.txt (Size: 46.29 KB / Downloads: 139)
Thanks for the logs. I suspect you have corrupted your cache. Delete all your cache files and rebuild them, then try again.
Initial tests seem OK - Thanks.

I'll keep an eye on it for a day or so.
It is happening again today.

get_iplayer gardeners world --verbose >files_attached

I'm not still trying to get Gardener' World - just using it as the example

Two consecutive searches - files attached. They are timed 1 minute apart.

The line

INFO: Cache refresh limit (tv): 2018-08-18T15:46:11+00:00

is interesting

Attached Files
.txt   getiplayersearch1.txt (Size: 39.94 KB / Downloads: 137)
.txt   getiplayersearch2.txt (Size: 39.94 KB / Downloads: 118)
Do you have refresh future enabled?

I was seeing this behaviour with 3.16, rebuilding the cache would fix for a while and then it would come back.

I stopped using refresh future and the problem disappeared completely.
I do, I'll give your suggestion a try. Thanks
I turned off refresh future but it looks like it is still updating tv cache before it should.

My last run of pvr updated the cache at 23:14. I tried a search using get_iplayer gardeners' at 23:37 and it again refreshed the tv cache, with no additions to the cache. The pvr run added nothing too.

I can live with it - it doesn't cause any downloads to fail.
I should have added I turned off refresh future and deleted and rebuilt the cache file.
Having refresh future on seems to cause intermittent cache problems, with refresh future on there are more occasions when no programmes are added to the cache and that seems to trigger the problem.

A tricky one for Dinky to find as it is intermittent.......
I did do the delete and rebuild. Thanks.

My decades of programming for a living makes me agree with you about finding the problem. Seems not many people have it anyway.

At least if people come here looking they have some suggestions to try.
--refresh-future won't affect refresh trigger unless a future programme listing happens to contain garbage data that breaks the structure of the cache file and thus screws up subsequent commands. You'll have to inspect the cache file to see if something looks amiss. If you can't tell, stick it on a postbin site and I'll take a look.

If the cache file looks OK, you may want to perform a better test. Both times you submitted logs, your cache had just been updated before you ran tests, so you wouldn't expect to see any cache additions. Therefore it isn't possible to tell if the cache isn't being updated at all or is corrupted on disk. Turn off any automated runs of the PVR so nothing else is touching the cache file. Then run 3 searches (with --verbose) with at least four hours between runs (allow a few extra minutes to be sure), and note the time of each run on the clock of the system where you ran it. Post all 3 logs.

I've had a look at the TV cache file and nothing untoward in it as far as I can see. Each entry on a single line.

I'll give your other suggestion a try tomorrow, but I'm confused as to what it will show.

Waiting more than four hours, I would expect the cache to be updated, whereas running a search and then a download within a couple of minutes I would not expect the second (download) command to re-update the cache, which is what is happening. Similarly running two searches in quick succession, with both updating the cache.
Just because the refresh runs doesn't necessarily mean anything is added to the cache. That appears to be the root of the problem. I thought I'd found a bug related to --refresh-future, but you said removing it doesn't change anything on your machine. It would help to have the output from a proper test on your machine for comparison with my tests.
Also: Perform your tests with --refresh-future.

I rebuilt without refresh-future at 22:40 yesterday and left everything overnight. Starting the first test now.
Here are the requested files, the name includes the time the commands were started.

I'll restart my PVR now.

Attached Files
.txt   getiplayersearch0855.txt (Size: 221.84 KB / Downloads: 240)
.txt   getiplayersearch1525.txt (Size: 29.32 KB / Downloads: 107)
.txt   getiplayersearch2000.txt (Size: 29.34 KB / Downloads: 112)
Thanks for the logs. They square with my results, so this is down to a bug. Until it is fixed, you'll continue see a lot of unnecessary cache updates with --refresh-future in preferences. --refresh-future  is of little real use, but if you don't mind all the extra updates, it's harmless (albeit wasteful) to keep it.
Thanks for that Dinky.

I'm glad I could help.

I had 30+ years of tracking down my own and other people's bugs - it can be a thankless and soul-destroying task. :)

Perl is somewhat different to the FORTRAN and Assembler I used to do.
To maybe ask a dumb question - how do you turn off refreshfuture?

I have refreshfuture 1 in my options (which I don't recall putting there), but deleting it (--pref-del) doesn't touch it and trying to add a zero value via --pref-add fails.

I'm also seeing exactly the same recurring cache corruption issue - I reported it before (here) and we ended up with the rebuild solution. As reported above, that works, but the issue recurs after a while.

Possibly Related Threads…
Thread Author Replies Views Last Post
  v3.18: PID-based PVR search indexes radio programmes without --type=radio errfmt 1 1,990 31-12-2018, 07:58 PM
Last Post: dinky
Bug [FIXED]  Index Numbers Overlapping in TV and Radio Caches when using --refresh-future User 04 3 3,516 30-09-2017, 09:59 PM
Last Post: dinky
  Recent 6 Music programmes not indexed due to incorrect --refresh-include value Dave F. 7 7,240 21-06-2017, 08:07 PM
Last Post: Dave F.
  Cannot download - "Ignoring Future Prog" (Top Gear / Charlie Brooker) markyk66 2 2,951 03-02-2015, 09:10 AM
Last Post: markyk66