[mythtv-users] Strange behavior under 0.16

[Shawn Asmussen]

I've been running 0.16 for a while now, and I've noticed some strange
behavior under the Delete Recordings menu. Lately, when I go into Delete
Recordings, I usually get a very long pause, and then it says, "The
connection to the master backend server has gone away for some reason.. Is
it running? Then, as soon as it finally displays that message, the list of
recordings pops up behind the message, and the preview window starts
playing the preview video of the first recording. The blue bar at the
bottom is completely full, and it says -2147483648% used, 0.00 GB free. In
reality, I'm currently about %70 full. I can delete recordings from this
menu, or go back and watch recordings, or whatever. Nothing else seems to
be affected. If I re-enter the Delete Recordings menu, I see the same
thing. Restarting mythfrontend doesn't help.

Here is what my mythfrontend log looks like when this happens:

2004-09-27 20:12:03 Default
2004-09-27 20:12:03 Connecting to backend server: 192.168.1.44:6543 (try 1
of 5)
2004-09-27 20:12:03 21      MYTH_PROTO_VERSION 13
2004-09-27 20:12:03 Using protocol version 13
2004-09-27 20:12:03 18      ANN Playback zen 0
2004-09-27 20:12:03 23      QUERY_RECORDINGS Delete
2004-09-27 20:12:04 21      MYTH_PROTO_VERSION 13
2004-09-27 20:12:04 Using protocol version 13
2004-09-27 20:12:04 18      ANN Playback zen 1
2004-09-27 20:12:04 15      QUERY_FREESPACE
2004-09-27 20:12:34 ReadStringList timeout.
2004-09-27 20:12:34 detectInterlace(Detect Scan, Detect Scan, 29.97, 480)
->Inte
rlaced Scan
2004-09-27 20:12:34 Interlaced: Interlaced Scan  video_height: 480  fps:
29.97
2004-09-27 20:12:34 Estimated bitrate = 0
2004-09-27 20:12:34 Commercial Detection initialized: width = 480, height
= 480,
 fps = 29.97, method = 1
2004-09-27 20:12:34 Image size. dispxoff 0, dispyoff: 0, dispwoff: 0,
disphoff:
0
2004-09-27 20:12:34 Image size. imgx 0, imgy: 0, imgw: 480, imgh: 480
2004-09-27 20:12:34 waiting for prebuffer...

and it goes on from there, but I think at that point I'm past anything
that has to do with the goofiness.

mythbackend.log just has this:

2004-09-27 20:12:03 MainServer::HandleAnnounce Playback
2004-09-27 20:12:03 adding: zen as a client (events: 0)
2004-09-27 20:12:04 MainServer::HandleAnnounce Playback
2004-09-27 20:12:04 adding: zen as a client (events: 1)

If I restart mythbackend, it seems to act normally for awhile, but then
later I'll come back and it will be back to acting up again.

Anybody else see anything like that?


The other major problem I'm having is that anytime I reboot my mythtv box
(Mostly due to occasional nvidia lockups. The 6111 driver doesn't like FC2
and the 2.6 kernel as well as it did the 2.4 kernel when I was running
FC1.), I have to restart the mythbackend I'm running on a second box as a
dedicated commercial detection server (Well, actually it's my file
server/firewall, but since not much CPU time gets eaten on there, I
thought I'd steal the CPU cycles to make commercial detection faster.) If
I don't restart the mythbackend on that box, the last thing that shows up
in the mythbackend.log on the slave server is:

DB Error (KickDatabase):
Query was:
SELECT NULL;
Driver error was [2/2013]:
QMYSQL3: Unable to execute query
Database error was:
Lost connection to MySQL server during query

Even after the main backend is up and running again, the slave won't do
anything at all until I restart that backend also. Is that normal
behavior, or should the slave backend be able to recover on its own once
the master backend is back up?

Shawn Asmussen