[vdr] VDR with S2API (update)
udo_richter at gmx.de
Sat Dec 13 12:31:05 CET 2008
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?
More information about the vdr