[vdr] [ANNOUNCE] VDR developer version 1.7.24

[Anssi Hannula]

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. 
> 
> Sure!
> 
> 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 same 
> machine.
> 
> 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, streams 
> 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 and 
> 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 from 
> frontend.
> 
> 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, if 
> 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.


-- 
Anssi Hannula