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.