Udo Richter wrote:
> Am 16.01.2011 05:35, schrieb Gero:
> > Currently I use a "backend"-vdr with budget-cards and an old fashioned
> > FF. My TV is plugged to the old FF and I watch HD through a
> > frontend-client with xineliboutput.
> You're using a very special situation here, as xineliboutput is IMHO the
> only output device that can promote itself to be 'the' output device at
> runtime. 

Well - that is a point, I don't like at all!

So if someone watches TV with the FF card, the TV gets dark as soon as I start 
the xineliboutput frontend.
I don't know anything from the vdr internals - I'm just a user.

>From my (user-)point of view the vdr may not break, if a client does an error.
Currently when I forget to switch to a SD channel on the xineliboutput 
frontend before stopping that frontend, the vdr is not operable for the FF-
user. There's no way to recover.
I have to start the xineliboutput frontend, change the channel and then stop 
that frontend again.

> VDR itself has not much to do with this switching, 

Best would be, to be able to switch this kind of switching off completely.

> and doesn't know in advance how many of its devices suddenly may or may not
> be the output device.

That's how it should be - at least from my point of view ;)

> Keeping multiple configurations for OSD persistently
> would break a lot (including plugins), and will probably have lots of
> issues. 

Well, after all it was just a wish :)

I think, the task to create a new OSD system is neither simple nor small - so 
lots of issues have to been taken into account.
I like to think about upcoming issues in advance and I'm sorry, but I don't 
like that pessimists, that only know to talk about things, that are 
impossible, that should never get touched, ....

> Its probably a lot easier to solve this at the output side within
> xineliboutput.

So you change a possible issue into a 'NMP'-issue - not very smart.
(NMP stands for "not my problem") 

kind regards


vdr mailing list

Reply via email to