--- "Brian J. Murrell" <[EMAIL PROTECTED]> escreveu: > On Tue, Mar 04, 2003 at 01:12:33AM -0500, Aubin Paul wrote: > 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. >
Press "d" (DISPLAY) when in movies menu. You'll have a preliminary Extended Menu. In near future, that will be the default and you will have more menu states: text-listing, icon-listing + view + info, icon-listing. And text-listing should not use the submenu (Prev/Next) anymore. > 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. > Sure. > > 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. > Great. > > 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. > IMHO we should have one "record daemon" and as many as tv-input "recorders". One "record daemon" should handle the already recorded programs, the program scores and choose the "recorder" to use. Each "recorder" should have it's own list of programs to record. And should return FALSE if the program that was gaved to record is in conflict. So the "record daemon" can try another "recorder". The record daemon should accept commands, like: add, del, list_programs (return the list of programs to be recorded), list_scores (return the program scores)... The "record daemon" should always be running, waiting for input. But how to deal with the "recorders"? Should it be a threaded program, one thread to wait for input (add/del/list program) and one thread to wait for the time to start recording the next program in the list? It's the best way, IMHO. > > 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). > I dunno nothing about how to cut off the commercial, but we can make this process and the reencode a low priority task (nice +20) so Linux scheduler will take care of this to us :) Gustavo _______________________________________________________________________ Busca Yahoo! O serviço de busca mais completo da Internet. O que você pensar o Yahoo! encontra. http://br.busca.yahoo.com/ ------------------------------------------------------- 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
