Re: [Freevo-devel] Recording TV
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
Re: [Freevo-devel] Recording TV
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.
Re: [Freevo-devel] Recording TV
--- 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)
Re: [Freevo-devel] Recording TV
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
