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
> >> On 27.02.2012 14:33, Frank Schmirler wrote:
> >>> I can't however overlook the impact these modifications have.
> >> 
> >> Me neither - and that's why I strongly oppose them ;-)
> > 
> > Then maybe it's time to return to KISS - perhaps in VDR 2.1.x? 

Oups - this principle is good to start on any date. 
Best would be start using it today :)

> > Maybe there's more obsolete stuff which can be thrown overboard. I feel
> > it's time to start from scratch with the device selection code, keeping
> > also the new challenges in mind (like e.g. the HD/SD or DVB-S/-T simulcast
> > thingy).

This is only one aspect, that really needs to be redesigned / completely 
rewritten from scratch.

> >> 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 same 

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 

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 ;) 

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

I think, many vdr-users crave for redesign and I'm sure, that some users are 
willing to participate.

kind regards


vdr mailing list

Reply via email to