[mythtv] Interesting Comparison

Dag Nygren dag at newtech.fi
Fri Mar 3 13:21:59 UTC 2006


> 
> 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

Well, it is if you have to create your own networking protocol.
Haven't considered yet how much info really is needed on the client
side though. Guess you at least need to access it for updating settings
from the frontend .

> >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.

I think you misunderstood me here. My backend would be more like a
"format converter" that makes a MPEG stream out of everything.

The Myth backend in my solution would be the scheduler, which would
stand on it's own as a process, possibly as you say just a simple atd (like)
thing.

My suggested architecture is actually "copied" from the EMC Networker
backup solution, where it works very well. The other inspiration is  UNIX.

I find Myth to be more like a solution programmed with  Windows rules
instead of my preferred UNIX rules.

Best
Dag



More information about the mythtv-dev mailing list