Deadlock in backend on starting a new recording

[danielk]

I'm setting this as a blocker for now. If it turns out to be rare I will reduce the priority. But I want to investigate this to at least determine if it is a recent regression.

[danielk]

Very little of value is in the backend log:

2010-09-21 11:59:00.209 TVRec(56): ASK_RECORDING 56 29 0 0
2010-09-21 11:59:12.880 Maximal bitrate of busy encoders is 0 KB/min
2010-09-21 11:59:27.910 Cardid 56: max bitrate 162597 KB/min
2010-09-21 11:59:27.912 Maximal bitrate of busy encoders is 162597 KB/min
2010-09-21 11:59:31.398 RecordingInfo(2101_20100921120000.mpg): StartedRecording: Recording to '/video/2101_20100921120000.mpg'
2010-09-21 11:59:31.459 TVRec(56): Changing from None to RecordingOnly
2010-09-21 11:59:31.464 TVRec(56): HW Tuner: 56->56
2010-09-21 11:59:34.857 AutoExpire: Adding Programs to 'Do Not Expire' List
2010-09-21 11:59:34.859     2111 at 2010-09-21T03:00:00 in use by recorder on living.kristjansson.com
2010-09-21 11:59:34.859     2101 at 2010-09-21T12:00:00 in use by recorder on living.kristjansson.com

[danielk]

It looks like m_SMpending is set and StartRecording() will consequently block forever waiting for the signal quality to improve. This needs to be fixed, we can't have a poor signal on one recorder prevent all other recorders and the fronteds from working.. When StartRecording() blocks it prevents the scheduler from running and prevents all backend calls that require a scheduler lock from completing...

[jpoet]

Fixed by [26440]