GBPVR loses ability to send IR Channel Changes?

[jksmurf]

The last few weeks I've missed a few shows because the IR (USB-UIRT) didn't seem to manage to change the channel (internal tuner changes work). In the same way, even on the PC the up arrow did not change the channel on my DSL box, except when I restarted GBPVR, then it was OK again. Is this down to a "loss of focus"?

My PC is fairly low spec, but used to work Ok, prior to a recent Xp/GVPVR new install. Would ForceHighPriority for the RecordingService help this? I am fairly sure I previously enabled this, from my old config. I only really need the priority during the channel change if that helps?
The show was this on channel 541 at 6~8pm last night, but the DSL box didn't change from Ch 685?

Code:

2007-04-20 17:59:03.785 INFO Log started
2007-04-20 17:59:03.785 VERBOSE ConexantRecorder::StartRecording(1, 852, 541, 0)
2007-04-20 17:59:03.795 VERBOSE target filename: E:\GBPVRVids\Super 14s\Super 14s_20070420_18002000.mpg

If not, any other suggestions?
Seems some errors initialising the Tray Icon Plugin, but they are unrelated I guess.

Code:

2007-04-20 08:07:28.785 ERROR [1] Error initializing event plugin: C:\Program Files\devnz\gbpvr\plugins\MVP Tray Icon.dll
2007-04-20 08:07:28.785 ERROR [1] Exception has been thrown by the target of an invocation.
2007-04-20 08:07:28.966 ERROR [1]    at System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean publicOnly, Boolean noCheck, Boolean& canBeCached, RuntimeMethodHandle& ctor, Boolean& bNeedSecurityCheck)
   at System.RuntimeType.CreateInstanceSlow(Boolean publicOnly, Boolean fillCache)
   at System.RuntimeType.CreateInstanceImpl(Boolean publicOnly, Boolean skipVisibilityChecks, Boolean fillCache)
   at System.Activator.CreateInstance(Type type, Boolean nonPublic)
   at GBPVR.Backend.Common.xc4f12ec3a8a4c96b.xb77fa95273e0c228(Boolean x8bae2a88590d8cc0)

There's lots of these in the MVP-gbpvr.exe.log, but they are unrelated too I guess.

Code:

2007-04-20 08:43:13.805 WARNING [12] Received unknown request of type: 0
2007-04-20 08:43:13.805 WARNING [12] Received unknown request of type: 23
2007-04-20 08:43:13.805 WARNING [12] Received unknown request of type: 167
2007-04-20 08:43:13.805 WARNING [12] Received unknown request of type: 218
2007-04-20 08:43:13.805 WARNING [12] Received unknown request of type: 52
2007-04-20 08:43:13.805 WARNING [12] Received unknown request of type: 0
.
.
2007-04-20 08:43:43.938 WARNING [12] Received unknown request of type: 0
2007-04-20 08:43:43.938 WARNING [12] Received unknown request of type: 25
2007-04-20 08:43:43.938 WARNING [12] Received unknown request of type: 6
2007-04-20 08:43:43.938 WARNING [12] Received unknown request of type: 205
2007-04-20 08:43:43.938 WARNING [12] Received unknown request of type: 244
2007-04-20 08:43:42.947 WARNING [14] Unexpected error updating PLAYBACK_POSITION: System.Data.SQLite.SQLiteException: The database file is locked
database is locked

k.

[jksmurf]

sub, any ideas on this one?

k.

[sub]

sub, any ideas on this one?

No not really - though you didnt include the GBPVRRecordingService.exe.log in the zip, which is probably the most likely log to have something.

[jksmurf]

No not really - though you didnt include the GBPVRRecordingService.exe.log in the zip, which is probably the most likely log to have something.

Arrghhh. Zip doesn't zip it if it is growing... I forgot to shut down RecServ before taking logs, so it's gone now I guess. I'll try with ForcePriority for a while and see if it helps, or try and capture the fault if it doesn't.

Ta

k.

[jksmurf]

OK sub, here are the logs, this time WITH GBPVRRecordingService.exe.log

Not much in that log.

As before, channel change with arrow keys does not change the channel (no lights on the USB-UIRT flash on either?) BUT the icon for the channel and the OSD channel name for the channel it SHOULD have changed to briefly flash on the screen.

A GBPVR restart (using Start Progs, GBPVR, config, OK) allows the default behaviour of very easy channel changes. (it seems to run more smoothly on a restart too?). I use the Nvidia PureVideoCodec which turns on and runs with LiveTV and it seems to take a while to start that, and hogs CPU a bit, do you think that is interfering?

Starts at 5:18pm approx until I closed it off at 5:20ish. Sorry about all the garbage before it, but the issue doesn't happen with a "clean" restart, so I can't give you clean set of logs.

HTH you diagnose it :o

k.

[jksmurf]

sub?

k.

[sub]

I'm not really sure. I can see the channel change attempts during that time, but there is no sign of any errors:

2007-04-28 05:19:31.499 VERBOSE [1] Switching to channel: 3 (ESPN)
2007-04-28 05:19:31.499 VERBOSE [1] Changing channels with USB-UIRT
2007-04-28 05:19:31.499 VERBOSE [1] Sending: 6
2007-04-28 05:19:31.770 VERBOSE [1] Sending: 8
2007-04-28 05:19:32.111 VERBOSE [1] Sending: 4

[jksmurf]

I'm not really sure. I can see the channel change attempts during that time, but there is no sign of any errors:

MMM...thought that might be the case. Nothing in event viewer either. Is there a log or something which would tell me if the USB-UIRT is getting the attempts to change. Any idea why a restart would make it work perfectly?

k.

[sub]

Is there a log or something which would tell me if the USB-UIRT is getting the attempts to change.

I'm not aware of any.

Any idea why a restart would make it work perfectly?

no.

[JonnyCam]

Is this something which only happens on 2nd and subsequent recordings after a restart?

I have the same kind of issue where the USBUIRT will not work with live TV after I have had a recording complete.
I thought it may have been to linked to GBPVR holding onto the UIRT after first use to allow for speedier changes in the future, and there is something in the config.xml for "recycleUSBUIRT" (SUb confirmed that it keeps hold of the UIRT) to stop this - but I still don't think this solved my live TV problem.

Also, Live TV after recordings takes ages to start, no UBSUIRT response, and very stuttery when it finally loads

Thanks