v.99.5 kudos and GBPVRRecordingService crash

[Braklet]

Hey sub, first off I'd like to vociferously thank you for v99.5. The major improvement for me personally is ability to edit post-padding for current recordings. This is a huge benefit during sporting events that run over EPG times. There are a few other additions that seem to make a big difference in my regular usage (Overlay mode aspect ratio, Recordings skin change). Many thanks!

The RecordingService crashes I've seen are unrelated to v.99; they've occurred since I started using GB-PVR v.96, but they are starting to really impact my timeshifts.

I am nearly positive that my crashes are due to recording a borderline ATSC channel that drops out. This screws up all current recordings on different tuners as well as future recordings until I manually restart the RecordingService.

I don't expect GB-PVR to fix a nonexistant data stream but I hope the RecordingService could fail a bit more gracefully by terminating the recording from the questionable channel, while preserving simultaneous stable recordings and future timed events.

The attached logs reveal one such RecordingService crash. The unstable recording starts on 14 Jan 2007 @ 19:00:00 (Kung Fu, channel label 47.1); see GBPVRRecordingService.exe-native-1.log. The signal stats are never better than (1,0,75,75) and jump around quite a bit.

We noticed a Windows Dr. Watson alert at approximately 19:42 which coincides with the end of the <>-native-1.log and a signal dropoff. I restarted the RecordingService approximately 19:45 which is indicated in GBPVRRecordingService.exe-native.log, and I manually terminate the questionable Kung Fu recording about 19:46:48.

Is this information enough to go on? Thanks for any help you can provide.

[Braklet]

Now that Sub is back I'm bumping this thread... pardon the interruption.

[sub]

You're probably right that it is signal related. I see it seems to take a major signal strength drop as the very last message in the logs:

19:40:35.702 VERBOSE checking signal stats took total: 0ms (1,0,75,75).....(,0,0,0)
19:41:05.796 VERBOSE checking signal stats took total: 47ms (1,0,25,25).....(,0,0,0)

It does try to handle these situations gracefully, but its often hard for me to guess what garbage data received may cause what logic to run then fail, so its hard to know where the problem is exactly.

When this happens, does a file get created in c:\windows\minidump?

[Braklet]

hard for me to guess what garbage data received may cause what logic to run then fail

I reckoned this was probably an error buried in some Windoze library, but thought that signal loss is a common enough event that maybe we could track some sort of guard logic around it.

When this happens, does a file get created in c:\windows\minidump?

I don't have a directory or file of that name, however I just checked the event logs and found these generated about the same time as that particular crash:

[Application]

Event Type: Error
Event Source: .NET Runtime 2.0 Error Reporting
Event Category: None
Event ID: 1000
Date: 1/14/2007
Time: 7:41:14 PM
User: N/A
Computer: RLR-HTPC
Description:
Faulting application gbpvrrecordingservice.exe, version 1.0.2547.27412, stamp 00000013, faulting module psiparser.ax, version 0.1.0.0, stamp 457783ae, debug? 0, fault address 0x0000bc44.

Event Type: Error
Event Source: GB-PVR Recording Service
Event Category: None
Event ID: 0
Date: 1/14/2007
Time: 7:44:04 PM
User: N/A
Computer: RLR-HTPC
Description:
Service cannot be started. System.Net.Sockets.SocketException: Only one usage of each socket address (protocol/network address/port) is normally permitted
at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress)
at System.Net.Sockets.Socket.Bind(EndPoint localEP)
at System.Net.Sockets.TcpListener.Start(Int32 backlog)
at System.Net.Sockets.TcpListener.Start()
at System.Runtime.Remoting.Channels.ExclusiveTcpListener.Start(Boolean exclusiveAddressUse)
at System.Runtime.Remoting.Channels.Tcp.TcpServerChannel.StartListening(Object data)
at System.Runtime.Remoting.Channels.Tcp.TcpServerChannel.SetupChannel()
at System.Runtime.Remoting.Channels.Tcp.TcpServerChannel..ctor(Int32 port)
at GBPVR.RecordingService.x116139cea0d00aa9.OnStart(String[] args)
at System.ServiceProcess.ServiceBase.ServiceQueuedMainCallback(Object state)

Event Type: Error
Event Source: Application Hang
Event Category: (101)
Event ID: 1002
Date: 1/14/2007
Time: 7:44:24 PM
User: N/A
Computer: RLR-HTPC
Description:
Hanging application GBPVR.exe, version 1.0.2547.35214, hang module hungapp, version 0.0.0.0, hang address 0x00000000.

Event Type: Error
Event Source: Application Hang
Event Category: (101)
Event ID: 1002
Date: 1/14/2007
Time: 7:44:41 PM
User: N/A
Computer: RLR-HTPC
Description:
Hanging application GBPVRTray.exe, version 1.0.2547.27413, hang module hungapp, version 0.0.0.0, hang address 0x00000000.

[System]

Event Type: Error
Event Source: Service Control Manager
Event Category: None
Event ID: 7034
Date: 1/14/2007
Time: 7:41:32 PM
User: N/A
Computer: RLR-HTPC
Description:
The GB-PVR Recording Service service terminated unexpectedly. It has done this 1 time(s).


Subsequent to these events, I am able to manually start the RecordingService and GB-PVR appears to function normally (restarts the recordings in progress).

Please let me know if there's anything else I can extract out of this system. The crash has happened often enough that I am reasonably confident I can induce it by recording the borderline channel.

Thanks again for taking a look.

[sub]

I reckoned this was probably an error buried in some Windoze library, but thought that signal loss is a common enough event that maybe we could track some sort of guard logic around it.

What I was trying to imply above, is that I actually have done this, but I'm obviously missing something. Most likely something ATSC related, or I would have likely seen it myself.

[Braklet]

What I was trying to imply above, is that I actually have done this, but I'm obviously missing something. Most likely something ATSC related, or I would have likely seen it myself.

Yeah, could well be some driver goofiness. If you'd like a closer look at my system, let me know. I can avoid recording the known borderline channel, though I have caught the crash on usually-good channels when the weather is unforgiving.

[sub]

The Dr Watson error messages doesnt indicate the name of a dump file? Sometimes they're not created in c:\windows\minidump.

[Braklet]

The Dr Watson error messages doesnt indicate the name of a dump file? Sometimes they're not created in c:\windows\minidump.

I'll have to induce it again to see. I went poking around on the HTPC and found a drwtsn32 report buried in All Users Documents and Settings. Unfortunately it was from an earlier, unrelated crash.

I did find evidence of a DMP file created at the time of that crash (in c:\windows\temp) but it is zero length.

I'm in the habit of cancelling or hitting the big red X on all Windows alerts.

I'll try to save the dump on the next RecordingService crash. Is there anything in particular I can do that might help narrow down the cause?

Thanks again.

[sub]

Is there anything in particular I can do that might help narrow down the cause?

About the only think I can thing of is recording a few large transport stream files of the problem channel, and burning them on a DVD then mailing them to me. With that I should be able to simulate the problem here.

[Braklet]

About the only think I can thing of is recording a few large transport stream files of the problem channel, and burning them on a DVD then mailing them to me. With that I should be able to simulate the problem here.

Oh, you think it has something to do with the actual data stream? I figured it was just a poorly behaved driver pulling the rug out from the RecordingService.

I played with Transport Stream back in the past, and can probably muster something up if I try some dedicated bug reproduction. Only problem might be disk space; TS files are HUGE and that Kung Fu recording took 45 minutes to crash.

I assume that all I need to do is set the BDA MUX to Transport Stream? Normally I use Microsoft DVR-MS.

I'll try to get toasted MPEG2, event logs and a Dr. Watson dump.