Is the <ForcedGraphTeardown> parameter implemented in Npvr?

[tjb]

Sub,

Can you tell me if the <ForcedGraphTeardown> parameter is implemented in Npvr, and if so, in which section of config.xml should it be located.

[sub]

It always does this by default in NPVR. You'll see messages like this in your log when it tears the graph down:

2010-08-17 17:31:15.872 [DEBUG][1] Removing filter EVR Renderer
2010-08-17 17:31:15.873 [DEBUG][1] Removing filter NPVR PES Collector (Teletext)
2010-08-17 17:31:15.874 [DEBUG][1] Removing filter NPVR PES Collector (DVBSubs)
2010-08-17 17:31:15.874 [DEBUG][1] Removing filter Default DirectSound Device 0002
2010-08-17 17:31:15.875 [DEBUG][1] Removing filter Default DirectSound Device 0001
2010-08-17 17:31:15.875 [DEBUG][1] Removing filter Default DirectSound Device
2010-08-17 17:31:15.875 [DEBUG][1] Removing filter Microsoft DTV-DVD Video Decoder
2010-08-17 17:31:15.876 [DEBUG][1] Removing filter Microsoft DTV-DVD Audio Decoder
2010-08-17 17:31:15.876 [DEBUG][1] Removing filter MainConcept (HCW) Dolby Digital Audio Decoder
2010-08-17 17:31:15.878 [DEBUG][1] Removing filter MONOGRAM AAC Decoder
2010-08-17 17:31:15.879 [DEBUG][1] Removing filter MPEG-2 Demultiplexer
2010-08-17 17:31:15.879 [DEBUG][1] Removing filter NPVR TS Reader

[tjb]

Thanks, and sorry to keep bugging you. Still trying to figure out what's going on with the HDHR.

[sub]

It sounds to me like a reference counting problem.

We had a problem almost exactly the same as this for a short period with GBPVR and the HDHomeRun in the past. It sounds very similar. The silicon dust guys were adament it must be a GBPVR bug because it was only happening in GBPVR. To me it looked like it must be an HDHR bug because it wasnt occurring with any other manufacturer's device. They eventually spotted it was a reference counting problem in the HDHR drivers and fixed the problem. It wasnt immediately evident to them in other applications because most apps build a graph with the device and hold on to it for the entire duration the app is running. GBPVR and NPVR build a graph when it needs it, then releases the device when its no longer needed, and the second time the graph was needed was when we'd see the problem.

[tjb]

It sounds to me like a reference counting problem.

We had a problem almost exactly the same as this for a short period with GBPVR and the HDHomeRun in the past. It sounds very similar. The silicon dust guys were adament it must be a GBPVR bug because it was only happening in GBPVR. To me it looked like it must be an HDHR bug because it wasnt occurring with any other manufacturer's device. They eventually spotted it was a reference counting problem in the HDHR drivers and fixed the problem. It wasnt immediately evident to them in other applications because most apps build a graph with the device and hold on to it for the entire duration the app is running. GBPVR and NPVR build a graph when it needs it, then releases the device when its no longer needed, and the second time the graph was needed was when we'd see the problem.

Just trying to narrow things down and understand this a little better in case I need to log a problem on the SiliconDust web site. If indeed it is a problem with the HDHR similar to the reference count problem, would you expect any of the following?

1) When the system stops working on the second invocation of LiveTV, a restart of the Recording Service will allow LiveTV to work one more time.

2) Also when LiveTV fails, I can use the HDHR setup utility to view the stream from the same tuner.

3) Once an initial recording is started (and working), a second recording started on a different tuner causes a system crash.

[sub]

Just trying to narrow things down and understand this a little better in case I need to log a problem on the SiliconDust web site. If indeed it is a problem with the HDHR similar to the reference count problem, would you expect any of the following?

1) When the system stops working on the second invocation of LiveTV, a restart of the Recording Service will allow LiveTV to work one more time.

Yes, second use of device in the same process is failing. Restarting the recording service is effectively resetting things back to the starting point.

2) Also when LiveTV fails, I can use the HDHR setup utility to view the stream from the same tuner.

I'm pretty sure the HDHR setup utility doesnt use BDA drivers, which is where I'd expect the problem to be.

3) Once an initial recording is started (and working), a second recording started on a different tuner causes a system crash.

If it's crashing, its probably case of NRecord.exe not gracefully handling the situation of the device not working on second use.

[sub]

tjb, try this patch to see if it helps. Its not a long term fix, but I'm curious if it helps.

[tjb]

tjb, try this patch to see if it helps. Its not a long term fix, but I'm curious if it helps.

Good news and bad news. The patch seems to have completely fixed the LiveTV issues I was having , but when I try to record a second channel, the system still crashes.

[sub]

Good news and bad news. The patch seems to have completely fixed the LiveTV issues I was having , but when I try to record a second channel, the system still crashes.

Unfortunately it wasnt really long term patch. It just attempted to hold on to the device and never free it.

[tjb]

Well, at least I had just a few moments of glorious hope. Thanks, Sub.