<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Jun 21, 2014 at 9:49 AM, Worik Stanton <span dir="ltr"><<a href="mailto:worik.stanton@gmail.com" target="_blank">worik.stanton@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think that MythTV has a design philosophy that I am uncomfortable<br>
with.  It is very capable, a wonderful example of a large and complex<br>
system.  And I will keep using it as it is the best there is.  But I<br>
cannot help but think that a 'unix philosophy' would be better.<br></blockquote><div><br></div><div>My opinion is that the backend architecture is pretty good. There are ugly bits, such as the way that multirec got hacked in, but overall it's proven to be flexible and powerful. It is complex, because it supports a huge variety of hardware types and configurations. I think the error reporting and documentation could be better.<br>
<br>I'm less impressed with the frontend design. I think it was a mistake to partition media by source/file type (tv separate to audio separate to video), they should have been partitioned by the type of content (movies, series, music, other video). There should be little or no difference in the UI between a series I've recorded and a series I've imported from DVD.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

That would be a collection of programmes that can copy from a digital<br>
tuner to disk, programmes to play those files, a programme to configure<br>
the tuners, a file in which the minimally useful details of those<br>
programmes are kept and the whole caboodle stiched together with cron<br>
jobs would be an improvement.<br></blockquote><div><br></div>You've left out the most important part of the whole system: the scheduler. I think you'd find that by the time you'd written that you'd be a lot closer to mythbackend that to your collection of separate programs.<br>
<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

It would not have all the bells and whistles - the search functions, the<br>
way Myth will keep a search for years and record much loved programmes<br>
after you have forgotten they existed... But it would be easier to set<br>
up and it would be less fragile.<br></blockquote><div><br></div><div>Unless it was designed really well I think it'd be more fragile. It would be very hard to handle errors between the various programs. If a recording fails because a tuner is not working you'd want the scheduler to provide an alternate tuner to use. That's not going to be easy to coordinate.<br>
</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

When Myth started, IMO, things were not so simple.  Configuring tuner<br>
cards was the most finicky part of the process IIRC.  In these days of<br>
digital tuners it is one of the simplest parts.<br></blockquote><div><br></div><div>IMO the first stumbling block for Myth users is understanding the model: video sources, recording groups, storage groups, etc. That stuff isn't really that difficult and it's not where the problems usually appear. From my perspective it seems most problems are caused by the external support programs; the tuner drivers (which were once often difficult to get working, as you note), the guide data import, lirc, ffmpeg etc. Changing Myth's architecture wouldn't resolve problems caused by component pieces of software and the fact that most issues arise from the bits that are already highly modular suggests to me that further modularisation isn't going to improve the situation.<br>
<br></div><div>The obvious way to make Myth simpler and a better user experience is to follow Apple's model: limit hardware options and limit configuration options. But that is not what the sort of people who use Linux want.<br>
</div><div><br></div><div>Cheers,<br>Steve<br></div></div><br></div></div>