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 _______________________________________________vdr mailing listvdr@xxxxxxxxxxxxxxx://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
