On Thu, Mar 06, 2003 at 09:57:01AM -0500, Aubin Paul wrote: > > I have a folder under "Watch Movies" called 'Recording' and it > contains the files that are recorded. The files are tagged by date and > time, and then by show name and title. Like this: > > 03-02 9:00pm - The Simpsons - "Treehouse of Horror XI" > 03-03 9:30pm - The Daily Show with John Stewart
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. 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. > I'm not sure what space is wasted. On my screen I have an info bar on > the top, a vertical menu on the right 2/3 of the screen and room for > cover images 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. > on the left. In my hacked MP3 player, the cover image > shows the album title, year and total track length under the cover. 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? > Shouldn't be too bad; Python isn't usually slower than C in my > experience, at least not in this type of application. 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. > What /will/ happen is that scheduled shows (since they're processed in > advance) will be highlighted in red in the TV guide, and if you want > to record at that time, it'll cancel the scheduled record. 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. > Hmm... that might work, though in fairness, I'm not recording that > much yet so conflicts haven't happened yet. You will and they will. > The current model doesn't > handle conflicts at all, but it's not impossible to do 1:1 conflicts. > I'm not sure how to handle multiple conflicts without a logic like > scoring. Well, scoring along with taking advantage of repeating episodes is the way to do it. > Scoring would probably help that; 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. > I would imagine that the "Season > Pass" What is a "Season Pass list"? > list would have scores, I'm not sure how to add them to the main > recording menu without making it overly complex. I suppose we could > set a default of, say, one below high priority. Yes, programs have a default score. As the user is notified of un-automatically-resolvable conflicts, he should be given the opportunity to alter the score of one or more of the programs involved in the conflict so that it records what he wants this time and in the future. > That I'd be interested in; because it sounds like the only way I would do > it is to sort an array of shows by priority and pick the highest one. 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. > I haven't done that, but mostly, hitting the 60 second fast forward > handles most of the commercials. 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 don't know if I could watch shows > and manually set commercial breaks, though, hypothetically, there is > no reason it would be difficult, since we intercept the remote before > it's passed to mplayer, and we could just split based on those breaks. 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). 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. If you happen to be sitting down at 8:00pm on Thursday you watch something else that's on the PVR from that 2 week cache of programs and watch Survivor when it's ready to go. Not being a slave to the TV guide and the scheduling whims of the networks really is a breath of freedom. > That sounds right; in my model, any non-one off recordings would be > scheduled at 3am, so I don't have to do it while I'm actually using > the machine. Yeah, but it's 4:00pm and the user has input a one-time, time-slot recording for 8:00pm that evening. But you scheduled something to record at 8:00pm during your 3am run. 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. :-( You see, after any change to the schedule (either manual or XMLTV driven), the full scheduler needs to be run again to take advantage of repeated programming. Waiting until 3am could result in missing something. The ripple effects of making a single change between sheduler runs could be extensive and could change the schedule quite a bit. > I generally update once per night, but I don't trust zap2it to handle > multiple days without erroring out and causing XMLTV not to write the > close tags. I never have that happen. Sure zap2it has problems, but I either get a full XMLTV file or nothing. The scheduling daemon would be responsible for going and getting new XMLTV data (at intervals, not at specific times -- i.e. every 24 hours), and when it is successuful, uses the new data to generate the latest schedule. If it's not successful at a given interval due to zap2it errors or whatever it just keesp it's schedule and tries again later (say, in 2 hours). > Right now, we run the "daemon" every minute; but it could be done as a > detached process. 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. > I didn't even think that would be possible, because of motherboard > bandwidth. 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. > Well, the current method does work that way, even if somewhat > unintentially. The cron-ed script which runs does run the recordings > detached, and I put a lock file in so it does prevent one recording > from recording another. 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? 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)? > Also, I had the timer record one second less (i.e. record 29:59 rather > than 30:00) so back to back records work. 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... that hasn't happened to me since I started giving it the one > second which seems to be enough to close the mpeg, change the channel > and start a new one. You could probably reduce that 1 second to 0.10 > seconds even, if your machine is faster. 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. b. -- Brian J. Murrell
pgp00000.pgp
Description: PGP signature
