gbpvr.mdb size??

[groover km]

I have had a problem for a while with my set up - I can't access live tv on the MVP (Sub helped me with this), gbpvr takes 10 minutes to open on the PC, seemed to always be spinning it's wheels at 20-30% cpu...

Well tonight, I restart gbpvr from the config screen and watch task manager for 10 minutes as peak mem usage rises to 212MB, cpu racing - then it falls away to 48MB and 0% cpu. And lo, the MVP comes straight on.

I did some digging and found this in my gbpvr log:

10/5/2005 6:52:37 PM.781 VERBOSE [2] Adding: Right FM_RIGHT
10/5/2005 6:52:37 PM.781 VERBOSE [2] Adding: Home FM_HOME
10/5/2005 6:52:38 PM.234 VERBOSE [2] getDatabaseConnection() creating new connection
10/5/2005 6:59:50 PM.453 VERBOSE [2] getValue cached value: /settings/EPGProcessingMode : NORMAL
10/5/2005 6:59:50 PM.703 VERBOSE [2] getValue cached value: /settings/EPGProcessingMode : NORMAL
10/5/2005 6:59:51 PM.390 VERBOSE [2] SimpleScreenSaverTask created

I looked in the directory and gbpvr.mdb is over 300MB - does this sound right to you guys? I'm guessing that the delay is while it loads this and 'does it's thing'.

I have never reinstalled gbpvr in nearly 12 months; always updated over the top.

Would it be worth reinstalling, or am I going in the wrong direction?

Thanks in advance.

[Lindsay]

Wow, no wonder it is gagging. Mine is 670KB.

[sub]

Its probably mostly empty/unused space. Access databases arn't very good at reclaiming free space, and can quickly become fragmented and far larger than they need to me.

If you've got MS Access on your machine, you could open the gbpvr.mdb file and use the 'compact database' menu option.

GB-PVR will try compact the database when you click the ok button in the config app, but this wont always work. The compaction will only succeed if there are no connections to the database.

[AOSandman]

Microsoft themselves say that the DB will grow as needed, but will not shrink on it's own. Popping in & out of config usually works here, sometimes I'll use Access and do it manually.

[sub]

I only went as far as saying "tries" because I know lots of different scenarios can stop it from happening, all relating to processes holding connections to the gbpvr.mdb database.

[groover km]

Thanks guys, I've got Access 97 on one of my machines, I'll give it a try - I really wasn't looking forward to reinstalling from the ground up.

Sub: Cheers for the help mate, I never sent my logs at your last request as I began to suspect it was more an issue with something funky happening with my set up, rather than gbpvr... hopefully the above suggestion will have the desired effect. Thanks again.

[groover km]

UPDATE: I opened gbpvr.mdb in Access, ran "Compact and Repair Database...", and the file size went from >300MB to 90MB; wow.

I'm gonna test it tonight more thoroughly tonight, but on first look it certainly seemed to make a difference.

[jsteele]

To compact an Access DB however no one must be attached to it. A new utility application or service might be in order here.

The utility would either run as a system service or get kicked off after the EPG update and once a day periodically check to see if the recording service is idle and the main GBPVR is idle. If they are not idle it would go to sleep for a while and test again. Once it finds them both idle it would a) stop GBPVR b) stop the recording service c) use OLE to run MS Access to compact the database d) restart the recording service e) restart GBPVR. The whole process should take only a few tens of seconds and would keep the database compacted.

I wrote a Windows 2000 service application something like this once before to stop anything that was using an Access database, compact it and then copy to another machine in order to keep a testbed up to date with the live system so I know it's practical. I don't know C++ or .Net or I'd tackle it myself.