Enhanced Web Admin

[drugstore_cowboy]

Hey Normanr... think I need a little more assistance but I am making progress both mentally and otherwise It appears that all is working with the Enhanced Web Admin Whoo Hoo !! (although sometimes it seems as there might be a network latency thing happening since it will sometimes err and display an asp error screen but a refresh takes care of that - is there anyway to contol how long it takes before it times out and spits out an error?)

Here is where my bad news comes in I (being the crazy guy that I am :eek: ) decided to also upgrade to version 24 and install the zaptools

The zaptools - well I am not seeing the extra info and my log says that it took 0 minutes to download so this can wait unless UncleJohnsBand has a quick solution I can try... otherwise this is a backburner issue for now.

I am unable to view the "Statistics" tab - exact same issue as AntiSpam. I have UNC paths listed in the config.xml file and I am sure that I can not get away with trying mapped drives since I have split the web plugin across my network. If I do try and use mapped drives only one box would successfully see the drives. Any ideas how I can get the Statistics tab to work? other than port forwarding the web service port? I have included my stacktrace below

Wait... can't you do something funky in Windows XP where you can mount a drive letter to a folder on you local machine??? maybe I can try mapped drives (Talk about stress testing a plugin !! I think that I may be creating a reciepe for disaster) Perhaps I will wait to hear your thoughts before I try this out.

[ManagementException: Not found ]
System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus errorCode) +167
System.Management.ManagementObject.Get() +296
gbweb.Info.GetDiskInformation(String nodeName, Label lblStatus, HtmlImage imgUsedSystem, HtmlImage imgUsedGBPVR, HtmlImage imgFree) in c:\program files\devnz\gbpvr\web\info.aspx.cs:80
gbweb.Info.Page_Load(Object sender, EventArgs e) in c:\program files\devnz\gbpvr\web\info.aspx.cs:46
System.Web.UI.Control.OnLoad(EventArgs e) +67
System.Web.UI.Control.LoadRecursive() +35
System.Web.UI.Page.ProcessRequestMain() +731

[UncleJohnsBand]

The zaptools - well I am not seeing the extra info and my log says that it took 0 minutes to download so this can wait unless UncleJohnsBand has a quick solution I can try... otherwise this is a backburner issue for now.

If you are seeing 0 minutes then you are not downloading anything...on a fast machine (I have a 3200+ processor with 1 gig of RAM) the whole process takes 1bout 1 minute...on average I think it is taking most people about 2-3 minutes for the whole process to run.

First.....make sure you are using the proper command line:

zapimport userid password

userid is the userid you use to log onto Zap2it as is the password...make sure these are correct.

To test it out open a command window in your gbpvr directory and execute the above command.

You should see the following output:

Using Path C:\Program Files\devnz\gbpvr\

Start downloading Zap EPG data...
Completed download of Zap EPG data...

Begining zapdb.mdb update process...

Removing GBPVR Recording Entries...
Loading GBPVR Recording Entries...
Removing Program Data without a corresponding GPBR Recording...
Removing Schedule Data without a corresponding GPBR Recording...
Removing Genre Data without a corresponding GPBR Recording...
Removing Crew Data without a corresponding GPBR Recording...

Opening zapdb.mdb for loading of new EPG data...

Loading downloaded Zap EPG XML data...
Total Loaded 8624

Loading zapdb.mdb with new Zap EPG data...

Loading up schedules...
root xtvd
children 6
Loading up channels...
Loading up programs...
Loading up crew...
Loading up generes...
Closing zapdb.mdb...

End zapdb.mdb update process...

Begin cleanup process...

Begin compact of zapdb.mdb...
End compact of zapdb.mdb...

End cleanup process...

Processing Statistics:

Download of Zap EPG data took 1 minutes
Complete zapdb.mdb update process completed in 0 minutes

Gee :o....now that I copied this log in I see the 0 minutes for process to complete....this has to do with the way the time was being calculated. I have now updated this to use a more standard method of time calculation. This ,however, should not have impacted your import process.

