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