Hi,
Dirk Meyer schrieb:
Its no problem to generate and import such a list into freevo.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 ] ) ) ]
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 soGood point. I agree fully. The channels.conf, however, doesnt tell about any quality/rating stuff.
good as dvb-s. If someone wants to create a vdr plugin, I guess you
can get that informations from a channels.conf file.
I need to think about this...
After the recordserver found the best way to schedule the recordings,Cool. So we can keep vdr running in the background all of the time?
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.
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?Hey! I'd be happy if the plugin could be part of the next official freevo version.
Nad can you implement it? It would be cool to have vdr integration in
Freevo 2.0.
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 guessVDR locks all cards to the needed channels/buequets. So if at least one card is free: no problem to watch live tv.
only for analog tv this doesn't work. But I need more ideas how live
tv fits in the recording context.
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
