NPVR 2.2.6 Recording Service Crash

[sub]

It added the ability to disable parsing of the EIT information in the stream. Previously it was always done, regardless of whether you were using a broadcast EPG or not. With <CollectEIT> set to false it'll throw away EPG info and never look at it.

[johnsonx42]

so basically anyone not using the Broadcast EPG can safely set this to false, and eliminate a potential source of crashes?

[sub]

Yes, potentially. Waiting for more feedback to decide whether its helping.

[buribu]

Hello sub,

I have installed the patch and changed the config.xml yesterday and since then no more crashes.

But, am I correct, that now I don't get any DVB-EPG information anymore?

If we now think that the problem is triggered by the EPG-Information, is there a chance to find a way for solving the problem? If I can help or test something for you please let me know.

[sub]

With that setting in your config.xml you will not receive any DVB EPG.

I'll keep an eye on feedback from this, and if others find it also fixes the issue for them, then I'll take closer look at the EPG processings to see if I can work out why this is causing problem for some people so I can fix it and it can be reenabled.

[johnsonx42]

perhaps people having problems with this should create C:\TEMP directory and then set HKEY_LOCAL_MACHINE\Software\NPVR\LogEIT=1 (DWORD)?

Then they can send you the resulting EIT.log files and you can find out what data is killing it?

[sub]

perhaps people having problems with this should create C:\TEMP directory and then set HKEY_LOCAL_MACHINE\Software\NPVR\LogEIT=1 (DWORD)?

Then they can send you the resulting EIT.log files and you can find out what data is killing it?

Unfortunately it's not killing it and causing a nice identifiable moment in time when the event happened. Instead, it seems more like something unexpected is being parsed in the stream, leading to some data or program code being trampled, which causes an issue much later when the graph stops. The makes it difficult to identify what earlier data caused the problem.

[johnsonx42]

got it.

[buribu]

Hello sbub,

I have good news and bad news

The good news is, that now after 2 days there is no more "Async stop taking way too long" and no crashes of nrecord.exe.

The bad news is, that now the nrecord.exe seems to hang after "2011-10-10 02:05:25.472 [DEBUG][8] Graph stopping...". And because there is no more crash of the nrecord.exe, the system doesn't restart this process (this was my workaround after a crash), and so the process is still hanging at the next recording which results in:
"2011-10-10 07:46:00.714 [DEBUG][7] Starting graph...
2011-10-10 07:46:00.724 [DEBUG][7] Failed to start device: 0x8007001f"
at the next recording.

I attach the logfiles, probably you see something that went wrong.


For now, I will install the new Patch R2 and search for a reliable workaround, hoping that you will find the cause of my problems soon.

[sub]

The good news is, that now after 2 days there is no more "Async stop taking way too long" and no crashes of nrecord.exe.

The bad news is, that now the nrecord.exe seems to hang after "2011-10-10 02:05:25.472 [DEBUG][8] Graph stopping...".

I suspect you've still got the original problem. The version of unmanaged.dll that was included in that zip file had this 'Async stop taking way too long' message disabled. This version re-enables that logging.