Dnia 2009-07-02, czw o godzinie 00:22 +0200, [email protected] pisze: > On Wed, 01 Jul 2009 19:05:24 +0200, Michał Sawicz <[email protected]> wrote: > > Dnia 2009-07-01, śro o godzinie 13:08 +0200, David McLeod pisze: --8<-- > > Volunteers? > > > Some organised and passionate developer must exist? :p
The first requirement shots /me off... --8<-- > > Now & Next FTW!! :] > > > > YEah I am kind fo fond of its simplicity too in a way. Maybe in v2 we add > search support so we can set a recording for a show that is like... 12 days > away like TiVo does it? Now and next guide is very much 'in the present'. I'm starting to wonder if the Channel vs Time EPG is at all needed... --8<-- > Yeah, station artwork. A good first source (no API) but showing it as a kind > of...marker in terms of quality is this site: > http://www.brandsoftheworld.com/search/97093716/12854.html They pull a lot of > the vectorised artwork from well known companies around the world. Nice, I even found some polish channels' logos there. > So, what I am talking about it, people with some slight design sense being > able to take that... put the logo on a square colored background at a high > resolution and then... uploading the artwork to a small Fluendo managed > database (because we can take the server hit)of station logo content. Again, not me :/ > But, you know, just an idea... sounds easier than it is. We can get away with > artwork that is 99px square at least. Just means for the 'Info Screens' we > need to be clever. Maybe a still from some jingle could be used after some retouching work. > Yes, good, glad someone else see this and thinks like this as well. Also, > consider TVRage.com. > But, factor in that, sometimes... shows exist that aren't on something like > TVDB like, the Iron Chef or Dr. Phill (Im naming bad TV :p). So, wonder what > we can do there? Google image search based on certain parameters? Dangerous... --8<-- > I say, dont give the user choices :). This was my point actually even though > I knew I couldn't describe it well with my non techy, no opposable thumb > weilding brain :p. > > If the user can do something like 'pause LiveTV' then it should always be > availble. So, in my brain that meant making sure we set aside one tuner > purely so that we never have to 'remove a feature' like pausing live TV, if > only temporarily. (you break trust and consistency with the user... never > good). That simply wouldn't work for me - I only have one tuner ATM ;) And I rather have it record things I did set schedules for than watch something unimportant. Having a tuner sitting and waiting is really wasting it. I probably could go with recordings 'escaping' LiveTV whenever Live is requested (rescheduling the recording at hand). --8<-- > > There's a third option when the scheduler gets cleverer - the scheduler > > could check if the currently recording show is on at a later date and > > reschedule it if that's what the user wants. > > Ah, yes... check for it at a later date... good thinking :). I highlght the > whole clash of schedules thing. > I trust you understand I am only opening the door to it as a reminder to keep > sanity checks on things like that. Believe me working with MythTV is all about scheduling, you should really try and have a look at it :) --8<-- > > That's only if the scheduler is stoopid ;) I agree with Kevin that the > > scheduler Myth has is a powerful beast - on the other hand, it's a bit > > bloated. I think even the most basic scheduler should use content, not > > channel+time to schedule recordings. Just as in LiveTV - you rarely want > > to record channel X from Y to Z. You want show A to be recorded. The > > scheduler should then find the show and try to record as soon as > > possible with as much efficiency in regard of tuners as possible (if two > > shows are to be recorded at the same time from the same multiplex - only > > use one tuner). And now there's a question - if a show is available to > > be recorded today and then again tomorrow, but recording it today would > > use all available tuners while tomorrow it would not - should it record > > today or tomorrow? > > Tomorrow, but as long as you inform the user. "Cant do this now... can record > it tomorrow at blah blah blah... Yes/No?" Yeah I rather meant scheduling without user input (like Season Pass for example). Anyway that decision isn't important now. --8<-- Nice you switched to plain text already :D I see you're using Roundcube, too - one great piece of webmail :) -- Michał Sawicz <[email protected]>
