On Thu, Mar 06, 2003 at 12:03:17PM -0500, Brian J. Murrell wrote: > Yes, that would work. But the waste of screen-space on the right must > truncate the names somewhat. IMHO, the picklist should use the full > width of the screen and forget the eye-candy.
Perhaps; of course, you're talking to the guy who has been in favour of eye candy :) But this is configurable without editing code. If you want no covers, and full width titles, you disable 'movie' covers and set the menu width to whatever width you want. I like the cover image, not just for a picture, but also for showing extended information. Like, if I get the daemon outputing xml files with the show title, description, etc. it would be nice to browse and see it. > That spot on the right for "icons" might work alright for MP3s with > putting an album cover there or something, but do you really need to > see an icon for a recorded television program? That space should be > given to the date/time/program/episide-title information. Not really, but I don't want to dictate what other people use... I've worked on my skin with the intention of it being pretty, simply because it's in my living room. But I've done some things to improve real estate and sacrifice cosmetics by getting rid of the 'back/prev' buttons on the bottom for example. > Yes. Do you really need a cover image for a television program? You > are sacrificing being able to see details about an episode just to see > a picture of what? A single frame in the episode? Surely using that > space to give more textual information is of more use. I would, but I want to use it for more textual information that the filename might allow; like episode name, summary, etc. Someone at xmltv is working on a tv_imdb thing to cross reference the xmltv listings with the extra information from imdb, so the two could be used in concert. > Yes. For MP3 player that is fine. But for television programs, what > could you put in the "cover image" that would be of any real use in > conveying information about the episode? Image is the wrong word; think of it more as 'extra information', a cover is just one possibility. > A brute force search where you have thousands or tens of thousands of > loop iterations and comparison operations? I doubt Python will be any > better at it than Perl was. C is orders of magnitude faster at it > than Perl was. In any case, lots of iterations has not been needed > for my small list of choices, so Python would probably work. But > somebody out there is going to have a lot of choices and complain that > the process is too slow and processor intensive. I'd be happy to try wrapping your code in Python, it's not too difficult, and it's mainly your optimized loop that needs to be in C, correct? File opening and closing, parsing should be easier in Python and then put the optimized loop in C. > Just cancel it? It won't try to find the same program/episode on at > another time? This is the entire point of the scheduler. It finds > repeated episodes and uses them to work out the best schedule of > recording such that the user gets as much as they can. This is also > why time-slot based recording totally sucks. If you record based on > name, you can let a process find the best time to record it. That's true. and of course, since none of this is past meatspace at this time, we could be more clever in how we do it. Nothing is written yet, and we certainly aren't locked in any corners. > Well, scoring along with taking advantage of repeating episodes is the > way to do it. That might work, but because of the somewhat sparse information on one channel versus say, a proper detail on another, it's hard to tell sometimes. Like, I like watching the simpsons and there are at least 6 different episodes here. One channel provides an episode title, summary, etc. another only says "Homer and Marge take care of their kids" or something. How do we deal with those? For that matter, it's easy for me to read that and see it's a general summary, but how do I know it's not a specific one? > I don't see how. If you keep track of programs that you have > seen/recorded before, their score is automatically nil due to the fact > that you aren't going to even consider the need to record it again. > Scoring really has nothing to do with not recording previously > recorded programs. Ok. > What is a "Season Pass list"? It's a term I picked up from the Tivo; a season pass is just a general flag on the Tivo that says "record all of this show" > Kinda like that. Basically for every conflict that involves an > episode that has a repeat showing you have double the number of _possible_ > schedules. You double for every occurance of that. You can see why, > when using powers of 2 the number of tests you have to do can grow > quite quickly. You go through each possible schedule, adding up the > scores of the programs that would be recorded in that schedule and > choose the one that yeilds the highest score. That makes sense. > I do that when I watch mp1e recorded programs (and it's less annoying > that watching commercials, but still annoying), but when I watch stuff > I recorded with MJPEG, I have to transcode to MPEG4 anyway, so before > I transcode, I edit out the commercials. Nice for watching and not > wasting encoding bits on commercials yeilds a much higher picture > quality for the same bandwidth as mp1e. Commercials are usually about > 1/3 of the showing time (i.e. 10 in 30 minutes and 20 in 60 minutes) > so it is significant. I never keep anything, so that's probably why it hasn't come up, but I imagine it would... > You don't want to just set breaks. You want to record the first pass > (from live) at a high bitrate, then edit out the commercials then > transcode to a lower, "longer term storage" bitrate (in my case, it's > 5GB/h first pass and 1GB/h for longer term storage without > commercials). No, no, I understand you. We set the breaks and pass them to transcode or whatever, and say "record 01:30.5 to 05:40.7" and do it for each chunk and glue them together, either within transcode, or manually if they're mpegs. > It does mean a lag in when you can watch something from the time it is > shown, but once you have been watching recorded shows on the PVR for a > while, and you have a 1 or 2 week cache of programs, you will lose > track of what is on when and the need to nail yourself to your couch > at 8:00pm (8:15 actually so that you can skip commercials :-) on > Thursday waiting for Survivor. I agree; it's nice to basically never have to worry about when something is on. > What do you do now? You can simply drop the 3am schedule 8:00pm > program for the one the user put in manually, but it was the Survivor > Season Finale! The user is not going to be too happy about that. > No fear however, it is being again at 11:00pm the same night. But > the scheduler will not run until 3am, so it'll be to late to get even > the second showing into the schedule and the user didn't know it was > repeated at 11:00pm so the Season Finale was missed. :-( Hmm... the only problem is that on slower machines, if the user inputs something and we have to recalculate the guide, it'll hit a wall, and probably not have enough power to compress video... I suppose we could just store the total scores of the guides and then if someone asks to record something else, we compare the scores using the totals and then search for the show with the lower one. > The scheduling daemon should be a daemon. It should never go away. > It should wake up and generate a new schedule when new input is > received, but otherwise sleep until it needs to dispatch the next > recording event or it recieves a new input event, or it needs to fetch > external data. That's doable... > MJPEG is a series of JPEG images. Compressed on the hardware. I have > it doing about 5GB/h right now. But even if I were using just bttv > and receiving uncompressed video data, I have heard you can run as > many as 3 bttv cards in a decent mobo. I don't have the CPU to do > MJPEG, 1 bttv (and encode it) and play at the same time, so I have not > tested it, but recording 1 MJPEG and 1 bttv and encoding with mp1e > works just fine. Hmm... it hasn't really come up that often, but I know some people will be happy to hear that multiple video inputs is possible. > So a recording job waits for the previous one to finish before it > starts, (observing the lock) even if it takes (to use a wildly > extreme) 10 extra seconds at the end of the first job? Or does the > second job just fail noting that the first one was not done with the > lock? Now, it just fails. But we could easily just say, try again in a minute. We're just not doing that now :) > Is that 10 seconds accounted for in the recording time of the second > job (i.e. it still ends when it was supposed to end or does it end 10 > seconds late too)? Wouldn't be hard to change that either, we can easily adjust if we know we're starting a minute late. > Yes, I do that too, but I have still found one job trying to start > before the previous one was finished. > > The lock file approach should work, as long as the time spent waiting > for the lock is accounted for in the recording time. Hmm... my 'lock' is just a file I touch before recording and delete after, so it's pretty much dependent on how fast we poll for it, rather than the lock file itself. > With mp1e 1 second might be fine. With other encoders it might not > be. Using the 1 second is error-prone. Chaining jobs or using a lock > file is not. Agreed; but the daemon would be a definite necessity, because the minimum time resolution of cron is a minute as far as I can tell. ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com _______________________________________________ Freevo-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-devel
