[mythtvnz] Recordings not happening without a reboot

[Steve Hodge]

On Sat, Jun 21, 2014 at 9:49 AM, Worik Stanton <worik.stanton at gmail.com>
wrote:

> I think that MythTV has a design philosophy that I am uncomfortable
> with.  It is very capable, a wonderful example of a large and complex
> system.  And I will keep using it as it is the best there is.  But I
> cannot help but think that a 'unix philosophy' would be better.
>

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.

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.


> That would be a collection of programmes that can copy from a digital
> tuner to disk, programmes to play those files, a programme to configure
> the tuners, a file in which the minimally useful details of those
> programmes are kept and the whole caboodle stiched together with cron
> jobs would be an improvement.
>

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.

It would not have all the bells and whistles - the search functions, the
> way Myth will keep a search for years and record much loved programmes
> after you have forgotten they existed... But it would be easier to set
> up and it would be less fragile.
>

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.

When Myth started, IMO, things were not so simple.  Configuring tuner
> cards was the most finicky part of the process IIRC.  In these days of
> digital tuners it is one of the simplest parts.
>

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.

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.

Cheers,
Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ourshack.com/pipermail/mythtvnz/attachments/20140621/3a9b05f3/attachment-0001.html>