Dnia 2009-06-30, wto o godzinie 14:31 -0700, Kevin Fox pisze: > On Tue, 2009-06-30 at 11:21 -0700, Michał Sawicz wrote: > > Dnia 2009-06-30, wto o godzinie 10:57 -0700, Kevin Fox pisze: > > > 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: > > > > Yeah me too, mostly. Only recently my hw got dodgy on me and does > not > > record most of my schedules correctly. > > That sucks. :/ But, if we're implementing this a piece at a time, most > useful stuff first, which is better? Implementing a feature most > useful > to those with broken hardware, or fixing your hardware? (not trying to > be mean about it)
Well I'm not trying to say that changes anything. I just remember how it was in the beginning - I mostly used LiveTV back then. And I know we can't get users to change their attitude this fast. You need some time to set up schedules to have enough recordings. > Would you still have that usage behavior if your hardware was working > correctly? Actually yes, I often have something unimportant playing in the background. On the other hand I think that's because Myth's music experience sucks ass... And I'd rather have music playing in the background than something unimportant in tv. > I'd order features in priority: > #1. simple list and play already recorded stuff in backend > #2. Proper jumping back and forwards. > #3. Cut list support. Either with skip button or automatic. > #4. recorded stuff metadata. Long descriptions, etc. > #5. Live TV playback / Channel changing > #6. Live TV playback integration with schedular. Ask if ok to record, > etc. > #7. Basic EPG. Standard channel+time grid. > #8. Setting up myth recording scheduals. > > While I think recording scheduals is important, its not done very > often, > and it can be handled with mythweb until its implemented. > > What do you think? I'm trying not to stick to mythtv ;) and would reorder like so: #5 #1 #2 #4 #8 + #7 is unbreakable I think #6 #3 > > Still, most users that start with PVRs don't get it from start so we > > need to allow that, too. > > Ah, the backwards compatibility argument. Ok. I'll remind you of this > below. :) > > So if it is not the main way its expected to be used, only a > transitional step, why not have the traditional EPG, time/channel > view. > Its easy to implement and then when the user wants more, they can > learn > to use the PVR in the more natural way of having it manage the > recording? I think it actually is the main way, only 'power users' will have separate frontend/backend that will record their shows. The first basic approach is to just start watching TV and later worry about other things. > > That's why I wanted it to be completely user-defined. You want it > this > > way? Good, have it your way. > > So your arguing for the layout should be generated by a plugin? Then > the > user can switch as needed? No, I think the layout should be completely user-defined (with some well-thought defaults). Instead of a channel list like we have now - a channel tree. You can create groups / subgroups and add any channel available to any number of these groups. > > > I hardly ever do that. > > > > I still do, sometimes. > > Is this the default most users will use? It should be a menu item for > sure, but should it be prominent, or further down in the list? I think yes it will be the default for first timers. One thing we could make them do is actually think about what they want to watch prior to tuning to any channel. A list (or a tree as mentioned above) of "currently on air" content instead of a list of channels or full fledged EPG. > > I may be biased, but that's just because I'm left with using Myth > even > > when I don't like it. > > I'm kind of in the same boat. It has its issues. I've been looking for > a > good replacement for a couple of years. I'm still using it because I > haven't found anything better. And, because its a hard problem to > solve, > I don't see anything else thats close yet. If we want something better > then what we have now, and soon, we should enhance Moovida to support > myth backend, eliminating the need for the front end. That gets us a > step in the right direction. Yeah I'm keen to agree on that. We should, though, try to abstract the MythTV connection wherever possible to be replaced simply by another backend when one's available. That's one more flaws of Myth - the disconnection of back-/front-end is so tightly connected it hurts. I know, it was the easiest and most efficient way to go. > > Most of the ideas they have are great, but IMO > > Myth is so big a lump it needs a rewrite. > > Its getting a lot of that currently. At their release rate though, it > could be another year out. It's mostly porting to Qt4 and MythUI, right? > Moovida can be the client rewrite. Something else can be the backend > rewrite. Using the myth backend, we can get all the client UI done and > working while someone else writes a different backend. > > > And that's what Moovida's here > > for ;P > > Moovida is currently kind of different beast then Myth. Either it can > complement or compete. Myth already has a big head start there. It is different, of course, but that's our advantage :) > > Yeah I sometimes have problems with that, it sometimes does not ask > > and > > hangs the frontend. And where's the 'Record and watch as it records' > > option > > gone? > > Not sure. Mine has it (last time I checked. A long time ago). I > haven't > updated the client in a while. > > Never the less, its a useful feature and Moovida should have it. I think it was gone with the multirec feature. Don't really know why. > > Grouping by series / season name is something we already have and as > > discussed earlier, we could easily integrate it with current TV Show > > menus. > > Hmm. Just played around with the TV stuff in Movida a bit. Its come a > long way since I tried it last. Yeah, I don't think it would be too > bad. > > If we wanted to use it in a plugin, can we subclass it? > > The layout is a little different then I'd like to see but thats more > of > a theming thing. Subclass? I don't think that's needed, we could just feed it up with additional content where it's applicable. No need for a 'TV Shows from TV' and another 'TV Shows from hard disk' sections. > > We can learn from them, simplify and improve even further. One of > the > > most important features of Moovida is simplicity. > > I guess the heart of the matter is, what is Moovida trying to > accomplish? Is it going to be a consumer of media which it is now, > which > may include a PVR client (or clients) in the future, or is it going to > be its own, all in one, PVR solution that doesn't work with other > PVR's? > I'd like to see Moovida be PVR agnostic. Just provide enough hooks to > integrate with the various PVR's. I hope this will happen, yes. That's why we're talking MythTV and/or GDVBD, not writing our own backend. > I said before, I'd remind you. ;) A lot of stuff is currently in Myth. > If we are going to be backwards compatible with what people are using, > Myth should be supported. Probably so. I'm still not sure I want to agree it's the most important one ;) > Also from a time standpoint, if Moovida is going to have PVR > capabilities any time soon, it would be good to start with a working > PVR > solution and if needed then work to replace it, in the mean time > reaping > the benefits of having a PVR solution. Right now, I can't use Moovida > much because it doesn't provide PVR. Yes, I know. I know. I know... There's one more thing I forgot to mention that bugs me. That's, of course, LiveTV related again. Myth lacks the ability to 'reuse' recorded data when it comes to LiveTV. Even if the same show you've just turned on is being recorded or watched by someone else, it fires up another tuner to record it separately for each of the frontends. Not a big issue but a significant one when you have _almost_ enough tuners :) I don't have enough knowledge of the NUV format to know if the timestamps there are universal nor if it's possible to put metadata in it as you asked earlier, but I think the above should be doable. When I thought about it some time ago I was close to setting my mind on how data coming from the sky should be handled. The only two unique things needed to identify content are channel and time. Anything else can / should be derived from the EPG data (sky based or external). The storage itself should never contain two copies of the same data (channel / time pair). Some 'storage manager' would be asked by the... something-else manager for this data using only this pair of arguments. I don't know how to explain this, really, but the end goal I have in mind is this: There are HD channels which broadcast exactly the same content their SD equivalents do. No need to have 'Something' and 'Something HD' in your channel list. You can have the same channel from different sources (satellite, terrestial) or even different providers. No need to have the channel X times in your channel list. Channels that provide the same data should be grouped in one 'content provider'. The recording scheduler would then record data from any available source, usually best available quality unless requested otherwise by the user (input priority). Most of the content providers will usually have one channel under them but that would be just a special case. Ideally (that's just a bit distant ATM, but still... there are usecases for that) the groups could be time-based. There are channels which are X from 6a.m-8p.m. and then they become Y the remaining time. All's theoretically fine but when you have EPG data separate for these two, in mythtv you then need to decide on one of them or hack the channel table to have two channels with the same tuning data but different xmltv ids. Another usecase - regional schedules. A channel is X but every day it becomes Y in terrestial and Z from satellite. All xmltv data is separate for each channel... Again, a pain in the ass and could be handled if designed properly. This would also allow to only show content providers which are currently showing something - most of the channels have mostly static start / end hours belong which they broadcast fireplaces, fishtanks and such... No need to have that garbage in the UI. That's about it, I'm running out of 5-centses ;). I'm not completely against MythTV, I just want us not to fall in the same deep, dark and smelly hole they've fell into. We need a fast-release button somewhere so they won't drag us in. I think it's the most active and biggest thread on this mailing list. Ever. -- Michał Sawicz <[email protected]>
