[mythtv-users] Mything thomething

[Raymond Wagner]

On 5/28/2011 02:18, Tyler T wrote:
> Make it simple to set up and use all functions via an
> integrated/embedded web interface that ships with the software(i.e.,
> no more nightmares trying to convince Apache to run MythWeb).

Web setup is in the works.  There are no plans to integrate MythWeb.

> For that matter, I'd also use SQLite to eliminate the requirement for MySQL.

SQLite has been tried before, and found lacking.  There are plans to 
migrate to embedded MySQL, which while will still require the 
dependency, will not require any user setup.


> Being web based, it would be platform-agnostic and friendly to set-top
> and mobile FE devices, which are increasing in popularity.

Except that all your mobile frontends and set top boxes are going to 
have different screens and different capabilities.  Just having a web 
interface does not make a 'one-size-fits-all' solution trivial.  The 
recently rewritten, and considerably more extensible, web services 
interface should make writing programs to run on such devices and 
interface with MythTV much easier.

> I would break all functions into separate components that call
> existing tools and use existing protocols as much as possible to keep
> code base small (i.e., don't write any code that tunes and records --
> just call tzap and dvbstream: the code's already been written and is
> already maintained by someone else). This would take Myth's 1.25Mloc
> and make it... well, tiny in comparison. Not only does this reduce dev
> workload, it makes it easier for users "off the street" to get into
> the code and submit patches.

Calling out to dozens of external applications for every little task, 
handling their assorted inputs and outputs and error codes, handling 
multiple different versions of each that users may have installed, it 
all becomes one giant mess and a pain to maintain.  Just look at all the 
problems with nuvexport over the years with changing command line 
arguments in ffmpeg.  There is a reason APIs exist, and people use 
them.  For anything larger than quick scripts, it becomes easier to manage.

> I would make it resilient, by having each component an independent
> processes, including a separate process for each tuner. One tuner
> process deadlocks? Fine, your shows on the other tuners will still
> record.
>
> I would make a proactive watchdog process, that will restart killed
> and deadlocked processes and recordings without human intervention.

A breakup of mythbackend for these purposes is planned.

> I would have it repair and back up databases automatically (by default
> out of the box),

Automatic backup already occurs during updates, and adding a cron job 
with the backup utility is simple enough (and done automatically by some 
distros).  Automatic repairs are planned for when the database becomes 
embedded in the master backend, and it can ensure nothing external will 
futz with the database while it is attempting repairs.

> I would embrace US ATSC EIT as a primary listings input path (though
> SD/XMLTV would still be supported). I'm convinced Myth users/devs only
> scoff at ATSC EIT because it was poor when ATSC was new. Now, years
> later, ATSC EIT seems to work great but nobody has bothered to check
> again.

On a whim, I decided to check this.  In my local area, the stations 
provide the following:

NBC: 12hrs (FCC minimum)
ABC: 24hrs
CBS: 12hrs
FOX: 48hrs
TBN: 72hrs
PBS (1): 12hrs
PBS (2): 18hrs
PBS (3): 12hrs
MyTV: 12hrs

So I have all of two channels providing more than a day of guide data, 
and only one of them is of any worth.  A quick scan through 
http://www.rabbitears.info/market.php seems to show 1-2 days of data is 
the norm, and stations giving out a week of data are the rare 
exception.  I feel justified in my scoffing once again.

> I would make the recording priorities logical. Right now, Myth's
> "remove all tuners and re-add them in a specific order" seems like a
> kludge. Also, my understanding of Myth's tuner priorities makes no
> sense and seems like a useless feature that will give unexpected
> results for 99% of users.

Removing all tuners and re-adding them to change order is a kludge.  
Dynamic re-ordering is planned for the web setup being written presently.

> I would have it automatically write an XML metadata file with each
> recording to alleviate DB pains and to make interoperation with
> set-top devices better (though recording info would still be
> duplicated in the DB for ease/speed of access).

Planned and half written as a proof of concept years ago, however it was 
intended as a means of allowing detachable frontends, such as a laptop 
taken on a trip, rather than any means of database backup or 
interoperability with other programs.

> It would support real-time (on-the-fly) user jobs that can commflag,
> transcode, or do other interesting things to the recording stream
> in-flight, between tuner and disk. Post-processing would still be
> supported for low-end systems.

All currently supported.