After the do-release-upgrade switched me from the defunct Mythbuntu distro to Ubuntu, and clobbered a bunch of my MythTV packages in the process, I've nearly got everything working again.

I had to reinstall some mythtv-* packages (notably mythtv-database), and set up MySQL after the upgrade removed it. Luckily all the data was intact. In MySQL, I had to enable networking and grant permissions to the mythconverg database. Now I can successfully connect to MySQL on the MythTV master backend server from the client, so the database connection is OK. Also, I'm able to run the MythTV frontend locally on the master backend server, so I know the MythTV stack there is working.

However, both the dedicated MythTV frontend as well as my standard Ubuntu workstation (which did not go through this upgrade) tell me "Connection refused" on the MythTV port 6543 when trying to connect to the master backend. Nothing shows in syslog on the server side, and 6543 is in use ("nc -lp 6543" fails). The UFW firewall is inactive/disabled on client and server (and workstation). This was not a problem before the upgrade, so it's extremely unlikely network hardware is to blame.

I'm out of ideas to figure out what is blocking the traffic to the MythTV backend master server. Does anyone else have suggestions?

Additional note: Before I fixed the MySQL access, the MythTV Frontend initially would either start without any existing config or just crash. Once I got the MySQL access fixed, both the Frontend machine and my workstation started up with the unique MythTV themes I had chosen for each before the upgrade. This seems to indicate the MythTV Frontend connects to SQL just fine, it's just the MythTV backend traffic on port 6543 that seems to be failing.

2017-03-12 Update: Running netstat -4lnp |grep :6543 returns:

tcp 0 0* LISTEN -

So this makes me think the port is binding to the address rather than the actual server address I've entered. Even though the local Myth frontend on the server points to the full server address, this could explain things, but I'm not sure how to fix it even if this were the case.

  • Mythbuntu has been discontinued mythbuntu.org/home/news. You should install regular Ubuntu and the MythTV packages on it. – TheWanderer Feb 27 '17 at 0:01
  • @Zacharee1 Not sure if you read the question, that's what I did. – brianary Feb 27 '17 at 0:02
  • I missed that part, sorry. But do-release-upgrade switched distros? That doesn't sound right. I stil recommend you actually install a distro of Ubuntu and then MythTV on top of that, because it sounds like something went wrong. – TheWanderer Feb 27 '17 at 0:08
  • @Zacharee1 I'd agree that it did not go particularly well, but the switch to the new package sources seems fine. If I find myself resigned to starting over, I'm not sure I'd even stick with MythTV. Client and server both work locally. A connectivity issue like this really shouldn't be insurmountable. – brianary Feb 27 '17 at 0:20
  • I suspect that the issues you have are from a late upgrade; one that removed Mythbuntu packages from your system because the Myth team pulled them. That probably broke things on the system level. Since MythTV is still maintained, I think it's worth a shot. – TheWanderer Feb 27 '17 at 0:30

Allowing mythfrontend on a remote machine to access mythbackend running on a second machine

If mythfrontend is not being run on the same machine as mythbackend, there is some additional configuration required to allow remote access to mythbackend.

Two separate issues related to MYSQL on the mythbackend host may be at work:

First, ensure that networking is enabled in the my.cnf file '/etc/mysql/my.cnf' on the mythbackend host machine. In this file, by default there exists either the following (depending on version) which prevents a remote mythfrontend from accessing the info on the database on the mythbackend host.



bind-address localhost



Instead of skip-networking the default is now to listen only on localhost which is more compatible and is not less secure.

So a suggested solution is to change 'bind-address' to the machine's LAN IP address - although this will only work if the IP address is static and not dynamically assigned.


If bind-address is used, it can only be configured to use 1 IP address.



#bind-address localhost






No '#' on the final example

Second, it may be necessary to alter the privileges table for the MythTV database to allow the frontend to access the mythbackend (NB; The mythfrontend communicates with the mythbackend by logging on to its mysql database -- generally as the user mythtv. On some systems by default mysql will not allow a user on another machine to login. The following grants users with id mythtv from any machine access to the mythtv databases).

This can be done by executing the following from the command line on the mythbackend machine (thanks to Torfinn Ingolfsen, Norway for this).


The 'passwd' in the command below should be the password listed in MythTV's configuration, which is also found in ~/.mythtv/mysql.txt

By default, the mysql database root user has no password, so this also should be changed by securing the default mysql accounts, refer to: http://dev.mysql.com/doc/refman/5.1/en/default-privileges.html

mysql -u root -p mysql
mysql> grant all on mythconverg.* to 'mythtv'@'%' identified by 'passwd';
mysql> flush privileges;
mysql> exit;
  • This looks like the MythTV or MySQL documentation. I've done all of this already (commenting bind-address & granting access). That's how I'm able to access the MySQL server from the other machines using the MySQL client. – brianary Feb 28 '17 at 1:37
  • @brianary maybe I misunderstood your problem. You don't want to comment the bind-address, you'll want to enter the static address there. I'm sure that you've checked that the database password in MythTV is correct. – heynnema Feb 28 '17 at 14:40
  • As indicated in your answer and the docs, commenting out should work because the default value of bind-address is to bind to all of the server's addresses. Yes, the password was picked up from the mysql.txt file and migrated to the config.xml, was working before, and I've verified it works for the MySQL client. – brianary Feb 28 '17 at 15:47

It turns out the mythtv backend service was just starting before the network was up! Restarting the service manually after startup fixes this issue. (Thanks to pbennett.)

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.