gbpvr.mdb file size

[chud]

i've hit what has to be a new record for gbpvr.mdb size ratio. in anticipation of the new gbpvr version upgrade, i was going to back up my gbpvr directory and found the gbpvr.mdb occupying an unholy 1GB of disk space! i tried running the config app to compress it down and there was no change. instead i shut down all GBPVR processes and did a compact and repair in MS access. the final file size? that would be 6.3MB... something is definitely amiss.

i am wondering if it has something to do with using Slimm GBPVR and too many processes fingering the database. can anyone else with this combination of software report such horrors?

[roy]

My .mdb file was also growing unreasonably, and I did determine that slimmgbpvr seemed to be the culprit of holding it open so it wouldn't compact. After disabling slimmgbpvr my .mdb file stays at a reasonable size.

[sub]

This is just a sad side effect of using MS Access for the database. These databases never reclaim unused space, even when records are deleted. The rate at which it will grow is determined by how many records are changing. Worst affected will be those with 'complete epg reload' enabled, and a large number of channels.

The new release has logic that will try to auto compact the database after the EPG update, but this can only occur if no external process holds a connection to the database (ie, like slimmgbpvr).

[chud]

super. thanks for the info.

[Mister Slimm]

If you were using Slimm GBPVR (which maintains a connection to the GB-PVR database, I have created a new beta version that allows GB-PVR to compact.

BETA v1.1.2258.32867

As always, please note that this is a beta version. Comments appreciated.

Features:

• Releases connection to database around time of EPG update to allow GB-PVR to compact and repair the database after update completed. GB-PVR is given half-an-hour to update the EPG and compact and repair the database.
  

forum entry and download link

[movie_lover]

I had not updated GBPVR from an earlier version of about a year ago - A testament to the stability of that set-up.

When I went to copy a movie file to that machine about four weeks ago, I got a windows error "insufficient disk space". After my initial WTF? reaction, my investigation showed a GBPVR.mdb file of (wait for it...) OVER 60GB!

Holy cow.

Holy cow....etc.

I just deleted it and started again.

Can any one beat this? Go on I dare you.....

movie_lover

[Mister Slimm]

... OVER 60GB!

That's somewhat astonishing as the Microsoft Access database system only supports a filesize of up to 2Gb!

Microsoft Access specifications

[wannabepvr]

This is astonishing! I am completely shocked. You could go a whole year without tinkering with you set-up? Amazing.

(Oh…hang on… did I miss the point? Yes 60GB is big.)

[movie_lover]

That's somewhat astonishing as the Microsoft Access database system only supports a filesize of up to 2Gb!

Microsoft Access specifications

Maybe it was a filesystem error or something.

All I know is that the file size was indicated as over 60GB and when I deleted it, 60GB of space was available on the HDD :confused:

As for not tinkering with the system for a year, isn't that the point of a good PVR? It did take a lot of tinkering to get right in the first place, and I certainly felt like defenestrating the PC a couple of times during the process:mad:

I am currently going through the same process with the new MB and graphics adapter as the big electrolytic capacitors on the old MB gave up the ghost. Oh well only another month or so of pain........

movie_lover

[jsteele]

I thought mine was bad when it hit 30 MB :-)

The biggest negative I've seen from the database growing is when using the web interface. I find that when it gets above about 10MB someone accessing the web interface causes the video/audio to "stutter". And doing episode searches in the web interface can even cause the audio to stop altogether requiring me to exit/reenter LiveTV.

Iv'e tried letting the new release compress method work but in my case it doesn't seem to have the desired effect. So I'm back to the Stop GB/Compress/Start GB approach. I have a batch configured to reboot the system, compress the database and start GB weekdays about 8AM, after the EPG update, when no one is normally using the system (it doesn't run on weekends). During the week this keeps the database in the 8-9MB range while over the weekend it grows to the 25-30MB range but Monday morning compresses back to the 8-9MB range. This does wonders for the web interface; you generally can't tell when someone is accessing it.