28.02.2012 12:24, Gero kirjoitti:
> On Tuesday 28 February 2012 - 10:11:48, Klaus Schmidinger wrote:
>> On 28.02.2012 09:32, Frank Schmirler wrote:
>>> On Mon, 27 Feb 2012 18:05:39 +0100, Klaus Schmidinger wrote
>>>> What exactly is the use case for this, anyway?
>>>> VDR has two purposes: "live view" and "recording". And the current
>>>> priority scheme handles this pretty well IMO.
>>> I guess in the meantime you could add "network streaming" to the list of
>>> purposes, too.
> But talking about future, I think a good VDR-design would be a real
> client/server-design. Or lets say a modern VDR consists of a backend and a
> frontend, which may run on different machines, but may also be run on the
> So networking is evident and vital.
> If I understand things right, the decoding of streams is a frontend task, so
> it would be possible to abstract all datasources as input. That means,
> may come from dvb-card, network, files (any file, that might contain stream
> data) and of cause from plugins, that might generate streams from pictures or
> the like.
> So the backend (beside the recording/timer part) just uniforms the streams
> makes them available via network.
> Frontend demuxes/decodes the streams (if necessary) and routes them to the
> real output devices.
> Taking into account, that networking can be broadcasted via UDP or streamed
> over single TCP-connection, it implies that different frontends might use the
> same stream from backend or each frontend might use a different stream. That
> also implies a complete different handling of setup and/or input/commands
> If connection between backend- and frontend-vdr could be established over
> network, as well as using shared memory, the 2 parts could behave like one,
> they were run on the same machine.
> With that design, vdr could handle all media, that make sense respect to
> looking and listening, so no more need for xbmc and other hacks ;)
I'd very much like something that would result in a better-behaving
server-client VDR system, i.e. so that clients just see the
recordings,timers,channels,epg just like they are on the server, instead
of duplication and the mess when they get out-of-sync.
I guess Klaus wants to keep VDR working as a monolithic entity like it
currently is, though, but maybe a "thin-client" (VDR instance with
viewing+menu only, with timers/recordings/channels transmitted from the
main VDR instance) support could be added as an optional feature.
(and probably a similar "headless" option to have VDR without
current-channel and GUI and stuff like that, for the backend)
>>> At the moment it all works pretty well in streamdev, ...
> As far as I understood available docs, streamdev is not able to handle
> recordings, so I would not say "all works"
>> I'll keep this in mind for "after version 2.0".
> Why so far?
Because 1.6.0 was released a long time ago, and we want a new stable
version soon? :)
> I think, many vdr-users crave for redesign and I'm sure, that some users are
> willing to participate.
vdr mailing list