Re: [Freevo-devel] Features & Ideas
Hi! On Friday 12 November 2004 17:48, Hans Meine wrote: > Cool. Does that work on X11, too? I'd be interested in trying that one.. > ;-) Vice runs on X11, too, of course. I only added SDL support to VICE to be able to use it on fbdev. I will cleanup things in the freevo plugin a little bit and then post it here. > Together with optional capturing for visualization, that seems to be a > sound idea to me! If I find the time I will definitely write that wrapper. It should be fairly easy. Using ALSA loopback capturing for visualization is also a general solution to other (audio) players in freevo and could run in parallel (think of the detach audio mode). > This is the main reason for me to post this; encouraged by your comments on > 2.6.9 I investigated hibernate-support on my machine again (did that for > 2.6.7 not long ago). Indeed, I was happy to get most stuff work. Pitfalls I > saw: Good to see that I motivated others to test 2.6.9. For ACPI junkies like me it is first choice. > - When suspending (using the hibernate script), my infrared remote stops > working (which again makes the whole suspend stuff useless for me for now). > I tried stopping lircd and removing lirc_i2c, but that was not enough; I > obviously have to unload ivtv, too. I also had to do that, but I think we can live with that as loading/unloading some problematic modules does no take too long. At least not as long as booting the whole machine and working through tons of init.d scripts. > However, I would have to stop Freevo > in order to do so, since Freevo leaves several FDs open attached > to /dev/video/0. I hope this can be patched in Freevo and I want to have a > look at that later. > > Or did you shutdown Freevo, then suspend? Freevo shuts down within a second and starts within 5 seconds if you put XINE_VERSION and FBXINE_VERSION into /etc/freevo/local_conf.py (and 10 seconds without; btw, why is that not mentioned in the FAQ or elsewhere, I had to look into the code to find that trick). Therefore, I simply stop it before suspend and start it after a resume. My scripts also load/unload some modules. I had to do that because they did not reinitialize themself on resume. However, with earlier kernel versions resume crashed the whole system every second time. Cheers, Stephan Kanthak --- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 ___ Freevo-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-devel
Re: [Freevo-devel] Features & Ideas
Hi Stephan! You certainly did some interesting work; it would be cool to get some of these things polished and integrated.. On Monday 08 November 2004 20:33, Stephan Kanthak wrote: > - I have a working version of a VICE/C64 games plugin. It can use the > autostart feature from vice to actually start games from D64 files. Cool. Does that work on X11, too? I'd be interested in trying that one.. ;-) > [comment on CD audio playing] > titles. Why not write a wrapper around the commandline cdtools? They Together with optional capturing for visualization, that seems to be a sound idea to me! > - I would like to bind lirc events directly to the actions from context > menus (key E). Most of the event system is a mystery to me; I would be very glad if I could bind more of my IR keys to "global" actions. (However, I am still running the stable branch, things are supposed to be better in HEAD AFAIR.) > - Better support for suspend-to-ram/resume-from-ram. I use some > self-written scripts that would be of interest to others. This is the main reason for me to post this; encouraged by your comments on 2.6.9 I investigated hibernate-support on my machine again (did that for 2.6.7 not long ago). Indeed, I was happy to get most stuff work. Pitfalls I saw: - With the swsup2 patches, ivtv did not compile/work anymore: the create_workqueue macro needs an additional argument. I just padded the three calls in ivtv-driver.c with additional 0s as last arguments. - When suspending (using the hibernate script), my infrared remote stops working (which again makes the whole suspend stuff useless for me for now). I tried stopping lircd and removing lirc_i2c, but that was not enough; I obviously have to unload ivtv, too. However, I would have to stop Freevo in order to do so, since Freevo leaves several FDs open attached to /dev/video/0. I hope this can be patched in Freevo and I want to have a look at that later. Or did you shutdown Freevo, then suspend? Ciao, / / /--/ / / ANS --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click ___ Freevo-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-devel
Re: [Freevo-devel] recordserver status, vdr integration and live tv
(repost, was wrong sending adress..) On Friday 12 November 2004 11:02, Dirk Meyer wrote: > Now to live tv. If you start live tv, the recordserver _must_ know > about this. If you have two dvb-t cards and use one for live tv, the > recordserver has to know that one card doesn't work anymore. For dvb > or ivtv, maybe the best solution would be to record the live tv and > watch it with a player. One file or a ringbuffer, both should be > possible. Things brings the whole how-to-do-timeshifting-right discussion to my mind again.. Obviously, timeshifting is done with some kind of "ringbuffer". However, this term usually refers to sth. with a constant size, and I prefer something more dynamic, a container which contains a contiguous range from a live stream, but which can dynamically decide to grow, or to overwrite old parts again. This solves the following use cases: - Watching live TV, with pausing (buffer will potentially grow), and skipping e.g. commercials. - Rewind / Slow-Mo up to some point depending on the maximum size of the buffer. - Deciding that the current program is worth a recording (if the buffer still contains the whole movie from the beginning, it could be told not to throw away anything, but just save that as a recording). With ivtv (which I am using) or dvb, this should be possible, and maybe easier to implement with a buffer in the recordserver, but I leave that decision up to you. AFAICS the pros and cons would be: + the recordserver could manage "busy" vs. available devices on its own + changing the timeshifting buffer into a recording would be easier, too - the information path from the timeshifting buffer to the modified mplayer with the information on which part of the file to play (where the ringbuffer starts/ends) becomes longer(?) Analog (non-ivtv) TV people might want to have a separate TV mode which does not do any encoding / recording (thus would not allow timeshifting). In that case, the recordserver would have to be told that the device is busy (as you said), and the recordserver would need to have the possibility to inform the user that a recording cannot happen if he/she does not leave TV mode within the next x minutes. Ciao, / / /--/ / / ANS --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click ___ Freevo-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-devel
[Freevo-devel] Wierd main loop issue on 1.5.2, vdr-xine, pysvdrp..
Not sure what is going on. But when watching vdr through xine, i'm getting a 'stuck loop' in main.py. What makes me say this? I loose control... Freevo is 'stuck', if I run irw from ssh I can see that lirc is seeing my remote key presses, but freevo is not listening.. top - 00:04:30 up 3:06, 1 user, load average: 3.27, 2.75, 2.55 Tasks: 70 total, 3 running, 67 sleeping, 0 stopped, 0 zombie Cpu(s): 43.2% us, 7.8% sy, 48.1% ni, 0.0% id, 0.0% wa, 0.3% hi, 0.6% si Mem:256324k total, 253212k used, 3112k free, 1192k buffers Swap: 506036k total,0k used, 506036k free, 152324k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 7341 root 39 19 63088 30m 25m R 48.6 12.2 12:08.06 python 17902 root 0 -20 126m 27m 30m S 32.4 11.0 15:16.88 fbxine 17908 root 0 -20 126m 27m 30m S 8.4 11.0 0:52.59 fbxine 17743 root 0 -20 126m 27m 30m S 6.2 11.0 2:56.39 fbxine 17903 root 0 -20 126m 27m 30m S 1.6 11.0 0:25.38 fbxine 20901 root 15 0 67548 7104 3596 S 1.3 2.8 0:02.86 vdr 7281 root 15 0 000 S 0.3 0.0 0:37.31 kdvb-fe-0 17901 root 0 -20 126m 27m 30m S 0.3 11.0 0:04.24 fbxine 20902 root 15 0 67548 7104 3596 S 0.3 2.8 0:00.78 vdr 20903 root 15 0 67548 7104 3596 S 0.3 2.8 0:01.01 vdr Yes, watching vdr with fbxine, killing fbxine makes no difference, freevo does not comeback: top - 00:06:50 up 3:09, 1 user, load average: 1.36, 2.24, 2.39 Tasks: 55 total, 3 running, 51 sleeping, 0 stopped, 1 zombie Cpu(s): 0.7% us, 0.7% sy, 97.7% ni, 0.0% id, 0.0% wa, 0.3% hi, 0.7% si Mem:256324k total, 230608k used,25716k free, 1280k buffers Swap: 506036k total,0k used, 506036k free, 154112k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 7341 root 39 19 58992 30m 25m R 98.1 12.2 14:08.46 python -OO /usr/lib/python2.3/site-packages/freevo/main.py 7279 root 17 0 67552 7112 3596 S 0.7 2.8 0:42.32 /build/vdr-1.3.13/vdr -Pxine -r 7281 root 15 0 000 S 0.3 0.0 0:37.73 [kdvb-fe-0] 7284 root 15 0 67552 7112 3596 S 0.3 2.8 0:21.75 /build/vdr-1.3.13/vdr -Pxine -r 20903 root 15 0 67552 7112 3596 S 0.3 2.8 0:01.53 /build/vdr-1.3.13/vdr -Pxine -r 1 root 16 0 1336 468 1184 S 0.0 0.2 0:00.19 init [3] 2 root 34 19 000 S 0.0 0.0 0:00.00 [ksoftirqd/0] 3 root 5 -10 000 S 0.0 0.0 0:00.35 [events/0] 4 root 5 -10 000 S 0.0 0.0 0:00.00 [khelper] 5 root 5 -10 000 S 0.0 0.0 0:00.02 [kblockd/0] 31 root 20 0 000 S 0.0 0.0 0:00.00 [pdflush] 32 root 15 0 000 S 0.0 0.0 0:00.08 [pdflush] 34 root 15 -10 000 S 0.0 0.0 0:00.00 [aio/0] I'm writing this as there is *nothing* in the logs do indicate anything has gone wrong.. VDR_XINE: EVENT RIGHT main.py (289): handling event RIGHT VDR_XINE: EVENT RIGHT main.py (289): handling event RIGHT VDR_XINE: EVENT RIGHT main.py (289): handling event RIGHT VDR_XINE: EVENT RIGHT main.py (289): handling event RIGHT VDR_XINE: EVENT RIGHT main.py (289): handling event RIGHT VDR_XINE: EVENT RIGHT main.py (289): handling event RIGHT VDR_XINE: EVENT RIGHT main.py (289): handling event RIGHT VDR_XINE: EVENT RIGHT main.py (289): handling event RIGHT VDR_XINE: EVENT RIGHT main.py (289): handling event RIGHT VDR_XINE: EVENT RIGHT main.py (289): handling event LEFT VDR_XINE: EVENT LEFT main.py (289): handling event LEFT VDR_XINE: EVENT LEFT main.py (289): handling event SELECT VDR_XINE: EVENT SELECT main.py (289): handling event RIGHT VDR_XINE: EVENT RIGHT __init__.py (227): Building the xml hash database... __init__.py (256): done And then nothing... Its stalled.. Actually, after I killed fbxine I got this line and then nothing ;-) --- childapp.py (317): stdout: No data, stopping (pid 17728)!childapp.py (317): stderr: No data, stopping (pid 17729)! --- restart or reboot fixes the issue.. But, I'd certainly like to find the root of the issue as it happens pretty regularly in thebackground while i'm watching tv.. Soo.. what can I do to debug this one?? Mick --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click ___ Freevo-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-devel
[Freevo-devel] Re: recordserver status, vdr integration and live tv
Thomas Weber wrote: > Hi, > > Dirk Meyer schrieb: > >>For that, each plugin needs to provide a list what it can record. This >>list is a list of devices, the ratings and the listing. E.g. you have >>a dvb-s card with the programs a, b, c, d, e, f and a dvb-t card with >>a, b, c, d but it is possible to record a/b and c/d at the same time, >>this function will return: >> >>[ ( 'dvb0', 20, ( [ a ], [ b ], [ c ], [ d ], [ e ], [ f ] ) ), >> ( 'dvb1', 15, ( [ a, b ], [ c, d ] ) ) ] >> >> > Its no problem to generate and import such a list into freevo. > The example is not good because when one has multiple dvb-[cts] cards > (up to 4) of the same type, all are usualy available to vdr. > So you dont need to know about the actual card but only about the > available programs. VDR assingns the recording on the fly to a "free" > card when the recording starts. dvb0 and dvb1 are only a key. You could also use foo and bar. By splitting it into devices I avoid one listing with all possible combinations (very long). For the recordserver it only means that these both are independed. > When a user have mixed card types like in your example, its becomes > IMHO more complicated to handle conflicts. Yes. The 'rate' function needs more work. Right now it tries to put a high priority recording to a better device, but will choose a lower one if necessary. I need some input what the best result should be. > I'm not even sure if such a case is handled by a single vdr instance at all. > One way to come around this would be to setup a dedicated vdr instance > for each card type. > This means: when a user has 2 dvb-s and 1 dvb-t cards, there would run > 2 vdrs [A) with card1+2, B) with card 3]. No problem there. My dvb mplayer dump plugin only handles one card because it is easier. If you have two, you need to start the plugin twice. From the recordserver point of view is no difference between one plugin having [ ( 'dvb0', 20, ( [ a ], [ b ], [ c ], [ d ], [ e ], [ f ] ) ), ( 'dvb1', 15, ( [ a, b ], [ c, d ] ) ) ] or two plugins with [ ( 'dvb0', 20, ( [ a ], [ b ], [ c ], [ d ], [ e ], [ f ] ) ) ] and [ ( 'dvb1', 15, ( [ a, b ], [ c, d ] ) ) ] >>You see, dvb1 (dvb-t) has a lower rating because the quality is not so >>good as dvb-s. If someone wants to create a vdr plugin, I guess you >> can get that informations from a channels.conf file. > Good point. I agree fully. The channels.conf, however, doesnt tell > about any quality/rating stuff. > I need to think about this... Maybe you get get the type in the channels.conf. I guess we can hardcode dvb-c better than dvb-s better than dvb-t. > Cool. So we can keep vdr running in the background all of the time? Sure. That's why I moved the recording timer from the server to it's plugins. > What about timers that are generated by 3rd party apps. > There is, for example, the tvtv plugin to program via web interface or > the autotimer plugin to record a tv-series via its EPG description. > We need some timer replication / polling here. That information needs to be send to the recordserver. The best way would be to add tvtv support for the Freevo recordserver. If this is not possible, maybe something can poll vdr and if it finds a schedule unknown to freevo, send it to the recordserver. >>My question at this point to the vdr people: does this work for you? >>Nad can you implement it? It would be cool to have vdr integration in >>Freevo 2.0. >> > Hey! I'd be happy if the plugin could be part of the next official > freevo version. That would be great. > There is, IMHO, no problem to implement it. Is there any release > schedule for Freevo 2? Not really. When it's working again everywhere. Right now I'm doing most of the stuff, but every help will speed up things. There are many things on my todo list. My basic list is: a) make the record stuff good enough that I can install the current cvs on my machine. Choosing cvs for daily use will help find bugs. And b) I hope to get a 2.0 pre1 out at the end of this year. >>Now to live tv. If you start live tv, the recordserver _must_ know >>about this. ... >> > >> For the vdr plugin, vdr will solve this automaticly. I guess >>only for analog tv this doesn't work. But I need more ideas how live >> tv fits in the recording context. > VDR locks all cards to the needed channels/buequets. So if at least > one card is free: no problem to watch live tv. > Otherwise the user can only switch to the channels on the same > buequets as the recording is on. Yes, for vdr this is easy. For others I have to think more about it. > Its still a good idea to let freevo know about the current live > channel. The command flow is always "remote control -- freevo -- > plugin -- vdr", so its know problem to let the plugin publish the > current channel to some freevo api. Yes, maybe the user could watch live tv on the analog card because vdr can't show that channel right now. Dischi -- .sdrawkcab dootsrednu tub sdrawrof devil si efiL pgp9Lo
Re: [Freevo-devel] recordserver status, vdr integration and live tv
Hi, Dirk Meyer schrieb: For that, each plugin needs to provide a list what it can record. This list is a list of devices, the ratings and the listing. E.g. you have a dvb-s card with the programs a, b, c, d, e, f and a dvb-t card with a, b, c, d but it is possible to record a/b and c/d at the same time, this function will return: [ ( 'dvb0', 20, ( [ a ], [ b ], [ c ], [ d ], [ e ], [ f ] ) ), ( 'dvb1', 15, ( [ a, b ], [ c, d ] ) ) ] Its no problem to generate and import such a list into freevo. The example is not good because when one has multiple dvb-[cts] cards (up to 4) of the same type, all are usualy available to vdr. So you dont need to know about the actual card but only about the available programs. VDR assingns the recording on the fly to a "free" card when the recording starts. When a user have mixed card types like in your example, its becomes IMHO more complicated to handle conflicts. I'm not even sure if such a case is handled by a single vdr instance at all. One way to come around this would be to setup a dedicated vdr instance for each card type. This means: when a user has 2 dvb-s and 1 dvb-t cards, there would run 2 vdrs [A) with card1+2, B) with card 3]. You see, dvb1 (dvb-t) has a lower rating because the quality is not so good as dvb-s. If someone wants to create a vdr plugin, I guess you can get that informations from a channels.conf file. Good point. I agree fully. The channels.conf, however, doesnt tell about any quality/rating stuff. I need to think about this... After the recordserver found the best way to schedule the recordings, he will give the list of recordings to each plugin. We will do it right now, not when the time comes. The plugin itself has to make sure it will start the recording when needed. This is for vdr because you want vdr to handle the scheduling. So maybe the vdr plugin will get a list of recordings when the first one starts two days from now. At this point, the recordserver itself will do nothing anymore, it's up the plugins. Everytime something changes, the recordserver will recalculate everything and update the plugins schedule. Cool. So we can keep vdr running in the background all of the time? What about timers that are generated by 3rd party apps. There is, for example, the tvtv plugin to program via web interface or the autotimer plugin to record a tv-series via its EPG description. We need some timer replication / polling here. My question at this point to the vdr people: does this work for you? Nad can you implement it? It would be cool to have vdr integration in Freevo 2.0. Hey! I'd be happy if the plugin could be part of the next official freevo version. There is, IMHO, no problem to implement it. Is there any release schedule for Freevo 2? Now to live tv. If you start live tv, the recordserver _must_ know about this. ... For the vdr plugin, vdr will solve this automaticly. I guess only for analog tv this doesn't work. But I need more ideas how live tv fits in the recording context. VDR locks all cards to the needed channels/buequets. So if at least one card is free: no problem to watch live tv. Otherwise the user can only switch to the channels on the same buequets as the recording is on. Its still a good idea to let freevo know about the current live channel. The command flow is always "remote control -- freevo -- plugin -- vdr", so its know problem to let the plugin publish the current channel to some freevo api. Greetings, -- Thomas Weber --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click ___ Freevo-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-devel
[Freevo-devel] Re: recordserver status, vdr integration and live tv
Hi! Dirk Meyer wrote: Hi, after some time of thinking about what I want for Freevo and how some people like to use vdr inside Freevo, I have the following proposal for the new recordserver. Some stuff is already done, other code is in my head and in cvs next weekend. This is great to hear :-) , keep up the good work!! First, I want to use the new recordserver even when you use vdr. Reasons for this are that there is maybe a card vdr doesn't know about (analog) and the Freevo recordserver knows more about priorities. So this is what the recordserver will do: Check all recordings for conflicts. A conflict is a list of recordings with overlapping time, even when only the padding overlapps. E.g.: a overlapps with b, b with c. d has no overlapping and e overlaps with f. So d will get the best recorder possible, no conflict here. And the other 5 will be in two lists of conflicts: [ [ a, b, c ], [ e, f] ] and they will be solved. When solving a conflict, overlapping times result in 'not possible', overlapping padding times are 'possible, but not so good'. The recordserver will try all combinations how to record the conflicts with all possible devices, including a fake device 'null' for drop. After that, we have a perfect schedule (as perfect as the 'rate' function is). For that, each plugin needs to provide a list what it can record. This list is a list of devices, the ratings and the listing. E.g. you have a dvb-s card with the programs a, b, c, d, e, f and a dvb-t card with a, b, c, d but it is possible to record a/b and c/d at the same time, this function will return: [ ( 'dvb0', 20, ( [ a ], [ b ], [ c ], [ d ], [ e ], [ f ] ) ), ( 'dvb1', 15, ( [ a, b ], [ c, d ] ) ) ] You see, dvb1 (dvb-t) has a lower rating because the quality is not so good as dvb-s. If someone wants to create a vdr plugin, I guess you can get that informations from a channels.conf file. After the recordserver found the best way to schedule the recordings, he will give the list of recordings to each plugin. We will do it right now, not when the time comes. The plugin itself has to make sure it will start the recording when needed. This is for vdr because you want vdr to handle the scheduling. So maybe the vdr plugin will get a list of recordings when the first one starts two days from now. At this point, the recordserver itself will do nothing anymore, it's up the plugins. Everytime something changes, the recordserver will recalculate everything and update the plugins schedule. My question at this point to the vdr people: does this work for you? Nad can you implement it? It would be cool to have vdr integration in Freevo 2.0. Now to live tv. If you start live tv, the recordserver _must_ know about this. If you have two dvb-t cards and use one for live tv, the recordserver has to know that one card doesn't work anymore. For dvb or ivtv, maybe the best solution would be to record the live tv and watch it with a player. One file or a ringbuffer, both should be possible. For the vdr plugin, vdr will solve this automaticly. I guess only for analog tv this doesn't work. But I need more ideas how live tv fits in the recording context. Comments please. This sounds all very interesting and very good so far. Nevertheless, I'd like to add my 2 cents (you asked for ;-) ). Is it planned to re-implement various cool things that vdr can already do, in freevo? Let me just enumerate few of them: - Manually editing vdr recordings/setting cutting marks via remote control and OSD, exchanging these cutting marks via the sharemarks plugin, even letting noad automatically set cut marks? - What if the recording schedule is altered or even modified by the user in VDR itself, some users might still want to be able to start VDR itself, and it would be cool if that would be a configuration option to start it from freevo, to get access to some of VDRs "specials", then he might schedule recordings from there, or from vdradmind , or from a remote streamdev client (like the windows client for example)? The plugin should then provide freevo's recordserver these changes. Might be difficult then to resolve conflicts among devices handled only by freevo, but I think maybe this should be discussed or thought of. - VDR can blend EPG data in the OSD, just like "normal" STBs, with data about the current show, what's running on other channels, what's next. Will Freevo implement this also in such a way (not like until now, without live video)? - How will EPG data for various devices will be handled? I for example have a PVR250 which used to receive about 23 channels from the collective antenna wall outlet of the flat we're living in, and I had to grab EPG through xmltv for it. Now I temporarily can't use Freevo (due to broken SDL, so I can't wait for a usable CVS version with DFB-only :-) which I already tested, thanks to Rob), so I mainly schedule recordings in VDR, which gets EPG data from DVB-S for most of the channels (especially german ones),
[Freevo-devel] Re: [PATCH] from _debug_ to logging
Eirik Meland wrote: > I have ported freevo from using _debug_ to using the python logging-module. > > I didn't find a good way of diffing the result (because of > site-packages etc), so I ended up with a > "cvs diff", and attaching the new file. Looks good and is working, thanks. > Limitations: > * The path to the log file (/var/log/freevo/freevo.log) is hardcoded > in the log.ini > * For main.py to find log.ini, freevo has to be started as ./freevo Maybe we can find a better way than using log.ini. I don't like another config file and you only include it in main.py, so a helper doesn't have that information. Any ideas how to solve that? Maybe with the help of the sysconfig file? Dischi -- Nothing is fool-proof to a sufficiently talented fool. pgp8WgjQTKpf6.pgp Description: PGP signature
[Freevo-devel] recordserver status, vdr integration and live tv
Hi, after some time of thinking about what I want for Freevo and how some people like to use vdr inside Freevo, I have the following proposal for the new recordserver. Some stuff is already done, other code is in my head and in cvs next weekend. First, I want to use the new recordserver even when you use vdr. Reasons for this are that there is maybe a card vdr doesn't know about (analog) and the Freevo recordserver knows more about priorities. So this is what the recordserver will do: Check all recordings for conflicts. A conflict is a list of recordings with overlapping time, even when only the padding overlapps. E.g.: a overlapps with b, b with c. d has no overlapping and e overlaps with f. So d will get the best recorder possible, no conflict here. And the other 5 will be in two lists of conflicts: [ [ a, b, c ], [ e, f] ] and they will be solved. When solving a conflict, overlapping times result in 'not possible', overlapping padding times are 'possible, but not so good'. The recordserver will try all combinations how to record the conflicts with all possible devices, including a fake device 'null' for drop. After that, we have a perfect schedule (as perfect as the 'rate' function is). For that, each plugin needs to provide a list what it can record. This list is a list of devices, the ratings and the listing. E.g. you have a dvb-s card with the programs a, b, c, d, e, f and a dvb-t card with a, b, c, d but it is possible to record a/b and c/d at the same time, this function will return: [ ( 'dvb0', 20, ( [ a ], [ b ], [ c ], [ d ], [ e ], [ f ] ) ), ( 'dvb1', 15, ( [ a, b ], [ c, d ] ) ) ] You see, dvb1 (dvb-t) has a lower rating because the quality is not so good as dvb-s. If someone wants to create a vdr plugin, I guess you can get that informations from a channels.conf file. After the recordserver found the best way to schedule the recordings, he will give the list of recordings to each plugin. We will do it right now, not when the time comes. The plugin itself has to make sure it will start the recording when needed. This is for vdr because you want vdr to handle the scheduling. So maybe the vdr plugin will get a list of recordings when the first one starts two days from now. At this point, the recordserver itself will do nothing anymore, it's up the plugins. Everytime something changes, the recordserver will recalculate everything and update the plugins schedule. My question at this point to the vdr people: does this work for you? Nad can you implement it? It would be cool to have vdr integration in Freevo 2.0. Now to live tv. If you start live tv, the recordserver _must_ know about this. If you have two dvb-t cards and use one for live tv, the recordserver has to know that one card doesn't work anymore. For dvb or ivtv, maybe the best solution would be to record the live tv and watch it with a player. One file or a ringbuffer, both should be possible. For the vdr plugin, vdr will solve this automaticly. I guess only for analog tv this doesn't work. But I need more ideas how live tv fits in the recording context. Comments please. Dischi -- I'm going to live forever, or die trying! -- Spider Robinson pgpRXK6WQS3X3.pgp Description: PGP signature
