MythTV

[tmetro-blu-5a1Jt6qxUNc at public.gmane.org (Tom Metro)]

Jarod Wilson wrote:
> I actually did have these topics in my notes to talk about last night,  
> but with me being late and the volume of questions (which isn't a bad  
> thing, I like interactive), I just didn't get around to them, so I'll  
> try to at least briefly address them here...

No problem. Your talk covered a lot of ground. Thanks for the reply.

Before I respond to your comments, I want to comment on a few questions 
that were posted to the list prior to your talk, and a few that were 
brought up during the talk.


At the meeting Rich Braun asked about low power front-end hardware. 
Jarod mentioned the Sigma Designs-based boxes, such as:

http://www.networkedmediatank.com/
http://www.popcornhour.com/

And then there is the MediaMVP-HD, the HD version of the MediaMVP from 
our friends at Hauppauge. It's also a Sigma Designs-based box.

http://www.nabble.com/MediaMVP-HD-tp22354968s24861p22357792.html

One problem with Sigma Designs is that they're not fully open with their 
drivers. Debian runs on some Sigma Designs boxes, and Hauppauge may help 
move things along, but even with the standard definition MVP, Hauppauge 
kept some drivers closed source and some of the hardware interfaces 
proprietary (possibly due to licensing restrictions imposed by IBM).

The other issue is that any front-end that relies entirely on a hardware 
decoder for everything ends up being rather "brittle" and unable to keep 
up with the rapidly evolving world of digital video. Between the MVP and 
a Divx DVD player, I have two hardware devices that each can play only a 
very specific video format, resulting in a lot of transcoding and 
trial-and-error.

I tend to think the  approach taken with the NVIDIA ION platform, where 
the hardware is used more as an assist to the decoding process (rather 
than a black box that you feed the video bitstream into), is more 
flexible and resilient to future changes. Not to mention that it is 
likely to be deployed far more widely than specialized set-top-box 
hardware, and thus more rapidly supported by common codecs and media 
players.


Rich also asked about on-the-fly transcoding. Unfortunately the MythTV 
protocol doesn't incorporate the concept of negotiating for the 
capabilities of the client. There are, however, a few projects 
attempting to add this kind of functionality. One developer, who was 
trying to get a way to do on-the-fly transcoding for iPhone playback, 
came up with the idea of creating a MythTV protocol proxy server, which 
inserts a transcoder (like ffmpeg, similar to what VLC does) into the 
video stream. It seemed promising, but I think he halted the project 
when he found a different strategy that addressed his iPhone access 
scenario (Apple added native support for video streaming to the OS). See 
these threads for more info:

http://www.nabble.com/Interesting-project-being-talked-about-on-mythtv-user-list...-tt22047893s24862.html
http://www.nabble.com/MythTV-Transcode-Proxy-libcmyth-support-tt22049665s24862.html
http://www.nabble.com/MythTV-Transcode-Proxy-and-libcmyth-Developments-tt22571108s24862.html

Outside of MythTV, you can use VLC for this kind of thing. Aside from 
setting up a VLC server and client, you'd need to take some additional 
steps to be able to browse your MythTV recordings with friendly file 
names, and it would be a different UI. Some people in the mvpmc 
community do this.


Someone asked whether MythTV can upscale resolution like a DVD player. 
I'm not sure, but I seem to recall some mention of that on the users 
list with regards to the deinterlacing algorithms used. The front-end 
has some settings where you can choose different playback modes and 
deinterlace algorithms, and I think upscaling might be an option there. 
A search on the users list should turn up a more useful answer.


Bill Ricker wrote:
> * is there a system76 style integrator that will preinstall and
> preconfigure so it's not a six weekend google-and-irc HELP project?

I don't know about a US company (I wasn't familiar with the one Dan 
mentioned), but there was an Australian company that specialized in 
delivering turn-key MythTV systems. One of the employees was a regular 
poster to the MythTV lists.


> * is there a choice besides Haupage?

