[mythtv-users] Slave backend disconnections after moving from r22901 to r22949

[Jim Stichnoth]

On Fri, Dec 4, 2009 at 4:57 PM, Jim Stichnoth <stichnot at gmail.com> wrote:
> Unfortunately, it's a production system and the WAF will suffer
> mightily if I try to investigate.

(Wife sleeping off headache) == (opportunity for further investigation)

I found two problems so far.  First,
MainServer::HandleQueryRecordings() does something strange.  If a
particular recording was done on a slave backend and it has a filesize
of zero and the recording has "completed", it calls
ProgramInfo::SetFilesize() with the current filesize, which is of
course 0.  SetFilesize() then calls the new Update() function which I
believe sets this into an infinite loop.  So if a frontend is trying
to load up the recording list, it may never get a chance to display
the Watch Recordings screen because of all the update loop.  A zero
filesize recording comes up sometimes from a failed recording, which
seems to happen especially often on the HD-PVR.  I'm not sure why that
call to SetFilesize() is there; it looks like a partial copy from the
case where the file is on the master backend.  This is also a
"problem" pre r22932, but a minor one because there was no Update()
call to push things into a loop.

Second, at least for an HD-PVR on a slave backend, the filesize of an
in-progress recording is being updated far more often in r22949 than
in r22901, like every 2-3ms.  While this happens, mysqld is clearly
being pushed, consuming ~15% CPU on an E5200.  Also, these
UPDATE_PROG_INFO events are being pushed around at a similar
frequency, unless I comment out the Update() call in SetFilesize().
The filesize updates are definitely happening at a reasonable
frequency in r22901; I don't know what happened between r22901 and
r22949 to change that.

Jim