Does this code lock the database?

[pastro]

Here are the lines of code that access the database

IScheduleHelper iSH;
[SIZE=2]IList myScheduledRecordings;
[/SIZE]

iSH = GBPVR.Backend.Common.ScheduleHelper.getInstance();
myScheduledRecordings = iSH.LoadRecordingSchedule();


I then search through all the recordings for descriptions files names etc.

Would this leave the database locked?
If the plugin is still active would that matter?



This is crossposted in the skiptool forum, but I figured you guys might not see it there..

[sub]

No, shouldnt do.

Database locks typically happen when DbReader is used, but not closed when reading is complete. (or if a database update occurs and the transaction not completed)

[pastro]

No, shouldnt do.

Database locks typically happen when DbReader is used, but not closed when reading is complete. (or if a database update occurs and the transaction not completed)

I don't dispose of iSH, it's a variable in the object. Does that matter?


This is the error that was posted that was attributed to skiptool for locking the database.



Is there anyway to tell who has it open?


The error I'm getting in GBPVRRecordingService.exe.log is:
2008-05-02 11:07:56.062 VERBOSE [5] RecordingFactory.save()
2008-05-02 11:07:56.062 VERBOSE [5] GETTING DATABASE CMD: update RECORDING_SCHEDULE set STATUS = 3, filename = ?, pre_pad_minutes = ?, post_pad_minutes = ?, quality_level = ?, manual_channel_oid = ?, manual_start_time = ?, manual_end_time = ?, capture_source_oid = ?, priority = ?, conversion_profile = ?, recording_group = ? where OID = 3151
2008-05-02 11:08:26.375 ERROR [5] Unabled to save ScheduledRecording: The database file is locked
database is locked
2008-05-02 11:08:26.375 ERROR [5] 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.xc979432fcc 5a510a(ScheduledRecording xe41d2b9d98dc1269)

[sub]

I don't dispose of iSH, it's a variable in the object. Does that matter?

Thats ok, you dont need to.

Is there anyway to tell who has it open?

The error I'm getting in GBPVRRecordingService.exe.log is:

2008-05-02 11:07:56.062 VERBOSE [5] RecordingFactory.save()

2008-05-02 11:07:56.062 VERBOSE [5] GETTING DATABASE CMD: update RECORDING_SCHEDULE set STATUS = 3, filename = ?, pre_pad_minutes = ?, post_pad_minutes = ?, quality_level = ?, manual_channel_oid = ?, manual_start_time = ?, manual_end_time = ?, capture_source_oid = ?, priority = ?, conversion_profile = ?, recording_group = ? where OID = 3151

2008-05-02 11:08:26.375 ERROR [5] Unabled to save ScheduledRecording: The database file is locked

database is locked

2008-05-02 11:08:26.375 ERROR [5] 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.xc979432fcc 5a510a(ScheduledRecording xe41d2b9d98dc1269)

It was most likely locked before that call happened. Unfortunately only GB-PVRs SQL statements are logged, not SQL calls performed directly by plugins or utilities, so we're not able to see what other plugins were doing. There is no SQLite tool that I know of for seeing all queries that occur.

Its probably best to advise the user to remove all the 3rd party plugins & utilities, then add them back in one at a time when they are confident the current set arent causing any problems. It could be a lengthy process, but there is no easy alternative.

[mkenyon2]

Sub, I hope you're still watching this.

I've been removing Plugins, trying to see what locks the database. I have a few more to remove, but here's a current shot, with the problem still existing.

From a clean boot, I go into PVRX2, I go into Recordings, I select a recording that has no MPG (the file was removed previously).

The record does not get removed.

I have enclosed logs, a screen shot of my plugins, and a file from Process Monitor, called 'LogfileFromProcMon.CSV' that shows activity against the DB3 file from the time I start PVRX2 to the time I try to delete and then I close PVRX2.
(I stripped some of the data out of the ProcMon file.)

Can you give me any insight on this?

[mkenyon2]

Look at line 43844. I think that's around when I tried to do the delete.

[sub]

That looks like exactly the sort of info required to track it down, but you dont seem to have the PVRX2.exe.log that covers time of day indicated in your CSV file, so its hard to see what was happening at the time.

[pastro]

Look at line 43844. I think that's around when I tried to do the delete.

If you want I could put together a version of skiptool that doesn't access the database at all as a test. Also, are you using the queue or just the commercial marking part?

[mkenyon2]

Hmm... so I went down to bare minimum, Live TV and Recordings... I could go in and delete recordings. I started adding, one plugin at a time then starting PVRX2.exe.
I did MovieWiz... good to go.
Skip Tool... good to go.
GameZone... good to go.
DVDtoMPEG... locked...

HOWEVER, when I turn of DVDtoMPEG it's still locked.

One note, it seems that if I go in and out of PVRX2 and/or Config a number of times, I then get the locking issues, regardless of plugin (though it could be a plugin and I'm missing something).

At one point the file 'gbpvr.db3.Locked' showed up in the gbpvr folder. Removing that cleared up locking issues even with the same plugins enabled that were enabled when it was locked.

I've been getting lock errors in config.exe.log and PVRX2.exe.log.

I was able to go in and delete a few things, then got the locked issue in the same session (period from when I started PVRX2 till I closed it) so I got the log right away. Here it is.

[sub]

Have you been able to reproduce it with no plugins installed?

If you can reproduce the error again, then post another one of the filemon cvs files along with a complete set of GB-PVR logs (covering the time the error occured), then I'll take another look.

Make sure there is no locks in place before you start though, so either reboot or restart everything.