Enhanced Web Admin

[cubsfan]

same as post #407, which I replied to in post #410.

Hmmm, having the number of days that you have guide data for would be very useful, someone want to code that up and send me the patch?

I have attached a VBScript that will do the check, sorry I'm not real familiar with C# and I don't have an editor loaded for it. If all else fails and no one wants to convert this vbscript into C# then you could always just use it as a custom task.

[UncleJohnsBand]

I have attached a VBScript that will do the check, sorry I'm not real familiar with C# and I don't have an editor loaded for it. If all else fails and no one wants to convert this vbscript into C# then you could always just use it as a custom task.

I also sent normanr an update to the Statistics page that will display the number of availble days.

The only thing that I noticed is that for some reason you can have an old date hangging out in the DB that can skew the results...compacting the GBPVR database gets rid of the old dates.

I am not sure if GBPVR automatically compacts the db periodically or not....mine always seems to grow to 40-50mb and then I force a compcat via Access.

[cubsfan]

I also sent normanr an update to the Statistics page that will display the number of availble days.

The only thing that I noticed is that for some reason you can have an old date hangging out in the DB that can skew the results...compacting the GBPVR database gets rid of the old dates.

I am not sure if GBPVR automatically compacts the db periodically or not....mine always seems to grow to 40-50mb and then I force a compcat via Access.

An old date shouldn't skew the results...well I guess not the way I did it. I took the date furthest into the future that is in the database and then did a date difference with that date and today's date which will always give you the amount of days left in the guide.

[UncleJohnsBand]

An old date shouldn't skew the results...well I guess not the way I did it. I took the date furthest into the future that is in the database and then did a date difference with that date and today's date which will always give you the amount of days left in the guide.

I took the request to mean "How many days are there in the EPG" rather than how many days left in the EPG. To calculate the answere I used the DateDiff between the oldest and newest dates in the Programme table.

Your calculation is valid one as well providing a different view of available EPG data. I will add this calculation as another display field on the Statistics page.

You will then know how many days are loaded and how many days are left in the EPG from today.

Teamwork!

[UncleJohnsBand]

An old date shouldn't skew the results...well I guess not the way I did it. I took the date furthest into the future that is in the database and then did a date difference with that date and today's date which will always give you the amount of days left in the guide.

I took the request to mean "How many days are there in the EPG" rather than how many days left in the EPG. To calculate the answere I used the DateDiff between the oldest and newest dates in the Programme table.

Your calculation is valid one as well providing a different view of available EPG data. I will add this calculation as another display field on the Statistics page.

You will then know how many days are loaded and how many days are left in the EPG from today.

Teamwork!

cubsfan...I liked your calculation better...there was only a days difference between the two numbers. Since your calculation remvoes the old date issue I have updated what I sent to normanr to use that calc in the display on the Statistics page.

[cubsfan]

[/i]


cubsfan...I liked your calculation better...there was only a days difference between the two numbers. Since your calculation remvoes the old date issue I have updated what I sent to normanr to use that calc in the display on the Statistics page.

Cool. In all reality I think the calculation you ended up using will be a better indicator for the user to determine if their EPG update is working correctly or not. The calculation that was used should always display the same number as the number of days you have set in the config for retrieving EPG data. Did you end up using the exact calculation I did in my code, where I format them as vbShortDates and then add 1 to the difference so it takes into consideration the guide data for the current date?

[UncleJohnsBand]

Cool. In all reality I think the calculation you ended up using will be a better indicator for the user to determine if their EPG update is working correctly or not. The calculation that was used should always display the same number as the number of days you have set in the config for retrieving EPG data. Did you end up using the exact calculation I did in my code, where I format them as vbShortDates and then add 1 to the difference so it takes into consideration the guide data for the current date?

I used System.DateTime objects to hold the max date and today's date and then created a small routine to calculate the difference between the dates. The routine is setup to calculate many differences ranging from total seconds to months and what we are using days.

My calculation will work but until I know how old dates can get stuc in the DB I think it could cause confusion to users. For example.....before I manualy compacted my gbpvr.mdb file there was an entry in the Prograsmme table for like 6/2/05. So when my calc ran I got like 130+ days......which is a correct date span but incorrect as to what is really available in the EPG.

Perhaps sub can answer the question as to why these old dates can get stuck out there and if the gbpvr.mdb file is to be autocompavcted at any time.....mine never does....I always have to manually do it.

[sub]

Perhaps sub can answer the question as to why these old dates can get stuck out there

If you have recordings that refer to a Programme, then these Programmes are left in the database, until the recording is deleted.

and if the gbpvr.mdb file is to be autocompavcted at any time

You can only compact the database when nothing holds a lock on it. As such, the only time GB-PVR compacts the database is when you click the OK button in the config app, at which time it stops and restarts the recording service - forcing it to drop its connections.

[UncleJohnsBand]

If you have recordings that refer to a Programme, then these Programmes are left in the database, until the recording is deleted.

There were no old recordings in the DB connected to the old entries.

You can only compact the database when nothing holds a lock on it. As such, the only time GB-PVR compacts the database is when you click the OK button in the config app, at which time it stops and restarts the recording service - forcing it to drop its connections.

Are you saying that when you click the ok button in the config that the DB should always compact?

If so, It is not working.....I have never seen my database ever get automatically comacted....I manually do it when it gets to like 40mb in size....which is about every other week.

[sub]

Are you saying that when you click the ok button in the config that the DB should always compact?

If so, It is not working.....I have never seen my database ever get automatically comacted....I manually do it when it gets to like 40mb in size....which is about every other week.

The compaction will only work if there are no other processes holding connections to the database. Lots of things could stop this happening, some examples include - any utilities running which have a connection to the database, the replacement tray app, GBPVR.exe is running, running the GBPVR web stuff via IIS etc.