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 |
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/
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |