I've run into some quirks in my brief experiences with Myth and my configuration. They may be due to my misconfiguration (likely) or a bug in Myth (less likely). They may even have been solved already in other places that I haven't checked! With that disclaimer, here we go:

Following system reboot of the slave, mythbackend fails to properly shut down. This may seem benign, but the abrupt exit of the slave backend confuses the master, causing it to either crash or enter a state where nothing important gets done. Furthermore, upon return to Linux, the startup of the slave mythbackend process doesn't work properly, since the master is freaking out!

Workaround: Manually kill the backend process on the slave before rebooting.

#killall -s 9 mythbackend

KnoppMyth unable to connect to MySQL database
After a bit of tinkering I was able to get my Windows box to at least pipe an X session to the TV-out of my nVidia card. Mythfrontend then was unable to connect to my database. I recieved an error:

Client does not support authentication protocol requested
by server; consider upgrading MySQL client

This turned out to be related to the fact that I used MySQL version 4.1.3, which uses a different password hashing scheme, while the KnoppMyth MySQL client was built with older MySQL libraries.

Workaround: Modify the master backend MySQL database to use the old password hashing scheme. (Reference)

mysql -u root -p
mysql>SET PASSWORD FOR 'mythtv'@'192.168.1.%' = OLD_PASSWORD('my_myth_passwd');

Received error 'mythbackend dead but subsys locked' when trying to start the master backend This can happen following a reboot of a slave backend. The problem lies with a zero-byte lock file being present that is preventing mythbackend from starting properly.

Solution: Stop all instances of mythbackend. Delete the file /var/lock/subsys/mythbackend on the master backend machine. Restart mythbackend on the master; then restart mythbackend on the slave backend machines.

Back to MythTV Guide