NPVR 2.2.6 Recording Service Crash

[cncb]

You might need to go through the individual patches to see if you can narrow it down to a specific patch introduced. ie, apply the R1 collection, then selectively apply the later patches to see if you can identify when this problem started happening. This would give me some good clues on where to look.

I'll see if I can do this but it is a little difficult to do in the middle of prime recording season. What about '32. mark recordings completed before stopping graph'? This sounds like it could be related since it is locking up when trying to stop the graph.

[sub]

I'm pretty sure it's not related to #32. This is a fairly innocuous change. It just related to updating the status of a record in the database to 'completed' prior to calling stop on the graph, because some people had been having this problem with it hanging during the stop. Prior to this, the database update happened after stopping the graph, and if it had hung stopping the graph the recording would have been left in the 'recording' status. Also, this is writing a record to a database, and not in any way related to the actual act of stopping the recording.

You could try sticking with an earlier version of that file (NShared.dll) though, to see if helps.

[cncb]

Well, I went back to 2.2.6 without any patches and it has run several days without any lockups. I know it's not much help but it seems in my case one of the patches is causing the lockups. Sorry, at this point it's not very feasible to test one by one until I get a lock-up and missed recordings which may lead to bodily harm to me if a particular show is missed .

[johnsonx42]

I'm pretty sure it's not related to #32. This is a fairly innocuous change. It just related to updating the status of a record in the database to 'completed' prior to calling stop on the graph, because some people had been having this problem with it hanging during the stop. Prior to this, the database update happened after stopping the graph, and if it had hung stopping the graph the recording would have been left in the 'recording' status. Also, this is writing a record to a database, and not in any way related to the actual act of stopping the recording.

I've discovered an unfortunate downside to this change. Now when NPVR does crash during a graph-stop, there's no telltale sign of a stuck recording to alert someone that there's a problem. The only way to know now is to either look at the Pending list, which we don't do often, and see that later Pending recordings have not started, or simply notice that later expected recordings are missing (and in fact there is now no way to know there's a problem until AFTER future recordings are missed). The old way, a crashed recording stuck out like a sore thumb at the top of the What's New list (and in many cases I would discover the problem before any recordings were missed).

The only upside to this change is that the recording it crashed on is playable from Recordings.

I think a better solution would be to enhance the 'mark failed' logic when the recording service restarts such that it can determine that a recording that appeared to fail does in fact have a valid recording file associated with it, so it can therefore mark it 'Ready' instead of 'Failed'.

[BrettB]

I think a better solution would be to enhance the 'mark failed' logic when the recording service restarts such that it can determine that a recording that appeared to fail does in fact have a valid recording file associated with it, so it can therefore mark it 'Ready' instead of 'Failed'.

+1 -- When there is a non-0 byte .ts file there, the recording shouldn't be marked as failed and hence be unplayable (without extra work).

[Deev8]

I also installed the patch and set CollectEIT to false in config.xml two weeks ago. During that time the recording service hasn't crashed, and it had previously been crashing around once per week. Two weeks is probably long enough to suggest that it has improved the situation for me - thanks sub.

Just over four weeks after installing the appropriate patch and setting CollectEIT to false, I have had another recording service crash that had all the same characteristics as the one I reported in the first post in this thread.

Code:

2011-11-10 15:06:00.641    [INFO][7]    No more streams active. Stopping device.
2011-11-10 15:06:00.650    [DEBUG][7]    About to request async graph stop
2011-11-10 15:06:00.679    [DEBUG][14]    Graph stopping... (async)
2011-11-10 15:06:08.651    [DEBUG][7]    Async stop taking way too long

This was followed by the usual recording service cash some minutes later.

However prior to setting CollectEIT to false the recording service had been crashing approximately once per week, and after changing the setting I have had more than four crash-free weeks - so my experience suggests that the collection of EIT data may well have contributed to the problem, but it seems that it is not the whole problem.

[cncb]

Well, I went back to 2.2.6 without any patches and it has run several days without any lockups. I know it's not much help but it seems in my case one of the patches is causing the lockups.

I stand corrected: I just got a crash/lockup with 2.2.6 sans patches after several days. Maybe one of the patches accelerates the problem but I don't know. I hope this can be addressed soon.