Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
On Sun, Jan 15, 2012 at 6:01 PM, Tom Metro <tmetro-blu at vl.com> wrote: > It also doesn't help that the non-MythTV clients are treated like 2nd > class members of the MythTV ecosystem. With the increasing popularity of > XBMC, it may become harder for MythTV devs to ignore the alternative > clients. I doubt it. From what I've seen over the years, the core MythTV developers are; in general; only interested in "scratching their itches". Unless one of the core developers suddenly decides to start personally using XBMC as a frontend, I wouldn't expect any changes here. They MIGHT accept code contributions from the outside, but not if this restricted their freedom to make internal code changes. They treat their MySQL database schema as an internal interface rather then as an abstraction through which third party software could interact. They do the same with the MythTV protocol. If you aren't running only their code (and preferably the latest release), don't bother them. > Getting a smoothly running home theater setup with open source software > is no different from how you approached building a Linux PC in years > past. It takes research to find what hardware and software components go > together well. The problem is that the switch from analog to digital has drastically upended the core MythTV functionality of capturing video streams. This often requires new hardware which usually requires new versions of MythTV. The MythTV developers lack of interest in maintaining abstractions from release to release didn't matter in the past because analog capture of RF signals was fairly stable and once you had a working capture system you could just freeze your version. The MythTV developers didn't cause the analog to digital change, but their way of (not) interacting with third party software hasn't made things any easier. > So for example, if you knew you wanted to run XBMC as your front end, > and found it didn't support MythTV 0.24, then use MythTV 0.23. (Granted, > not a very practical option if you've already upgraded to 0.24.) Which just isn't possible if you want to use what should be the right hardware for the job (for example MythTV supported cablecard compatible capture devices). Not doing it this way involves any number of problematic configurations if you are interacting with a cable TV system. You can forgo HD entirely and use composite analog capture devices and IR blasting with set top boxes. This is the oldest and is the most reliable. Or you can try your hand at doing component analog capture devices (Hauppauge HD PVR) which gives you HD but the trip via analog is going to lose quality (and reportedly the reliability is lower). Or you can try using FireWire to do digital capture directly from a set top box which is (again reportedly) even less reliable. All of these require significant ongoing payments to the cable company for set top box rental, lower quality recordings, and/or major reliability issues. A frequent response to this is that video capture is dead and we should all just get our video fix via Internet streaming sites. For me and I suspect many others that just doesn't work. I want access to many shows that aren't available via streaming sites and I would prefer not to have my kids one hour of television a night be dependent on the vagaries of the Internet. Bill Bogstad
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |