[vdr] VDR with S2API (update)
nicolas at huillard.net
Fri Dec 12 23:23:48 CET 2008
Udo Richter a écrit :
> On 12.12.2008 18:06, VDR User wrote:
>> I can say I've seen many people move away from VDR because it doesn't
>> provide a good solution to this. After years of using standalone VDR
>> boxes, I too would love if we had the option to use a networked VDR
>> with each client being exactly as you described... Diskless, and only
>> with ethernet cable + IR sensor, and each with an own OSD to control
>> his VDR thread.
> Hmmm, sounds just like what I have in my bedroom. Ok, it has a local
> disk for convenience, but no own receiver and no locally stored
> recordings. It could easily run from an USB stick or do network boot if
> I want. Oh, and the 'second remote frontend' is actually a complete VDR
> using streamdev.
> I really don't get the point why it is necessary to totally rewrite VDR
> core to support multiple frontends (surely loosing compatibility to
> almost all plugins), when it will at the end just start one thread per
> frontend, while we can already start one VDR instance per frontend right
> Even better: If one frontend crashes (well, it doesn't, but lets
> assume), the core VDR just runs on and none of the other frontends
> crashes too. Cool feature, or?
> If you're not happy with using streamdev to connect several VDR
> instances, wouldn't it be the better way to improve streamdev to meet
> the needs instead of starting all over again? VDR remote frontends would
> need a streamdev-like interface anyway.
In my opinion, the client and server are both full VDR, which just
happen to use one part of the whole functionnality.
I'm just talking about a split line drawn in the core VDR. Maybe like
the plugin interface is a split between what's in the core and what is
not, there could be an internal network interface that splits what's in
the front-end and what's in the back-end.
The problems that come to mind in typical current multiple VDR are :
* DVB device handling is running even if there is no actual DVB device
(OK, this is not a problem in practice, except for device numbers)
* EPG data is not shared between VDR instances : the one holding the DVB
devices could "distribute" the contents upon request (streamdev does
* recording list is also not shared, even though NFS does the actual
sharing of files : if one VDR starts a new recording, the other ones
won't see it until "some time", or until .update is touched ; if one VDR
removes a recording that another one is recording, I'm not sure about
the result (maybe a few GB lost in a strangely named directory ?)
* schedules are not executed on the VDR instance holding the DVB
devices, resulting in double network transfert, instead of none at all
* if 2 VDRs record the same program at the same time, it seems to a be a
big problem... If using a slightly different EPG data, this result in 2
recordings with different times, and if using the exact same EPG, this
result in something weird and maybe unusable (say, same station, same
EPG, one via DVB-S, the other one via DVB-T, two different streams in
Again, I trust Klaus and the collective creativity to come with a clean
solution, some time. In the meantime, the current solution based on
various plugins is OK for me.
I just have to remind my wife that she can't do "this" or "that" from
time to time ;-) Not that it's a problem for her. Not that it's
difficult for me to see why.
(getting back to solder this stupid IR sensor which doesn't want to send
anything to LIRC)
More information about the vdr