SEGV when TOGGLERECORD from live on a slave encoder

[bjm]

To reproduce, in an environment with a master and at least one slave backend, enter live TV from a frontend on any host. Press "Y" to change cards until a card on a slave host has been selected. Press "R" to transition from live to recording in progress. Playback stops as the slave backend will have a segmentation fault.

A backtrace is attached but probably unnecessary. AddRecording() is being called on the slave which doesn't have a scheduler or a reclist. This should only be callled remotely at the master.

[bjm]

Seg fault when AddRecording() is called on a slave host.

[danielk]

I will fix this Monday.

[danielk]

(In [8694]) References #1089. Possible fix.

This at the very least gets rid of the segfault...

It should also fix the problem, but I don't have slave backend set up at the moment to test...

[bjm]

I can confirm that the slave backend does not seg fault but it does not succeed and leave the slave in an unresponsive state.

Slave log:

2006-01-23 14:07:31.168 TVRec(1): SetLiveRecording(0)
2006-01-23 14:07:31.175 TVRec(1): SetLiveRecording() -- record
QMutex::unlock: unlock from different thread than locker
                was locked by -1248348448, unlock attempt from -1317430352

Master log:

2006-01-23 14:07:31.723 ProgramInfo::FromStringList, not enough items in list.

2006-01-23 14:07:31.723 Bad SCHEDULER_ADD_RECORDING message

[anonymous]

Thanks Bruce, I'll have to create a slave backend to fix this then. I'll do it tomorrow (Tuesday).

[danielk]

(In [8704]) Fixes #1089.

The problem was with dispatchNow() which breaks when the scheduler is not local. I had to move some things to Scheduler::AddRecording() to be able to use dispatch() instead, but this should work about the same.

[bjm]

How had you tested this before closing the ticket? For me, all attempts still fail on "Bad SCHEDULER_ADD_RECORDING message". It appears that the stringlist of proginfo is not being passed successfully through the MythEvent. If I add some simple debugging, it appears that there is a valid list created by ToStringList((), however, only a one item list with just the title is received from me->ExtraDataList() at the master.

Slave log when "R" is pressed:

2006-01-24 13:33:35.243 TVRec(2): SetLiveRecording(1)
2006-01-24 13:33:35.248 TVRec(2): SetLiveRecording() -- record
Prog[0]: The Cosby Show
Prog[1]: Getting to Know You

Master log:

Message: SCHEDULER_ADD_RECORDING
List[0]: The Cosby Show
List[1]: 2006-01-24 13:33:35.401 ProgramInfo::FromStringList, not enough items in list.

2006-01-24 13:33:35.401 Bad SCHEDULER_ADD_RECORDING message

[bjm]

Simple debug messages for proginfo sent with a MythEvent

[danielk]

(In [8706]) References #1089. Oops! Missing part of [8704].

[danielk]

Sorry Bruce, I didn't commit the whole thing.

This was a 'just-in-time' slave backend created with my WAF++ production box (sans svn). I was just shuttling diffs back and forth with scp, and must have copied the last bit backwards. I've just applied the last fix which includes a fix for the very thing you just ran into.

There may be other problems, so I'm leaving the ticket open until it works for you...

[bjm]

Verified that I have sucessfully transitioned from live to recording on a slave. The rule, reclist, oldrecorded and recorded* all looked good and the recording ended properly at the end of overrecordseconds. I've verified this in two different environments.

I did see some anomilies today where SetLiveRecording() was called but the master didn't receive the command but this may have been due to general confusion. One may have happend when I was inadvertantly close to the end time of the program. I'll look for this again now that it can function correctly.

I still want to test playback through the end of the recording and back to live mode for both master and slave. Start, stop, start on master and slave, etc.

[bjm]

Closing as I not finding any problems with starting the transition to or from saved recording with TOGGLERECORD on master or slave. I am seeing another problem but it is different enough that I'll put it in a different ticket.