A choice I expect to see become more practical - and hopefully more 
legal, too - in the not too distant future, is having no tuners. If you 
think about it, we're all paying for video capture hardware to 
redundantly capture content that most of us have access to. This used to 
be done for technological reasons, such as bandwidth. But now it is done 
more for legal reasons.

Consider off-air national networks. Why have hundreds of thousands of 
users redundantly recording those, when just a dozen or so would provide 
adequate redundancy to feed an online distribution system?

An application like MythTV is going to need to evolve from being a video 
capture tool, to being a video management tool (which it already does) 
and a portal to online content (which it does to a limited extent). A 
natural extension would be integration of BitTorrent, but that's a 
direction the MythTV developers don't want to go in for obvious legal 
reasons.


> * what disk arch is good for this?

This was mostly answered at the talk. I'd second the recommendation for 
XFS. I'd also emphasize the point that MythTV supports storage groups, 
which is a less hassle way to aggregate storage than using LVM.

I'd also recommend RAID. While backing up TV shows may not be important, 
improving the uptime and reliability - which is what RAID accomplishes - 
of your MythTV system is a worthy goal. The pair of RAID1 arrays that 
permits rolling upgrades as Rich Braun recommends is a good way to go. 
That gives you 4 spindles to distribute reads, and two storage groups to 
distribute recording. (With the OS and DB on a 5th spindle (or pair).)


Bill Horne wrote:
> 2. Advantages over a store-bought unit.

Can you actually skip (not just fast forward) over commercials with a 
TiVo? Can you program a TiVo to automatically skip over commercials?

In the long run you're trading off polish and ease of setup for a device 
that won't restrict you from doing things that might not sit well with 
Hollywood, even if perfectly legal.


david-8uUts6sDVDvs2Lz0fTdYFQ at public.gmane.org wrote:
> - The web interface is VERY powerful.  Being able to diddle with my 
> schedule, clean up conflicts, verify I recorded something, see the
> status, or delete recordings I watched live is indispensible.

