I’ve set up MythTV with a separate frontend and backend machine a while ago. Now, I don’t always watch TV on my TV, but also on my workstation (as does Diana), which runs Windows XP (yea yea, eww, eww, etc). There isn’t any working MythTV windows frontend available, and some people don’t seem to like the idea so they guess there never will be one.
I’ve asked a few questions on the #mythtv-users channel relating to documentation of the protocol, which is severely lacking, but apparently the only thing one should do in that case is bash the person who is asking the question. So I’ll just bash back: someone really needs to learn how to write a decent protocol.
For starters, there is no back/forwards compatibility. At the start of the session you announce your version, and if it doesn’t match with the backend, you just get thrown out. Done.
Then, it’s a bit of a ridiculous protocol, with 8 characters where you can put (in text format) the length of the upcoming message, and then for x characters, the message itself. Parameters are separated by []:[], okay, probably not a likely sequence to be somewhere inside a variable. But you can only do some things with this protocol. If you want to get information instead of action out of the backend, you have to connect to the MySQL database yourself, which means another open port, another grant statement into your MySQL users, and another way to get incompatible when some small part in the database structure changes.
MythWeather, the weather forecast plugin, is also broken. Well, it’s broken in reality right now because msnbc changed their site, but that’s bad luck and can be fixed. But it’s also broken by design, as there is a webpage part, in PHP, for your MythWeb server, and then there’s a python part for on your frontend. Both with totally different code, just pulling the location from the database – in my opinion the frontend should query the backend through the protocol for the current weather info and be done with it. A frontend should be just that, a dumb front end retrieving info from the backend.
MythMusic. Ah, another great piece of design. You have a music collection on the backend, which is set up for MythTV. Then you have your frontend, which contains the actual music player. However, the backend does not stream your music data to the frontend, instead you must mount a (smb/nfs/whatever) share on your frontend (on the same mountpoint as where the music is on your backend, no less) and then it will play your mp3’s locally.
Of course in the transcoder profiles, many ID’s are hardcoded so you can rename and switch all you want, the transcoder will still pick profile id 2 from your database wether it’s what you wanted or not.
I haven’t dug deeper into this stuff, but I’ll bet there’s more where that came from — in my view caused by lack of decent coder docs combined with a broken protocol implementation.
I read on the channel the backend would likely need a complete overhaul, the database structure is completely idiotic and the frontend theming sucks majorly, so one has to wonder if there is ANY piece of this software which actually works the way it’s supposed to.
Update after more coding: it also crashes the entire backend when you give it bogus data. Combine this with absolutely no authentication whatsoever on the protocol and anyone can fuck up your scheduled recordings, tv watching, etc.
Update after calming down and receiving a wider audience by way of mythtvnews.com: many of these issues are known and are being worked on, but of course Rome wasn’t built in a day – if you can help, I guess it would be welcomed in making MythTV better — after this post you may think I hate it, but in fact I think it’s great, otherwise I wouldn’t be using it 🙂
