On Wed, Mar 05, 2003 at 07:55:05PM -0500, Brian J. Murrell wrote: > I have lots of experience at this part. I hope I can help, at least > with suggestions if not code. The latter will depend on my time.
That works for me :) > I must admit that I am still not using Freevo, but maybe that can > change soon. How are you using the UI to choose recorded television > program to watch? Are you just using the "Movies" menu? How do you > know that you are watching program episodes in the order they were > shown without any kind of date display or date sort on that menu? 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 > This really needs to be addressed, as well as the real-estate issue in > general. I have ony used the "default" skin, but I find that it > wastes too much screen space to "eye candy" and does not give enough > space to the business at hand... choosing media to play. It would be > nice if there were a no-nonesense, low-eye-candy-lots of well-used > real-estate skin. Oh, with a scrollable media chooser. Next/Prev > page just sucks. 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 on the left. In my hacked MP3 player, the cover image shows the album title, year and total track length under the cover. > I have that written already, albeit in `C', for efficiency. If I get > time (not hopeful) I might try re-writing it in Python just to test > out my python skills. :-) Shouldn't be too bad; Python isn't usually slower than C in my experience, at least not in this type of application. > And what happens if that adding causes conflicts? That is what my > scheduler deals with. 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. The only thing I need to do to get that to work is to add that info to the record file. > You need scoring for programs to help resolve conflicts in a way that > you get what you want recorded and some heuristics to try and do the > right thing. For instance, it has been my experience that programs > that have episode titles normally, do not have them when the episode > is a repeat. You want to decrease a programs score in that instance. Hmm... that might work, though in fairness, I'm not recording that much yet so conflicts haven't happened yet. 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. > You also want to track what you have recorded, again for optimal > conflict resolution. For instance, you do not want to record an > episode of a program you have already seen at the expense of another > show who's episode you have not seen. Scoring would probably help that; I would imagine that the "Season Pass" 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. > Conflict resolution _can_ be processor intensive. If you have a lot > of programs in your "wanted" list, you will wind up with a large > matrix of conflicts that you have to resolve by brute force. My > experience (with my recording schedule) is that this is not an issue. > It was in one of my early implementations but I found an optimization > that reduced searches by many orders of magnitude. 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. > I will want one for lavrec, but that should be quite easy. Your > encoder plugin model is like the "record" script from my OpenPVR > project. Should be easy enough; just write a small python script and set a variable. > Not watching live TV rules! 'Specially so when you take a couple of > minutes before watching to remove all commercials. Then you sit and > watch a whole program without having to touch the remote. I haven't done that, but mostly, hitting the 60 second fast forward handles most of the commercials. 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. > It all revolves around a scheduling daemon. The daemon accepts inputs > of several varieties. It will of course take a list of programs by > name, but also by recurring date/time (I usually refer to this as > "timeslot" programming and avoid it at all costs because it's > unreliable) or simply by a one-time date/time specification. Right. > The daemon re-evaluates the recording schedule after every input > change and always has a chronological list of what's going to be > recorded for as far out as it has information. If you have 2 weeks of > XMLTV data, your scheduler will know what it's going to record for the > next 2 weeks. 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. > Of course, what is going to record could change at any time due to new > input (manual or XMLTV fed). Indeed, I would give it a whole new 2 > week XMLTV schedule every day, to keep up with the programming changes > that happen on North American television networks on a daily basis. 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. > But even entering a one-time programming request (with score) could > change the schedule as a conflict resolution is performed after every > input. Right now, we run the "daemon" every minute; but it could be done as a detached process. > The scheduling daemon is responsible for farming out recording jobs to > one or more recording daemons on one or more (local and/or remote) > recording hosts. For instance, here in my setup, I have my actual PVR > with a MJPEG capture/compression card in it as well as a bttv card. I > also have a bttv card in my workstation. So my setup would run 3 > recording daemons, two on the main PVR and on on my workstation. I > tend to record first on my MJPEG card and then on my workstation if > the MJPEG card is busy. I don't have enough CPU in the PVR to fire up > a third recording if I want to watch at the same time so I avoid it, > but I do find every now and then that I want to watch 3 things all on > at the same time. I didn't even think that would be possible, because of motherboard bandwidth. > Recording daemons are responsible for accepting recording jobs and > firing off recorder/encoder programs, with their required parameters. > They should always be listening for new jobs, even while busy with > recording, so that they can "chain" the recording of programs one > after the other. But when chaining they need to ensure that one > recording process is complete before another starts. 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. Also, I had the timer record one second less (i.e. record 29:59 rather than 30:00) so back to back records work. > I tried the latter once and found that every now and then, cleanup of > a recording seesion would lag for just enough time to make the next > recording overlap and find a device busy. 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. > For this reason, a recording daemon needs to ensure one recording > process is done before trying to start another. Done :) > The recording daemon also needs to allow removal of a previously > submitted job by the scheduling daemon due to last minute changes in > the schedule. Imagine a job is ready to go in recording dameon "0" at > 10:00pm, but at 9:58pm the user makes a recording change that bumps > the 10:00pm job. Waiting to the last moment to submit jobs to the > recording daemon can alleviate the need to recall jobs, but it can > also result in a mis-timing of a recording. The later you wait to > submit jobs, the lower the probability of a race, but it will always > exist and should be dealt with. Being able to remove a job from a > recording daemon would allow the race to be dealt with. Right now, it goes first-in, first out, but it could easy be switched by reading from the bottom, up. > There is a need for post-processing of recordings, for instance to > automatically remove commercials, or to transcode to another format, > but I have not given dealing with that in this framework much though. > Currently I do this part manually. I would like an auto commercial > removal process but have not had time to write one yet (based on MJPEG > capture files). It shouldn't be difficult, just have the daemon wait for the recording to finish, and run a command afterwards, also detached. Aubin ------------------------------------------------------- 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
