[vdr] VDR with S2API (update)

[Nicolas Huillard]

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 
> now.
> 
> 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 
nearly this)
* 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 
one file...)

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)

-- 
NH