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 _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