MythWeb is terrific for setting and managing schedules. I've always used 
it as my primary interface for that. It's also great for reviewing 
upcoming recordings (to check for conflicts, etc.) But it falls short 
when it comes to reviewing stuff that's already been recorded - at least 
if you have a sizable collection of recordings. It provides no means to 
navigate and drill down to a particular recording, in the same way all 
other MythTV clients do. Instead it throws one big list at you, which I 
can't even view these days as rendering it exceeds the amount of memory 
Apache allocates to PHP. (I could boost the setting, but there's no 
point, as the UI still isn't usable.)


> - More ways to search for programming than you could imagine, down to
> the level of actual SQL queries.

I occasionally use SQL to find stuff, but I make regular use (via a cron 
job) of SQL to rewrite the metadata for recorded programs to 
re-categorize shows that the listing service has poorly categorized, or 
do other customizations to the listings data. (For example, putting all 
movies into a "Movie" category.)


Jarod Wilson wrote:
> MythTV's support community is entirely made up of people who provide
> support out of the goodness of their hearts...
> I used to be one of them myself, but due to list volume...I more or
> less completely dropped off the mythtv- users mailing list for the
> better part of about two years.

That's exactly my point.


> I've recently started reading and replying on the list again though.
> I just have to apply fairly strict internal filters -- I try to only
> reply in threads where I *know* the answer for sure, or if its about
> something Fedora-related or LIRC-related...

Good that you've figured out a system for making it manageable for 
yourself. Ideally there should be some sort of a similar filter or 
subdivide strategy for everyone, but I'm not sure what. Breaking the 
list up into regional sublists? (New England MythTV Users?) Topics, like 
tuner hardware, LIRC, scheduling, etc.?


> For the casual follower, Gossamer Threads' searchable indexing of the  
> MythTV mailing lists helps out tremendously:
> 
> http://www.gossamer-threads.com/lists/mythtv/

Yes, the list is still quite useful as a data mining target.

At the talk someone asked for the recommend hardware picks for tuners, 
IR blaster, etc, and mining the list is probably the best way to 
accomplish that. It's what I did prior to building my system.


> There's also a #mythtv-users IRC channel on freenode.net...

Add #ubuntu-mythtv to the list, if you're using Mythbuntu or MythTV on 
Ubuntu.


>> ...it's also worth noting that MythTV devs have a
>> policy of rejecting bug reports that don't come with patches.
> 
> Yeah, that's... A touch annoying, not really a policy that I agree  
> with, but I do understand on some level. All the MythTV devs have day  
> jobs that typically don't revolve around MythTV, so most development  
> is doing in their spare time, and generally, only on things of  
> interest. As long as it works for THEM, they're happy.

Glad to see you agree. It's a flawed strategy. Lots of bugs will be 
noticed and reported by non-developers. That's valuable QA data that 
shouldn't be discarded. Most open source projects depend on volunteer 
developers, but even if the main developers don't want to spend their 
time on bug fixes, other developers looking to get their feet wet might.

This alone wouldn't be such a big deal, but this policy seems to 
compound with other factors that tend to make the MythTV project have 
higher barriers for entry as a contributor than a lot of other open 
source projects. The "you can customize anything" claim that comes with 
most open source projects goes largely unrealized with MythTV, with the 
exception of the bits around the fringe (like what you can do through SQL).


>> Do you run the SVN version everywhere, and find it stable enough?
> 
> I do run the svn trunk version everywhere, and yes, its plenty stable  
> enough.

Good to know. Of course they also recommend that if you run the SVN 
version that you keep up with the MythTV developer's mailing list. (So 
you're aware of significant changes and known breakage.) While it is far 
less volume than the users list, it still takes a fair bit of time to 
follow.


> ...if it ain't broke, don't fix it, and for most developers, it ain't  
> broke, and for many, there's not a lot of joy to be had in code  
> refactoring.

The idea is that refactorings should be driven and motivated by new 
development. So for example, when MythTV evolved to client-server, that 
would be the time to refactor and extend the protocol to hide the 
database interaction. Instead, they applied an agile approach of sorts - 
implement the simplest thing that will work - but are paying the price 
of accumulated "technical debt" by having clients that are rigidly 
coupled to the server.

The database issue is only one of many. The client is actually full of 
functionality that should be implemented on the server, and because it 
isn't, has to be redundantly implemented in other third-party MythTV 
clients.


>> Almost the entire system is implemented in C, but the  
>> UI,
>> and things like commercial break analysis ought to be implemented with
>> an interpreted language and be more capable of end-user modification.
> 
> Commflagging, I dunno, you might lose out considerably  
> on performance moving to an interpreted language.

Commflagging can be divided into a data acquisition phase and an 
analysis phase. The existing code is already split up this way to some 
extent. During the data acquisition phase - which is written in a high 
performance compiled language - you scan the video for blank frames, 
logos, and other artifacts used to feed the analysis. Then the 
interpreted code can deal with the far less arduous task of deciding 
where and when a commercial break starts and ends. A common set of 
attributes can be analyzed in a wide variety of ways, so a design that 
lets users tweak and try out their own analysis algorithms could greatly 
improve the quality of commercial flagging.

It also opens the door to other possibilities, like creating a 
centralized database of commercial break points for shows, which could 
take advantage of statistical averaging and human corrections. (Not 
unlike the SchedulesDirect proposed enhancement to incorporate user 
corrections to the listing data.)


> libcmyth is the most interesting one to me, from the mvpmc project,
> and also apparently used by xbmc now...

Yup, there are a handful of projects that use mvpmc's libcmyth.


> As I mentioned last night, one of the not-so-visible-yet changes in  
> MythTV 0.22 is an overhaul of how screen elements are rendered... 
> ...there *is* one new from-scratch theme in the  
> works, using almost exclusively the new rendering infra:
> 
> http://www.fecitfacta.com/Graphite/Home.html

Nice. Better aesthetics are great, but my issue with the MythTV UI is 
more in the areas of usability. In that regard, I find mvpmc to be 
superior. For the basic, repetitive actions needed to select and play 
shows, its UI works more efficiently.

  -Tom

-- 
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/