On Tue, Mar 04, 2003 at 01:12:33AM -0500, Aubin Paul wrote: > I've got a few moments to think about the recording interface, and > this is what I've come up with. A few slight modifications to the > recording system may be helpful.
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. 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? 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. But I digress... > 3. The last thing I'd like to see is a auto-scheduler based on program > names. 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. :-) > What would happen ideally is that when the epg_xmltv.py is > processing the guide (something I do at 3am) it looks for certain > programme names in a file, and adds them to the record list. And what happens if that adding causes conflicts? That is what my scheduler deals with. > A programme list file or "Season Pass" would look something like a > file with line by line shows, when epg_xmltv.py runs, it would compare > this list to the processed guide, and auto-schedule the favourites. 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. > We'd add a line to the Record parameters menu called "Record all (Show > name)" and then add that to a list, and use the pickled guide to add > the days worth of stuff. 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. > This should be dead simple to add and if you process your guide in the > middle of the night, almost invisible to the user. 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. > I've started the plugin stuff for the different encoders, I have mp1e > working now, but I want to make sure we have one for mencoder before I > commit anything. 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. > Last of all, let me just recommend the recording stuff to anyone who > hasn't tried it. I don't think I've watched live television in a week! 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 have been thinking about recording architure design a bit. I used to think at and at jobs were sufficient to manage recording but I have since changed my mind. This is my idea of a recording framework: 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. 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. 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. But even entering a one-time programming request (with score) could change the schedule as a conflict resolution is performed after every input. 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. 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. To expand on this a bit, let me explain what can go wrong. In my current scheduler, it was always designed to submit a single at job for a series of back to back recordings in such a fashion: at 9:00pm <<EOF record "program 1" "60 minutes"; record "program 2" "30 minutes"; record "program 3" "90 minutes" EOF rather than submitting 3 at jobs such as: at 9:00pm <<EOF record "program 1" "60 minutes" EOF at 10:00pm <<EOF record "program 2" "30 minutes" EOF at 10:30pm <<EOF record "program 3" "90 minutes" EOF 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. For this reason, a recording daemon needs to ensure one recording process is done before trying to start another. 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. 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). Thots? b. -- Brian J. Murrell
pgp00000.pgp
Description: PGP signature
