On Tue, 2009-06-30 at 15:41 -0700, Michał Sawicz wrote: <snip> > > 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.
True. I guess I'm just annoyed by having to press down when it first starts up to go from "live tv" to "recordings" all the time since I hardly ever use it. ;) > > 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. Hehe. Agreed. > > > 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: Since playback in 5 actually depends on 1 in myth the way its implemented now, I'd at least set that first. > > #5 > #1 > #2 > #4 > #8 + #7 is unbreakable I think I envisioned 7 as showing the EPG and letting you switch live tv to the selected channel. Scheduling using the EPG would be an extra feature in #8 > #6 > #3 Hehe. So your saying commercial skipping really doesn't work for you. :) > > > > 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. I think this is a different subject then what I was taking about. Probably a true statement though. > 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. That wouldn't be too hard to do. I'd give it a lowish priority though since when using the PVR it would hardly be used. > > > > 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. Thats one of the reasons I like putting it a little farther down in the list. Makes them think, why am I moving down the list all the time. Whats this default option its always on? > 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 kind of agree. One nice feature of the EPG is that it shows you whats coming up on a channel next. Say, if your a few minutes to the change, which thing is it better to show you? With the time/channel EPG you can see both and select a channel based on it. Maybe the best way would be a top layer list of categorizes which you assign a channel to, then once clicked, it pulls up an EPG channel/time grid based on just the channels in the group. You can then select one and it starts LiveTV on that channel. I think that feature should come after the basic EPG is written though. > > > 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. Totally agreed. I've been disappointed with their lack of abstraction myself. Do you know if the DLNA spec has support for PVR's yet? If it does, it might be interesting to wrap up MythBackend to support it. Then Moovida stays neutral, and it already has good upnp support. We just extend it to support upnp + pvr > 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. more then that, when myth was started, I think the performance aspect was rather critical. It had to be coded that way. Now a days, not so much. > > > > 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? I thought there were backend changes too. But I don't follow trunk too closely. > <snip> > 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. This is again the, is Moovida a Media Renderer or is it a PVR? If its a PVR, it should be integrated nicely like you say. This would be like Myth in that its hard to use one client to talk to multiple backends. Say I have Moovida with its own backend on a laptop and I bring it to your house.. It would be great if the Moovida on your tv could detect via UPNP the laptops existence, and play anything on it, seeing all metadata. You could then select a file and even have it copy to your local box with metadata in tact. If the PVR functionality was too tightly coupled, that might be difficult. I kind of think the PVR functionality should work like the UPNP code. You select a backend (or it picks the only one for you by default), then you can do stuff with it. > > I hope this will happen, yes. That's why we're talking MythTV and/or > GDVBD, not writing our own backend. So what we need then is a PVR plugin abstraction that is good enough that it can support both, and even better, both at the same time. I may have stuff in my old myth server for a while while setting up my new gdvbd server and want to run both concurrently for a while. Another reason I don't quite like merging menus with TV Shows/Movie > > > 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 ;) Fair enough. :) > > > 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've noticed this too. Its just another feature that the backend doesn't support yet. But, the myth backend is full of little features like this that you don't think are important until you try to rewrite mythbackend. :) > > 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 ;). Hehe. Thats a lot of 5-centses. But your helping me prove my point. Doing a backend of a PVR well is hard. Its way way more then just copying a stream of data from a card and putting it in a file. Does gdvbd do any of that well now? If not, its a ways out. In the mean time, I'll stick to myth backend. It mostly works pretty well. :) > 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'm worried from the opposite direction. If we try to rewrite mythbackend, we're going to get stuck in a worse smelly hole because we will have a lot less experience in how a pvr scheduler should really work. Other projects have tried and failed to create a PVR that worked better then Myth. Making it pluggable in Moovida using its great plugin mechanism and keeping it abstract as possible gives you the easy button to hit, provided there is anything else to jump to. Kevin > I think it's the most active and biggest thread on this mailing list. > Ever. > > -- > Michał Sawicz <[email protected]> > >