The zapdb.mdb file needs to be in the same directory you installed gbpvr to.

The size of the .mdb file should be over 3,000K....mine runs about 4,700K. If it is only a couple hundred K then the import is not working.

Download the new updated zaptools with the new time display and try the above command line in the gbpvr directory and let me know what happens.

The final statistics should read like the following:

Processing Statistics:

Download of Zap EPG data took 0 minutes and 41 seconds.
Complete zapdb.mdb update process completed in 1 minutes and 2 seconds.

[drugstore_cowboy]

Well with the old zaptools (cuz I had to see how long it would take) it took about a minute to download and the same can be said for the new version.

Here is my log file for the new version:
Using Path C:\Program Files\devnz\gbpvr\

Start downloading Zap EPG data...
Completed download of Zap EPG data...

Begining zapdb.mdb update process...

Removing GBPVR Recording Entries...
Loading GBPVR Recording Entries...
Removing Program Data without a corresponding GPBR Recording...
Removing Schedule Data without a corresponding GPBR Recording...
Removing Genre Data without a corresponding GPBR Recording...
Removing Crew Data without a corresponding GPBR Recording...

Opening zapdb.mdb for loading of new EPG data...

Loading downloaded Zap EPG XML data...
Total Loaded 6721

Loading zapdb.mdb with new Zap EPG data...

Loading up schedules...
root xtvd
children 6
Loading up channels...
Loading up programs...
Loading up crew...
Loading up generes...
Closing zapdb.mdb...

End zapdb.mdb update process...

Begin cleanup process...

Begin compact of zapdb.mdb...
End compact of zapdb.mdb...

End cleanup process...

Processing Statistics:

Download of Zap EPG data took 0 minutes and 47 seconds.
Complete zapdb.mdb update process completed in 0 minutes and 58 seconds.

