SheduleRecording() locks database

[cb123]

While looking into occasional crashes caused by the database being locked, I discovered that making a number (40 to 100) of calls to SheduleRecording() in a short period of time would lock the database. Sometimes after a number of 30 second timeouts the database would recover and GBPVR would respond to inputs, but most often it would have to be killed with the task manager and then restarted.

To demonstrate the problem I added the following code to sub's HelloWorld example:

Code:

protected override void handleCommand(string command)
{
... snip ...
    case "Button 3":

    // start of SheduleRecording() test code
    Logger.Verbose("** Starting");
    IScheduleHelper scheduleHelper = ScheduleHelper.getInstance();
    IList allChannels = scheduleHelper.GetListingsForTimePeriod(DateTime.Now.AddDays(1.0), DateTime.Now.AddDays(5.0));
    IList programmeList =  ((Channel)allChannels[0]).getProgrammeList();
    Logger.Verbose(string.Format("** About to schedule {0} recordings", programmeList.Count));
    int cnt = 0;
    foreach (Programme programme in programmeList)
    {
        cnt++;
        Logger.Verbose(string.Format("** About to schedule {0,4} {1}", cnt, programme.getTitle()));
        ScheduledRecording scheduledRecording = scheduleHelper.SheduleRecording(
                                                programme.getChannelOID(), programme.getStartTime(),
                                                programme.getEndTime(), programme, 0, 0, programme.getTitle());

        Logger.Verbose(string.Format("** ScheduleRecording.status: {0}",
                            scheduledRecording == null ? "NULL" : scheduledRecording.getRecordingStatus().ToString()));
    }
    Logger.Verbose("** Finished");
    // end of SheduleRecording() test code

    setPopup(new GBPVRX2.Popups.PopupMessageBox(this, "The user clicked " + command, "OK", "Cancel"));
... snip ...
}

The test code attempts to schedule four days of consecutive programs on the same channel when one of the buttons is selected. If the database is locked and then recovers after a 30 second timeout, the program is not added to RECORDING_SCHEDULE but the failure is not indicated by the returned ScheduleRecording being null. Slowing the test program with calls to Thread.Sleep() keeps the database from being locked.

The attached logs are from a run on a new installation of GBPVR (RECORDING_SCHEDULE was empty) where the 98th call to SheduleRecording() locked the database.

System: 2.4 GHz Intel CoreDual, 3 GB ram, XP Pro/sp3, HVR-1600

[fla]

Excellent bug report. I'm surprised nobody replied although it was right before xmas. I think someone here is running into this same bug by rapidly calling CancelScheduledRecording as you are calling SheduleRecording. The end result is the same with an error about the database being locked.

Anyone know of a fix for this? Could this be a question of an old/obsolete System.Data.SQLite.dll?

[cb123]

fla,

When I first started using GBPVR recording schedules changes were processed fairly quickly. As I added more recurring schedules and accumulated old recordings on the hard drive, I started to get program freeze/lockup of more than 30 seconds after making a change. The worst offender was adding or canceling a recurring schedule. After every long delay GBPVRRecordingService.exe.log would have a entry saying that 'The database file is locked'. There was no difference in behavior between using the built in guide, TVListings plugin, or my own guide plugin to make changes.

At the time of my first message, I had approximately 2 weeks of EPG, 40 recurring schedules, and 400 old recording on the hard drive. Since then, I have eliminated the locked database problem by cutting back to 3 days of EPG, 20 recurring schedules, 100 old recordings, and adding a 0.5 second delay between SheduleRecording() calls.

The test code was intended to be a short and simple demonstration of how rapid call to SheduleRecording() could lock the database. I did not want to complicate the code to handle conflicts with already scheduled recordings or require a complicated initialization of gbpvr.db3. On my recording system, after setting everything up to avoid conflicts, the test code would lock the database after approximately 5 calls to SheduleRecording() .. a much smaller number than required on a fresh installation.

I was also surprised by no responses. I was hoping that someone would have a solution better than adding delays between calls to SheduleRecording() to keep from locking the database.

[sub]

I missed the original post. When I have some more time available, I'll give this a test and try to resolve it.

I am intending to update the SQLite DB provider in the 1.4.x release. I've also added an additional database index that might help.