I was running 2.4.23104 but I didn't have that dongle.bin in the dongle directory....however, putting the 2.4.23104 dongle.bin in there didn't help. I stepped back to the 2.4.23096 which is the latest shown as released on Haupauges website...here is what the log shows how....similar but appears slightly different syntax
Media stream thread caught exception: An established connection was aborted by the software in your host machine
6/7/2005 10:11:41 PM.968 ERROR [31] at System.Net.Sockets.Socket.Send(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
at System.Net.Sockets.Socket.Send(Byte[] buffer, Int32 size, SocketFlags socketFlags)
at q.ai()
6/7/2005 10:11:41 PM.968 VERBOSE [31] StopLiveTV()
6/7/2005 10:11:42 PM.202 VERBOSE [31] at ay.b(Boolean A_0)
6/7/2005 10:11:42 PM.202 VERBOSE [31] MVPHideOSD()
oh..sorry...i did as you suggested earlier and it didn't help.......
I notice that with live TV started, my CPU is at about 7%
I have a 2.8 Ghz P4, with 1 GIG Ram.
When I press the guide button the CPU shoots to between 55% and 75% utilization....so it is like GBPVR becomes resource starved and then can't pass the data on to the MVP.....i'm not sure how it could be starved at that utilization, but I guess it is possible.....my network utilization stays at about 5% the whole time.
just wanted to reply and let you know what I've found out by trial and error:
Note my config: i have two capture cards with about 350 total channels. My initial config was to have 14 days of information in the Guide.
I think what is going on is that GBPVR can't respond fast enough with the request for Guide information when the guide and thus the database has that much information in it. If I went to just one Capture card with 14 days of data, or two capture cards with 7 days of data, I don't get any errors.
If I have either of these last two configs with the fully transparent OSD I do get the error.
So, I guess in essence, GBPVR is getting resource starved, or it just can't bring in the data for the OSD guide fast enough if the database is too big.
I'm going to attempt to move the database to MSDE tomorrow and I'll let you know if and when I get MSDE working if this fixes the problem. If it does, then it appears to be an issue with getting the data out of the database fast enough before the built in timer on the MVP times out and basically does a quick reboot of the device.
[ If it does, then it appears to be an issue with getting the data out of the database fast enough before the built in timer on the MVP times out and basically does a quick reboot of the device.[/QUOTE]
It seems that my system goes to contacting servers quite often and from what I have been reading, it looks like some kind of network speed or time out issue. I there a way to lengthen the "built in timer" so the MVP waits for data movement so I can minimize this?
MSDE did indeed fix the problem. However, I was having other issues with MSDE running correctly as the database, and I shelved that for now. But the response time was far better.
Because of the issues I was having with MSDE and thus have gone back to the access db, i decided to try the JETCOMP utility to help compact the gbpvr database down.
If I do this my database went from 166meg down to 22meg with 14 days of data with 2 capture cards. I could get the on screen guide to come up if I did NOT have the transparent OSD selected in the config util. As soon as I engaged it, it didn't work anymore
If I do this my database went from 92meg down to 14meg with 7 days of data with 2 capture cards. I could get the on scree guide to come up if I DID have the transparent OSD selected in the config util.
I guess I'm going to go with 7 days of data with 2 capture cards and run the JETCOMP nightly.
Same problem here.
1) How did you config the EPG to reduce from 14 days of data to 7 days of data ?
2) What is JETCOMP ? and how do you run the JETCOMP nightly ?