Ahhh Database is now 3.16 MB in size... that is an improvement but now I am getting the following (bear in mind I don't want to restart anything as I am currently taping UFC):

The Microsoft Jet database engine cannot open the file '\\honey\gbpvr\zapdb.mdb'. It is already opened exclusively by another user, or you need permission to view its data

Shouldn't I be able to open the database from another computer? (Access says that it could not find the file even though I double clicked it from a mapped drive) I was able to open the file before when it was only 200 kb in size?? does this mean that it is locked by GBPVR? I only see one .ldb file and that one is for the GBPVR database?

[UncleJohnsBand]

Ahhh Database is now 3.16 MB in size... that is an improvement but now I am getting the following (bear in mind I don't want to restart anything as I am currently taping UFC):

The Microsoft Jet database engine cannot open the file '\\honey\gbpvr\zapdb.mdb'. It is already opened exclusively by another user, or you need permission to view its data

Shouldn't I be able to open the database from another computer? (Access says that it could not find the file even though I double clicked it from a mapped drive) I was able to open the file before when it was only 200 kb in size?? does this mean that it is locked by GBPVR? I only see one .ldb file and that one is for the GBPVR database?

Well...you have the extended data since your DB is now populated. If you are trying to access on a share you could have inadvertently locked it with access. I belive Xrecord also uses the database so perhaps that has it locked. I have not had any problems with locking of the DB. I don't use Xrecord so perhaps that is it.

Best bet would be to restart gbpvr after you are done recording to see if that releases it.

Your auto-update via the postupdateepg.bat should be working for you since you were able to run a-ok via a standard command line.

[normanr]

I am unable to view the "Statistics" tab - exact same issue as AntiSpam. I have UNC paths listed in the config.xml file and I am sure that I can not get away with trying mapped drives since I have split the web plugin across my network. If I do try and use mapped drives only one box would successfully see the drives. Any ideas how I can get the Statistics tab to work? other than port forwarding the web service port? I have included my stacktrace below

This was fixed in build 25 :p. I couldn't get it to work with mapped drives (it just refused to work, yuck). I didn't try with UNC paths, so that _might_ still be possible.

[normanr]

1. Currently, I can watch Live TV through the web interface by starting a recording of a currently showing programme, and then starting to watch it. There is one technical problem: VLC reads the duration of the file when I start watching. If I do nothing, it will stop playing once that point has been reached (even though the file has grown by then). I can trick VLC to update the duration by skipping in the file, but if I watch almost live, I have to do this every minute. I guess I should bring this up at the VLC forums. Does anyone here have any thoughts on this?

I might be able to fool VLC into not stopping (don't tell it how long the file is), but then you'd probably lose all seeking ability. Optionally I could tell it the file is 4gb long, and you lose fine grain control over where in the file you are. If there's a header or something I can add to let VLC know that the file will grow as it's downloading, let me know.

2. It would be very cool to be able to play the live TV buffer through the web interface. (Otherwise you are blocked from live TV if live TV is watched at the server or through an MVP.)

Yea, it would be cool, eh? If you want to watch the same as is currently being viewed, then it _has_ to be watched in timeshift mode, and not in preview mode. Maybe I can add a link on the statistics page for the recording source to watch what's currently playing.....

[jsteele]

normanr

I have a thread (http://forums.nextpvr.com/showthread.php?t=7251) reporting a problem with video "stuttering" caused by GBPVRRecordingServices.dll taking 100% of the CPU. Last night I found that this occurs only when the Web Server is running! If I stop the Web Server the problem goes away immediately.

[normanr]

The web server isn't doing anything in the background, and should only use the CPU when pages are loaded. Can you check the log files (under the statistics tab in build 24+, or go dig under windows\microsoft.net\framework).
The only thing that would cause cpu usage is page hits. Are you sure that no-one else on your network is using the web frontend (is it open to the internet?).

[jsteele]

I'll be the first to admit that correlation is not causation, but they are certainly related: if I stop the web server the CPU spiking in GBPVRRecordingServices simply goes away, if I start the web server the spiking returns. Access to the server is blocked at my router.

I can't imagine that simply accessing the web server would cause this kind of usage spike; it seizes the CPU >~ 100% for 1-2 seconds. And why accessing the web server would cause the spiking to occur in the GBPVRRecordingService to the degree that it overrides all other processes in the system.

I've just tried an experiment; with the system sitting idle at the main menu, logging in to .../gbpvr/login.aspx DOES result in a 100% CPU spike in GBPVRRecordingService.exe.
--------------------
Extract from the log file under the Stats tab :
---
RecordingFactory.loadSchedule() 8/12/2005 10:42:40 AM.368 VERBOSE [124] RecordingFactory.loadSchedule() 8/12/2005 10:48:46 AM.103 VERBOSE [124] RecordingFactory.loadSchedule() 8/12/2005 10:49:41 AM.790 VERBOSE [3170] RecordingFactory.loadSchedule() 8/12/2005 10:50:10 AM.071 VERBOSE [124] RecordingFactory.loadSchedule() 8/12/2005 10:52:07 AM.962 VERBOSE [124] RecordingFactory.loadSchedule() 8/12/2005 10:53:23 AM.415 VERBOSE [3170] RecordingFactory.loadSchedule() 8/12/2005 10:53:29 AM.399 VERBOSE [124] RecordingFactory.loadSchedule() 8/12/2005 10:53:43 AM.056 VERBOSE [124] RecordingFactory.loadSchedule()
----
I did the log in experiment at about 10:50 AM or so (+/- 2 minutes). As you can see there are no error indications of any kind.
---

It's very strange --- I'm waiting for the next general release of GBPVR to do a clean install and reinstall all my plugins to see if this problem goes away.

[normanr]

How odd. When does the spike occur - is it page load, or when you try and login? it might be the parsing of the log files, or it might be loading up the guide. Do certain pages hog the cpu for longer than others?

Would people be aversed to me adding a 1 millisecond delay time during the loading of the guide page? (this would cause it to load slower, but other apps should get more cpu)