SlimmGBPVR - replacement for GBPVRTray

[Mister Slimm]

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.
  

Direct download link

[HtV]

BETA v1.1.2258.32867
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.

I would make that a little longer because GBPVR doesn't start right away at the set time but somewhere during the following hour, I think. That is why you can only select whole hours for EPG-update time.

[Mister Slimm]

I would make that a little longer because GBPVR doesn't start right away at the set time but somewhere during the following hour, I think. That is why you can only select whole hours for EPG-update time.

Right-O. What I'll do, I think, is add an option to set when it disconnects before and after the UpdateEPG hour. Mine only takes about 70 seconds to update but I only have five channels in the EPG.

[chud]

feedback: i am not sure that the latest build (BETA v1.1.2258.32867) with the mdb release for compaction is working for me. i have been steadily watching my database bloat up over the last few days.

mdb = 488MB
turn off SlimmGBPVR
perform manual guide update
mdb = 493MB
run and "OK" GBPVR config
mdb = 7.7MB

at this point it is hard to tell if the guide update is not running the mdb compression (obviously the manual update didn't) or if SlimmGBPVR is still getting in the way of this compression. i will have to wait a few days for the database to grow again and shutdown SlimmGBPVR manually before the scheduled update...

[Mister Slimm]

feedback: i am not sure that the latest build (BETA v1.1.2258.32867) with the mdb release for compaction is working for me. i have been steadily watching my database bloat up over the last few days.

mdb = 488MB
turn off SlimmGBPVR
perform manual guide update
mdb = 493MB
run and "OK" GBPVR config
mdb = 7.7MB

at this point it is hard to tell if the guide update is not running the mdb compression (obviously the manual update didn't) or if SlimmGBPVR is still getting in the way of this compression. i will have to wait a few days for the database to grow again and shutdown SlimmGBPVR manually before the scheduled update...

I coded the above version, tested it and it released the connection. When it does so, it makes a note in the log. Anyways, I noticed that my own db had grown considerably (I accidentally downloaded all channels in an EPG update instead of just the 5 I use, duh!). I looked in my log "Slimm GBPVR.log" and there was no entry for the disconnection. Bit odd, I thought, but I turned my attention to another project for a few days. Just come back to it today, read your post, took a closer look at the code and discovered a stupid bug where it only works on the day you first run it!

I shall post a bug-fixed version shortly. Thank you.

[Mister Slimm]

BETA v1.1.2265.39017

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

Bug fixes:

• UpdateEPG time was set when class was instantiated and never updated. This meant that the database disconnection code would never fire unless the UpdateEPG hour happened to fall before midnight on the day the class was instantiated.
  

Features:

• Time that the connection to the database is released can be set under Options->Advanced.
  

Direct download link

[chud]

well, my 2pm'ish update came and went and given the file size and the logs, i don't think SlimmGBPVR released the database. attached are the log files that i could find. where is the configuration data stored?

[Mister Slimm]

well, my 2pm'ish update came and went and given the file size and the logs, i don't think SlimmGBPVR released the database. attached are the log files that i could find. where is the configuration data stored?

Thanks for your feedback on this. It is more helpful than you can know. I am very poorly and have very short coding windows. According to your log the database released its connection and re-established it as I would expect.

Code:

SlimmGBPVR.exe Information: 0 : 06-03-15 13:55:00 : GBPVRdb connection closed during EPG update.
SlimmGBPVR.exe Information: 0 : 06-03-15 14:30:00 : GBPVRdb connection opened.

I'm issuing a GBPVRdb.Close() command just before the first log message but perhaps that isn't enough to actually release the connection. Perhaps I have to do something else to actually release it. I shall do this during my next coding opportunity.

My update runs at 7am (I've found that if I change the updateEPG time GBPVR tends to update very erratically for the next few days, but I'm sure it's just me!) and so issued the bug fix before my own update fired.

I did find another odd thing. Without my programme running, I ran the Config utility which also compacts on close and my db went down to about 4Mb in size. If I manually compact it in Access 2002, it goes down to about 1Mb! How weird is that?!

Please forgive me not being able to quite nail this problem and be assured of my continued attention and appreciativeness of your feedback.

[Mister Slimm]

Where is the configuration data stored?

What configuration data are you after?

The settings are stored in the registry under Current User/Software/Slimm Solutions/SlimmGBPVR but are all available to edit under the Options tab (and should only be edited from there).

[chud]

right! i checked there but somehow only saw the root SlimmGBPVR entry and didn't expand it. i was only looking for it to attach it with the logs...

man, i don't know what is wrong with me not spotting the database close entry. i guess i'm having an off day (with the reg thing too) and was just overwhelmed with the log text.

no worries on the multiple iterations. it is not affecting my system because i am keeping an eye on it and i have full confidence that a solution is on its way.

btw, i have also noticed tha the "config" compaction doesn't do quite as good of a job as the Access repair procedure...