1 tuner stuck recording, nothing else recorded all day

[GlowTube]

What firmware version are you running? I used to have that issue, but Silicion Dust fixed that a release or two ago.

I am using the April 15th version (complete download). I've read that some folks have seen different behavior by mixing and matching Silicon Dust's "software" and "firmware" between their releases, but I have not done this.

There's also a July beta that is available for testing.

To me this still seems like a GBPVR problem, though. Even if the HDHomerun is giving incorrect status or no status, the recording service seems locked into recording a show long after its scheduled duration has passed.

One other anecdotal item: When my system is in the errored state, GBPVR's interactive response is waaaay slower than normal. By this I mean that the tray icon's response to a right-click is very slow, and if I then choose something like Display Status, the resulting window painting is similarly slowed. I don't think this was mentioned on the thread before. I'll have a look at the CPU usage and process list next time to see there's a clue there.

I will check my recording service native log the next time this happens, and see the sequence of completion messages.

[johnsonx42]

One other anecdotal item: When my system is in the errored state, GBPVR's interactive response is waaaay slower than normal. By this I mean that the tray icon's response to a right-click is very slow, and if I then choose something like Display Status, the resulting window painting is similarly slowed.

Yes, this is a side effect of the recording service being unresponsive. You can duplicate this by stopping the gb-pvr recording service in Services - the tray app will behave the same way.

[GlowTube]

I've upgraded to the latest release from SiliconDust (August 6), but unfortunately this bug bit me again a few nights ago -- I discovered at 11:30 PM that the Recording Service was stuck on a show that ran from 6:30 to 7 PM, so about eight recordings failed in the interim. Green icon in the tray, no active tuners on the HDHomerun. In the GB-PVR status display, one tuner shown as sleeping, one tuner still recording the show four hours in the past. Also, the associated sluggishness to bring up the status window, as mentioned above.

I restarted the Recording Service, and things appeared normal after that. The logs didn't show anything unusual for this event. I did not see the incomplete sequence of termination messages mentioned before. No error messages stood out.

On the forum there's a range of opinions on this issue, from "It doesn't happen to me," to "I'm intentionally using old versions of HDHomerun code," to "I'm thinking of restarting the Recording Service once a day." Sub, is this one on your radar?

[sub]

On the forum there's a range of opinions on this issue, from "It doesn't happen to me," to "I'm intentionally using old versions of HDHomerun code," to "I'm thinking of restarting the Recording Service once a day." Sub, is this one on your radar?

To be honest, no. I havnt seen widespread reports of problems like this, and dont really have ideas based on the description I've seen.

There was a known reference-counting bug with the HDHR drivers around the time this was first reported, which caused a flourish of reports of recording and live tv problems, but this was later fixed by them so I wouldnt expect that to be the cause any longer. Prior to that, some users were going back to old versions of the HDHR drivers. Since they put the fix out I hadnt seen any other comments about it.

I'm hoping the 1.4.x release will be out next week. If its still occuring with the new version, I'll get someone to capture a dump (from context menu of Vista/Win7 task manager), and look into what the process is doing.

[johnsonx42]

Glowtube is the only one reporting this issue who is using an HDHR... the rest of us in this thread and the other one linked in post #7 are using other tuners.

Glowtube, it might be useful to post your recordingservice and recordingservice-native logs, just to see if they look like my and Carlito's logs.

[sub]

Glowtube is the only one reporting this issue who is using an HDHR... the rest of us in this thread and the other one linked in post #7 are using other tuners.

Yes, I know - but he explicitly mentioned reading another thread about people going back to an old version of HDHR software, and I remembered that thread with a similar sounding problem, but was specifically HDHR related.

As I mentioned above though, if its still happening with 1.4.x, then I'll look into it. My code is no longer compatible with 1.3.x, so I couldnt provide patches to correct additional logging etc at this stage.

[Carlito]

Gah, this happened to me again. Just got back last night after a weeks vacation to a stuck recording service. It failed on the 17th so I missed a good week of recordings.

Really wish I could figure this out. I'm getting heck from the wife...

[johnsonx42]

per sub's comment, let's see what happens with 1.4 (last I read, due any day now)... even if he wanted to he couldn't help us any more with 1.3.

[johnsonx42]

I continue to have this problem with 1.4.7, just occurred again today. The recording service just stopped doing anything after recording the kids' Zula Patrol early in the morning of 10-19. We watched live TV several times during the day, it was still functional for that purpose, but finally noticed around 6:40pm it still said it was recording Zula Patrol.
As in previous occurances of this issue, the native log just ends while trying to stop the recording, and nothing else is ever attempted:

Code:

2009-10-19 03:00:25.226    VERBOSE    BDARecorder::StopRecording()
2009-10-19 03:00:25.226    VERBOSE    StopRecording()@1

In this particular case, it does appear that something was wrong with the recording, and the recording service attempted to end the recording after only 20 seconds:

Code:

2009-10-19 03:00:00.054    VERBOSE    [5]    BDARecordingSource about to start recording  oid:2 channel:T:41,0,0~P:3~TSID:309~V:65~A:68~PMT:64~PCR:65~N:>58.2  KLCS-DT (000(AC3)) file:F:\Recordings\Zula Patrol\Zula Patrol_20091019_03000330.mpg
2009-10-19 03:00:04.382    VERBOSE    [5]    getValue cached value: /settings/BDASubmitTuningRequestTwiceOnRecord : true
2009-10-19 03:00:04.398    VERBOSE    [5]    start recording @3
2009-10-19 03:00:04.398    VERBOSE    [5]    start recording @4
2009-10-19 03:00:04.398    VERBOSE    [5]    Programme is now recording
.......
2009-10-19 03:00:25.226    INFO    [5]    Recording is unusually small. Giving second chance: F:\Recordings\Zula Patrol\Zula Patrol_20091019_03000330.dvr-ms  (5602)
2009-10-19 03:00:25.226    VERBOSE    [5]    Stopping recording
2009-10-19 03:00:25.226    VERBOSE    [5]    Stopping recording oid:2

This has not generally been the case with this problem though, in most cases the program records fine, but the native log just trails off the same way attempting to end the recording.
It looks like the recording service was going to stop the recording and then attempt to start it again (I presume that is what was meant by "Giving second chance").
It looks like something in the native utilities is dying trying to stop a recording, and no mechanism is available to recover from it.

[sub]

Reproduce the problem, then from the Windows task manager right click the GBPVRRecordingService.exe process and choose the dump option, then place the dump file somewhere I can download it, and I'll take a look.