Tales From The Geek Side

Mytharchive is written to assume that the backend and the frontend machine are the same. To work around this I do the following:

1. Use a frontend to select recordings for export. I specify the output to be an iso image.
2. Allow mytharchive to fail. Then copy /tmp/config/mydata.xml to the backend machine
3. Install mythfrontend on the backend machine (grrrrrrr I HATE THIS but it is necessary because mythreplex is required and found in the frontend package)
4. On the backend machine modify /usr/share/mythtv/mytharchive/scripts/mythburn.py at line 134 by hardcoding the hostname of my frontend machine so that the configuration options are correct. Note that you will still have to insert a RecordFilePrefix entry into the ‘settings’ table of the ‘mythconverg’ database for the frontend host. Mythburn.py uses this setting to find the recording files.
5. On the backend machine create $MA_TMP/logs and $MA_TMP/work where $MA_TMP is the directory that you configured as thetemp directory for mytharchive in the mytharchive setup options.
6. On the backend machine, as the mythtv user, run /usr/share/mythtv/mytharchive/scripts/mythburn.pl using the mydata.xml file that was created in /tmp/config on the frontend machine

After doing all of that you should have an iso image in /tmp/work/mythburn.iso on the backend machine. I then burn that to DVD over NFS.

The other night I switched my my Via M10000 based frontend to use the Retro MythTV theme (after I had learned that msttcorefonts is required for this theme). I also enabled OpenGL. Everything seemed OK, I even watched a recording or two. Then it started crashing left and right. I disabled OpenGL and I still had stability issues. Finally I gave up and reverted back to the good old Blue theme with no OpenGL. Now it’s rock-solid stable again.

The mytharchive plugin for mythtv is supposed to make exporting data from MythTV easy. My experience with mytharchive is not favorable. First, the GUI is very unintuitive. That’s partly because the GUI is not expected to have a mouse and designing a decent GUI for cursor controls isn’t easy. However, this GUI is just plain hard to use.

When I finally got to the point of creating a DVD mytharchive errored out. After looking at the source code for a while I found that it was because MythArchive wanted a value for ‘RecordFilePrefix’. That setting applies to the backend and tells myth where to store files. This was a big red flag because it meant that mytharchive expects files to be present to the local system. My myth frontends do NOT reside on the same machine as the backend. Ugh #1.

To resolve Ugh #1 I nfs mounted /var/lib/mythtv. I then inserted a ‘RecordFilePrefix’ to the settings table of the mythconverg database for the frontend that I was working with. That got me past the first problem.

Finally the DVD creation process started. It started and promptly stopped with a new error. This time it errored out because it couldn’t run mythtranscode which, again, exists on the backend and not on the frontend. At this point I had to give up all hope of running Mytharchive on the frontend.

My current approach is a nasty hack to get mythburn.py to run on the backend by messing around in the settings database until all of the incorrect assumptions made in the code are satisfied.

If you attempt to use the Retro theme for MythTV and you do not have msttcorefonts installed you will have no menu text. The debian-multimedia packages for this theme suggest msttcorefonts but they should be a dependency.

I would like to tear apart the CreateService function call. It takes “only” 13 parameters. Here is some code I just wrote:

svc = CreateService(scm,
SERVICE_NAME,
SERVICE_NAME,
SC_MANAGER_CREATE_SERVICE,
SERVICE_WIN32_OWN_PROCESS,
SERVICE_DEMAND_START, // for now require manual
// starting.
SERVICE_ERROR_NORMAL,
binPath,       // Path to exe.
NULL,          // load order doesn't matter
NULL,          // tag order doesn't matter
NULL,          // no dependencies
NULL,          // use local system account
NULL);          // No password needed

The first parameter is a handle to a service control manager which you have to open with another function call that takes only three parameters (that’s reasonable) one of which is a sensible bitflag parameter.

The next 2 parameters are services names and display names. I think these should be the same. Having two makes little sense.

The next parameter specifies what sort of access you want to give the service. I think it would be better if a sensible default were used and a function provided to change the default, maybe ServiceSetAccess().

The next parameter is bit flags specifying what you really want to do. Did you know you can install a kernel driver using CreateService? Sure why not? I mean, who really needs KernelDriverInstall()? That wouldn’t make any sense at all when you can just put a flag in a call that already exists.

The next parameter is the start type. I’m OK with this parameter.

The next parameter is stupid. It specifies what you want the program that starts your program to do if your service errors out. WTF? Why should my service dictate the action of another program? stupid.

The next parameter is a full path to the service executable.

The next THREE parameters can all be NULL or you can specify 14 billion options for dependencies among other services, etc, etc. stupid. Why is this in this function? Why not have ServiceSetDependencies? One of these options is a “Pointer to a double null-terminated array of null-separated names of services or load ordering groups that the system must start before this service.” That’s nice and simple.

The last two parameters are to run the service as a different user. I disagree with providing a password since that means that the system needs to store the password and if the password changes for the user account then the service will not run. In addition this would be better as a different function, maybe ServiceSetUser(). Since a “super user” is starting the services that user ought to have enough privilege to switch to a different user context.

Truly I understand why there are so many crappy programmers out there when you see ridiculous code from a well respected company like Microsoft.

I’m honestly a bit surprised that the win32 API isn’t this:

CreateService Reference from MSDN