[mythtv] mythbackend --resched and updating override record rules

[Michael Rice]

I've been looking at MRE (Myth Recording Extender) of late.  I am
having an occasional problem where it doesn't extend the recording.
To explain a bit it works by creating and/or updating an override
recording rule and incrementing the endoffset field by 5 minutes.  It
then calls mythbackend --resched to reschedule.  When it works it
shows this in the log:

TVRec(1): updating recording: NHL Hockey 1074 Sun Mar 2 12:59:00 2008
Sun Mar 2 14:05:00 2008

Here is part of the log on a recent fail.

Something (not MRE) caused a reschedule:
13:58:00.816 Reschedule requested for id 0.

Which finished:
13:58:08.887 Scheduled 2492 items in 8.1 = 0.00 match + 8.06 place

Now while that was running MRE executed a mythbackend --resched:

2008-03-02 13:58:07.825 read  <- 17 21      MYTH_PROTO_VERSION 40
2008-03-02 13:58:07.827 write -> 17 13      ACCEPT[]:[]40
2008-03-02 13:58:07.830 read  <- 17 28      ANN Playback masterbackend 0
2008-03-02 13:58:07.832 write -> 17 2       OK
2008-03-02 13:58:07.840 read  <- 18 27      ANN Monitor masterbackend 1
2008-03-02 13:58:07.842 write -> 18 2       OK
2008-03-02 13:58:07.845 read  <- 17 24      RESCHEDULE_RECORDINGS -1
2008-03-02 13:58:07.846 write -> 17 1       1

And apparently an error occurred:
2008-03-02 13:58:07.852 MythSocket(86a3208:18): socket is readable
2008-03-02 13:58:07.858 MythSocket(86a3208:18): socket closed
2008-03-02 13:58:07.859 MythSocket(86a3208:18): state change Connected -> Idle
2008-03-02 13:58:07.869 MythSocket(86a3208:-1): cb->connectionClosed()
2008-03-02 13:58:07.852 MythSocket(90eaf28:17): state change Connected -> Idle
2008-03-02 13:58:07.940 MythSocket(90eaf28:-1): cb->connectionClosed()
2008-03-02 13:58:07.942 MythSocket(90eaf28:-1): writeStringList:
Error, socket went unconnected.

A few seconds later MRE executes another --resched since two
recordings needed extending during this check.  This one worked ok:

2008-03-02 13:58:09.892 read  <- 17 24      RESCHEDULE_RECORDINGS -1
2008-03-02 13:58:09.892 write -> 17 1       1
2008-03-02 13:58:09.893 MythSocket(aa7bf3f8:17): DownRef: 1
2008-03-02 13:58:09.893 MythSocket(aa7bf3f8:17): socket is readable
2008-03-02 13:58:09.895 MythSocket(aa7bf3f8:17): socket closed
2008-03-02 13:58:09.896 MythSocket(aa7bf3f8:17): state change Connected -> Idle
2008-03-02 13:58:09.897 MythSocket(aa7bf3f8:-1): cb->connectionClosed()
2008-03-02 13:58:09.898 MythSocket(aacc0120:18): socket is readable
2008-03-02 13:58:09.898 MythSocket(aacc0120:18): socket closed
2008-03-02 13:58:09.899 MythSocket(aacc0120:18): state change Connected -> Idle
2008-03-02 13:58:09.900 MythSocket(aacc0120:-1): cb->connectionClosed()
2008-03-02 13:58:09.970 Reschedule requested for id -1.
2008-03-02 13:58:17.466 TVRec(1): StartRecording(NHL Hockey)
2008-03-02 13:58:17.757 MythEvent: RECORDING_LIST_CHANGE
2008-03-02 13:58:17.759 MythSocket(b5e0aa30:12): UpRef: 2
2008-03-02 13:58:17.759 TVRec(1): updating recording: NHL Hockey 1074
Sun Mar 2 12:59:00 2008 Sun Mar 2 14:05:00 2008

The second --resched caused one of the recordings to extend but the
other recording ended.

Questions:

What could cause the socket to become unconnected?

Is it a problematic to execute a mythbackend --resched when a
reschedule is already running?

What problems am I likely to see running two (or more) mythbackend
--resched calls back to back?