EPG Update repeats if GB-PVR restarts within the hour

[Major Hostility]

I noticed something last week, and again today during an update to 96.12 that seemed worth mentioning.

If I restart GB-PVR during the EPG Update "hour" it seems like it wants to go ahead and rerun the EPG update, even if it's already done it today.

I noticed this most particularly because I had been running the Config.exe application to compact the DB after the EPG update completed and it kept going back out and reloading the EPG, causing me to try and compact again ...

I haven't seen the "auto compact" after EPG update behavior work yet that was added to 96.08, so maybe that's not working as well as it could.

[sub]

I noticed something last week, and again today during an update to 96.12 that seemed worth mentioning.

If I restart GB-PVR during the EPG Update "hour" it seems like it wants to go ahead and rerun the EPG update, even if it's already done it today.

I noticed this most particularly because I had been running the Config.exe application to compact the DB after the EPG update completed and it kept going back out and reloading the EPG, causing me to try and compact again ...

If you restart the recording service during the EPG update hour, then it'll do the update again. This is the expected behaviour. The time of the last EPG update is just some that is held in memory, so restarting the recording service loses this piece of info. The user shouldnt be restarting the recording service often, so this is fine.

I haven't seen the "auto compact" after EPG update behavior work yet that was added to 96.08, so maybe that's not working as well as it could.

I suspect one of the utilities or plugins you're using is holding the connection to the database. This means it wont be possible for the compaction to occur.

[Major Hostility]

I suspect one of the utilities or plugins you're using is holding the connection to the database. This means it wont be possible for the compaction to occur.

The only plugins I have loaded are the "MVP Tray Icon" which doesn't do any DB access, and "MVP Screen Position" which I believe only interacts with config.xml.

I did have to load XRecord after updating to 96.08 since the regular Recordings screen quit working with that odd "cast information" problem, but I've fixed that now so I'm back to just the 2 MVP plugins.

I'll watch it for a few more days and see if it manages to auto compact.

Does the regular "GBPVRTray.exe" application open any connections to the database?

[sub]

If you're actively using GB-PVR at the time, this will have database connections as well, and can potentially stop the compaction from occurring.

What normally happens is when the screen saver kicks in, GBPVR.exe drops any cached connections it has to the database, so if the compaction occurs when the screen saver is active, it'll most likely succeed.

Another thing that can stop the compaction from occurring is a recording scheduled in the next hour.

[Major Hostility]

What normally happens is when the screen saver kicks in, GBPVR.exe drops any cached connections it has to the database, so if the compaction occurs when the screen saver is active, it'll most likely succeed.

My primary output for GB-PVR is an MVP device that's off during the day, so the only active copy of GBPVR.exe is the one running in the background waiting for the MVP to wake up. Does the MVP server version of GBPVR.exe also monitor the screen saver status?

Is there anything in one of the log files that would indicate any errors during the compact process?

[sub]

Does the MVP server version of GBPVR.exe also monitor the screen saver status?

Yes, it'll still be showing the screen saver even if the MVP is not turned on to show it.

Is there anything in one of the log files that would indicate any errors during the compact process?

You could try posting GBPVRRecordingService.exe.log. It probably wont show much though, since its JetComp.exe that encounters the problem if database connections are getting in the way. You should at least be able to see if it tried to compact the database.

[Major Hostility]

I found several entries in GBPVRRecordingService.exe.log indicating that it did attempt to compact the database after today's EPG update, however, the it does not appear to have been successful.

I ran Config.exe and set the MVP autostart value to 0 to see if the GBPVR.exe running in MVP server mode was the culprit. The DB compacted normally when I exited Config.exe.

The EPG update ran again a few minutes later, since I'm still within the update hour, but the request to compact the database seems to have run while the DB update was still running, and the entry "DB Compaction requested, about to start..." did not appear in today's log:

Code:

3/14/2006 12:24:29 PM.687    INFO    [120]    Running PostUpdateEPG.bat
3/14/2006 12:24:29 PM.843    VERBOSE    [23]    flushDatabaseConnections()
3/14/2006 12:24:29 PM.906    VERBOSE    [23]    processing request to reload schedule
3/14/2006 12:24:30 PM.203    VERBOSE    [120]    RequestDatabaseCompaction()
3/14/2006 12:24:30 PM.421    VERBOSE    [23]    RecordingFactory.loadSchedule()
3/14/2006 12:24:30 PM.421    VERBOSE    [23]    getValue cached value: /settings/AutoRemoveMissingRecordings : true
3/14/2006 12:24:30 PM.421    VERBOSE    [23]    getDatabaseConnection() creating new connection
3/14/2006 12:24:30 PM.437    VERBOSE    [23]    getDatabaseConnection() creating new connection
3/14/2006 12:24:30 PM.468    VERBOSE    [23]    checking recordings

[Major Hostility]

Compaction failed again today.

I find it interesting that although the "RequestDatabaseCompaction()" entry is showing up near the end of the EPG update, the rest of the entries, like "DB Compaction requested, about to start..." are not. Is this because the call to "RequestDatabaseCompaction()" is coming to early, while the app is still "checking recordings"?

Code:

3/15/2006 12:05:25 PM.890    VERBOSE    [23]    flushDatabaseConnections()
3/15/2006 12:05:25 PM.890    INFO    [120]    Running PostUpdateEPG.bat
3/15/2006 12:05:26 PM.000    VERBOSE    [23]    processing request to reload schedule
3/15/2006 12:05:26 PM.390    VERBOSE    [120]    RequestDatabaseCompaction()
3/15/2006 12:05:26 PM.500    VERBOSE    [23]    RecordingFactory.loadSchedule()
3/15/2006 12:05:26 PM.500    VERBOSE    [23]    getValue cached value: /settings/AutoRemoveMissingRecordings : true
3/15/2006 12:05:26 PM.500    VERBOSE    [23]    getDatabaseConnection() creating new connection
3/15/2006 12:05:26 PM.500    VERBOSE    [23]    getDatabaseConnection() creating new connection
3/15/2006 12:05:26 PM.531    VERBOSE    [23]    checking recordings

[Major Hostility]

Today, the call to RequestDatabaseCompaction() occurred after the "checking recordings" phase completed, and the DB did indeed compact correctly, so it looks like this feature works if called after the EPG is finished reloading.