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 list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
