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