On 12.12.2008 23:23, Nicolas Huillard wrote:
> 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)

When there are no DVB devices available at start, no overhead will be 
launched anyway. And if you explicitly don't want to use local DVB 
devices, you can say so on command line.

And if DVB support really moves into a plugin, as plans currently seem 
to be, then this will be solved anyway.

> * EPG data is not shared between VDR instances : the one holding the DVB
> devices could "distribute" the contents upon request (streamdev does
> nearly this)

My clients do get EPG, worked right out of the box.

> * 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 ?)

There's a TouchUpdate() in cRecordings::AddByName and 
cRecordings::DelByName, that are probably there to do exactly what you 
request. Maybe there are some remaining bugs that need to be found.

> * schedules are not executed on the VDR instance holding the DVB
> devices, resulting in double network transfert, instead of none at all

Agreed. Solutions like RemoteOSD and RemoteTiemrs are merely 
workarounds. A nice solution to this integrated into VDR would improve 
things a lot here.

<brainstorming> Another parameter for every timer would be a nice 
solution: "Record locally" or "Record remotely" - VDR would have to 
connect to a remote VDR via SVDRP to read and write these timers.

> * 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...)

This would be a lot better with a client-server timer structure. And in 
the end, I'm pretty sure you don't need two VDR instances to record two 
different programs into the same folder, or?



vdr mailing list

Reply via email to