On Tue, 2009-06-30 at 10:15 -0700, Michał Sawicz wrote: > Dnia 2009-06-30, wto o godzinie 16:48 +0200, David McLeod pisze: <SNIP> > > Actually if LiveTV is more important than recorded shows is debatable. > According to #mythtv-users most of the users set in their MythTV setup > rarely use LiveTV. They have so much recordings set up they don't have > the time to watch live. Of course the ability to watch a show > currently > being recorded is needed, too. The usual PVR does never show a > completely 'Live' TV. It's always a recording, just a recording of > what > is currently broadcasted. This, in turn, allows for all the use cases > you've described.
This is how I use it. > > What we really need, IMO, is a new way to do EPG. The stale old table > of > channels vs. time is soooo 90s. We need to leverage the abilities > Moovida provides us with in terms of UX and design. I'm not saying I > know what to do, I don't even have a set idea of what could we do, I > just want us to brainstorm here. I usually use Myth's search feature rather then the channel vs time for this. > Another thing is channel hierarchy. I don't think a flat list digs it > now that we have hundreds if not thousands of channels available. Again, this is one of the reasons to not bother with live tv. What I want to do is watch the shows I want to watch, not "tune to channel 107 at 5:30pm". You let the PVR do all of that. I think the EPG should be designed around letting you pick what you want to watch. Sort by Genre of show, similar shows to what you like, etc and then let you schedule recordings easily. > I > think the ability to arbitrarily set up a tree of channels (where the > same channel can show up in different branches) would allow for easy > and > user-defined grouping by service provider, channel type (movies / > sports / news), favorites etc. I think thats probably too confining. I'd take your 90's comment and apply it to channels entirely. The SciFi channel for example plays science fiction and and sometimes fantasy. Say I was a Scifi nut but didn't like fantasy. If the tree was more like: Sports/All Sports/Football Sports/Basketball Science Fiction Fantasy Drama/All Drama/Some kind of hospital show series Etc. I could just select based on what I liked. > > > 3. UI Hierarchy > > > > > > > > > TV > > > Watch > > > TV Guide > > > Search > > > Keyboard + Results > > > Media Results > > I know that 'Watch TV' is the usual way to start watching - just jump > to > the last watched channel. I find myself doing that even if I want to > watch something else, I then have to wait for the channel to lock and > start playing before I can switch to a different channel I actually > want > to watch. I hardly ever do that. > I think a better way to start watching would be to either to > select a programme you want to watch from a "currently showing" list > or > a list of channels like described above with the added shortcut "watch > the last watched channel". I think the 'proper' way to watch TV is to > watch a programme, not a channel :) But that may just be me, I know > the > approach differs. > > > > 4. Development Overview > > > The TV can be done in two ways (based on the discussion above). > > > Using MythTV backend as a service, getting the EPG data from that, > > > getting live tv stream from the backend, telling the backend to > > > change channels, and using the backend to record channels. > > That would, probably, be easier as the backend side of things is > complete. On the other hand Myth is recently getting a rehaul and we > can't be sure what will the future bring. One of my biggest complaints with them though has been how far apart their stable / devel branches get. Its years before then release. But, this means if you always target the stable release for your client, your pretty safe. It is definitely not a moving target. :) > The thing to notice here is > that there's completely no alternative UIs for MythTV anywhere. I > think > there's a reason. I think its because their UI is deceptively simple looking. Once you dig into trying to implement it elsewhere you find a lot of little, great features, that are hard to implement in whatever client your trying to bind to it. For example, commercial skip. I have it set on by default. It works 9 times out of 10. The 10th time, I can just hit back a couple of times or forward a couple of times and get past the issue. Or, I can hit 'E', bring up the commercial skip list editor and fix the issue, so next time I watch that recording its fixed. If I tell it to burn the show to a DVD, I can have it use that same cut list that I ensured was correct right in the client, and burn to the disk cropping out the commercials. If I'm watching a live stream, and the scheduler wants to use the tuner, it prompts me if I want to let the scheduler have it. If I don't respond in time, it just takes it. Or a big one, all the metadata related to a show. They way they order things, if you have 30 different episodes of the simpsons recorded, You can easily look through them, get a short/long description and find one you want to watch and ignore the ones you don't. I've seen very few media clients that do that well. > And again - have you ever tried talking to Myth devs? > I can't imagine having them talk to us about any feature we'd like to > extend MythTV with for our use. They are rather set in their ways, yes. But, I think thats partially because they have seen a lot of possible mythtv clients come along and say, "oh, it would be easy to just replace all of your gui stuff with ours, and ours is better". Experience has shown them differently. > I don't think a patch would get in, > even... I think they are rather receptive to good patches. If it really does add to the system instead of adding stuff their system will never use. > I'm also not sure about Gstreamer's ability to play / rewind > files saved by MythTV, my quick tests show that playing the file > directly or through a mythv:// URI does give me playback, but > rewinding > is only possible for files that have stopped recording. We'd need to fix up gstreamers codec then. Which would be harder, rewriting mythbackend from scratch, or fixing a slightly broken codec? :) Also, having this codec fixed helps for other reasons. No matter what, I still have lots of NUV encoded stuff laying around. > > > The other method is to use Gnome DVBD, this means providing our > own > > > code for TV streaming, interfacing with GDVBD's EPG or using an > > > outside source (preferable). Also this means writing our own code > > > for things like recording, schedules, expiration, ad skipping, and > > > possibly alot more. I think this is pretty hard to do well. It took Myth a long time to get all of that usable. > > The 'external source' EPG is planned for GDVBD, anyone planning to > write > a TV plugin based on GDVBD would definitely need to work inside it > with > Sebastian Pölsterl (sebp) but I think it'd be much easier to get in > this > code than MythTV's. Ad skipping is a feature I myself don't rely on > completely. It rarely works properly. Sure it's nice but completely > unreliable. Like I said, it works most of the time for me, and when it doesn't, the client is robust enough to let me easily handle it. > > >From discussions we already had on IRC the easiest way to integrate > with > GDVBD would be to use UPnP. We would need to extend the protocol but > that, according to Frank Scholz (d...@#elisa,#coherence), the core > developer behind Coherence, should not be too difficult. This sounds like a good idea to me. It would be nice for my PS3 as well. :) > > One BIG drawback of GDVBD is that AFAIK it's currently DVB-only, That makes it completely unusable for me at the moment. Thanks, Kevin > one big > pro is that it's completely gstreamer-based. Extending it beyond DVB > for > anything gstreamer provides shouldn't be too difficult. > > We should ask some container / format guru what's the best filetype to > keep files that should be accessible as soon as there is some data in > them and allow easy skipping. > > I'm glad we finally got a brainstorm about that going :) > > -- > Michał Sawicz <[email protected]> > >
