Am 01.03.2012 06:37, schrieb Gero:
>> A timer menu that belongs to a recording backend, a recording menu that
>> displays content of storage modules, several frontends that can connect
>> to one recording backend or several storage modules, ...
> I think, here is already the first shortcoming in design. May be cause you're 
> thinking with today plugins in mind?

You got me wrong on that. My vision would be that timer UI and recording
backend are two modules, and in a more complex environment there may be
several UI frontends connected to one (or more?) recording backends. Any
client should be able to edit timers on the server independently, the
backend shouldn't even have any UI.

In fact, any UI should be located in the frontend. For all sxfe fans: A
frontend implementation itself could split into two parts, one
server-side frontend, and one lightweight stream&OSD display. Or keep
latency low and put a more complex frontend on the client, that acts
independently of the server backend.

A high-level frontend could connect to one or more receiver backends to
get channels on demand, would be able to schedule timers on recording
backend(s), and would be able to play back from storage sources. Why not
allow a storage plugin to act as a media player instead of just VDR
recording server? Or on-the-fly transcoding on recording?

> Additionally it should be possible to configure the preferred input device 
> used 
> by this client for life-view. Other devices may be configured as fallback, in 
> case the preferred device is not available.

Thought of that. Generally, the default link between video frontend and
receiver backend should be handled like transfer mode, to make things
more unique. For the case of FF cards, there could be an additional
prefer-this-backend-for-this-frontend rule, and a shortcut in transfer
control that routes the video stream within the card instead of user space.

> As I already wrote, from my point of view, plugins may continue do 
> networking, 
> but the connection between backend- and frontend-part of vdr should not be 
> public nor affected by any plugin. 

Well, I have a different vision: More like recording server and
streaming client, where all the UI logic resides in the client, and the
server doesn't need to know about UI at all. One advantage: Allow a
frontend to connect to more than one backend. For example, have two
'full' VDR systems with receivers, recording capabilities and storage,
and some streaming clients. And then let each of them use any receiver,
any recording capability, and any recording storage that is available.

As said, the server itself could spawn several clients, so sxfe-like
lightweight viewers can connect to it. There could also be shortcuts if
backends are on the same machine or in the same executable, so not
everything must go over network.

However, thats all pretty much vision and far from being reality.



vdr mailing list

Reply via email to