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
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.
vdr mailing list