Database locked during rectracker -purge

[Gedanken]

I don't use the whole CDK schedule infrastructure but I do make good use of the rectracker mechanism to purge repeats from my scheduled recordings. This has worked great until the last couple releases of GBPVR where I started getting this error when I invoke the command:

rectracker -purge -useOid

It will churn for a while, outputing the expected results and purging the first couple duplicates and then it will hang for about 30 seconds and issue an error:

Error System.Data.SQLite.SQLiteException: The database file is locked
database is locked
at System.Data.SQLite.SQLite3.Reset(SQLiteStatement stmt)
at System.Data.SQLite.SQLite3.Step(SQLiteStatement stmt)
at System.Data.SQLite.SQLiteCommand.ExecuteNonQuery()
at GBPVR.Backend.Common.x396614b3dae3b1da.x5e29b479fd4eab70(ScheduledRecording xe41d2b9d98dc1269, Boolean x29a0b54a36a7fcdf)
at GBPVR.Backend.Common.ScheduleHelper.CancelScheduledRecording(ScheduledRecording scheduledRecording)
at RecTracker.RecordingTracker.purgeWatchedShowsFromSchedule(Boolean bZap)
at RecTracker.RecordingTracker.Main(String[] args)
Stack at System.Data.SQLite.SQLite3.Reset(SQLiteStatement stmt)
at System.Data.SQLite.SQLite3.Step(SQLiteStatement stmt)
at System.Data.SQLite.SQLiteCommand.ExecuteNonQuery()
at GBPVR.Backend.Common.x396614b3dae3b1da.x5e29b479fd4eab70(ScheduledRecording xe41d2b9d98dc1269, Boolean x29a0b54a36a7fcdf)
at GBPVR.Backend.Common.ScheduleHelper.CancelScheduledRecording(ScheduledRecording scheduledRecording)
at RecTracker.RecordingTracker.purgeWatchedShowsFromSchedule(Boolean bZap)
at RecTracker.RecordingTracker.Main(String[] args)

There are two issues here.
1) The database shouldn't be locked.
2) When the error happens, rectracker still issues a 0 return code/error level so I can't detect the issue in my PostEPGUpdate batch file. This prevented my from working around the database locking issue by putting the call in a loop until the program terminated successfully.

I've got a reasonably large rectracker.mdb file and a good sized gbpvr.db3 database as well, although I have no specific data relating the size of the database to the issue.

I have seen some comments regarding some bugs in the SQLite providers used by GBPVR so I suspect that that might be the issue. I am hoping someone might have a fix to avoid triggering those issues. If it is a bug in the SQLite interface, I was thinking slowing down the query rate might help alleviate the problem.

[fla]

Part 1 of the problem you report seems to have already been reported here so it doesn't sound like it's rectracker related. As a workaround I created a version that will slow the loop that is making all the CancelScheduledRecording calls. If you set an environment variable as shown below in your batch file before calling rectracker, each CancelScheduledRecording call will be followed by a wait of that many seconds. You can play with the delay to find the smallest value that avoids the db lock bug but still runs reasonably fast.

Code:

set DBLOCKBUGDELAY=0.1
rectracker ...

For part 2 of the problem I created a version that returns 1 if rectracker exits due to an exception.

Let me know if it works around the problem. I guess I could put this in the official version if it works (with many warning comments around the delay thing).

[Gedanken]

I installed your special version expecting to validate my looping mechanism and then tweak the delay until it the problem disappeared....

but installing the new version make the problem go away even without specifying a delay amount. I'm guessing that the additional code to checl the delay parameter is sufficient to fix the problem, at least on my system.

If you decide to keep the delay environment variable, I suggest chaning the units to microseconds or something. It takes eons to complete with even a medium-sized fraction of a second.

I wasn't able to validate the return code part since I cannot reproduce the exception with the new binaries.

[fla]

Thanks for the feedback. Since sub has promissed to take a look at the issue in another thread, I'll wait to see if there is a real fix. If there is a real fix I'd throw out the workaround but keep the return code part. If there is no fix, I'd change the delay to milliseconds as you suggested. It's surprising that a single if statement adds enough delay to make a difference. There is no call to Sleep if the environment variable is not set or set to <= 0.0F. The value of the environment variable is checked only once before the loop.