[mythtv] Interesting Comparison

[mythtv at zacglen.com.au]

>
>You are probably right about XML.
>Thought about this myself as I also have problems with Myth and 
>
>communicating with the developers (well not all  of them ;-) ) thus
>considering brewing my own.
>The problem with a textfile for setup is that to implement a front/backend
>solution both probably need some access to this file and you get the problem
>of accessing that data. The database solution solves that problem nicely.

Accessing modifiable data isn't really a big problem.
In my case it is only the queue files that need modification.
In which case a simple prioritised locking scheme works fine (using flock
or fcntl or whatever). The only trick necessary is to use dual lock
files, and to fork a child process to unlock the temporary lock
file as soon as the parent process has commenced the flock os the]
main queue file. Sounds complicated but it really is a simple, cheap
and reliable operation

>
>My humble opinions on Myth are the following:
>1. The back/frontend idea is good
>2. I would prefer different programs instead of a "allinone" solution.
>    That is: 
>
>   - Backend's doing DVB reception, reading a file, doing Firewire etc.
>     All these creating a MPEG stream

There isn't even a need for a so-called backend.
My solution simply uses standard atd scheduler (albeit it has been slightly
modified wrt to niceness, and even SCHED_FIFO if you want).
So there is no backend whatsoever.
Jobs are created, and contention is eliminated through a simpler
wrapper script when jobs run.