[mythtv-users] Mything thomething

[Tyler T]

I'll throw my .03 in as well. I've had a bit of a love/hate
relationship with Myth too. I understand that part of the reason Myth
is where it is, is because it grew that way organically rather than
being "architected". Sometimes it makes sense to throw things out
start somewhat fresh, as MS did from Windows 98 to Windows NT. For
example, if I were to architect a all-new, pie-in-the-sky DVR solution
like Myth today, I would:

Make it lightweight with minimal hardware requirements, embracing
single-spindle, low RAM, slow CPU systems. Especially ARM, which is
increasing in popularity. Turning your little NAS or wireless access
point into a DVR BE is a big win for many users.

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). For that
matter, I'd also use SQLite to eliminate the requirement for MySQL.

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

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.

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.

I would have it repair and back up databases automatically (by default
out of the box), email users about problems the watchdog couldn't
solve on it's own (so nobody has a nasty surprise about a missed
recording), queue several recordings in advance (in case the scheduler
process goes away), and periodically automatically scan for new
channels / moved channels.

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.

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.

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

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.

I would ditch the whole seektable business. Modern players like
mPlayer and VLC seem to have no trouble seeking modern MPEG2/MPEG4
files without a separate seektable, so eliminating seektables from the
DB would remove a ton of DB writes during a recording -- those very
same writes that seem to be the source of disk contention troubles for
so many Myth users. Without seektables, you can have a single hard
drive spindle for the OS, DVR software + DB, and recordings storage
with fewer conflicts.

----------

I worry that at some point Myth may collapse under the weight of cruft
upon cruft, just as Mozilla seems to be doing. The constant playback
pauses and MBE deadlocks may already be a sign of impending implosion
-- it seems like there is just too much code complexity to chase these
things down and fix them quickly or easily? Maybe Myth needs to throw
a little of the baby out with the bathwater to get back to a
manageable project size. Already some people are rejecting Myth to use
and work on new projects like TVHeadend and Showtime -- these are
direct competitors to MythTV's BE and FE, respectively, and took a
very different approach to architecting a DVR solution... a different
approach that I think has a lot of merit. Maybe Myth should consider
moving in a different direction before it goes the way of XFree86.

Don't get me wrong, I still use and like Myth. I hope my post is taken
as food for thought and maybe a hope for the future, not a denigration
of Myth or its devs.