Re: Thoughts on VDR evolution - my 2 cent

[Margit.Fiegert@t-online.de]

> If I recall right what came up for enhancements, I get
> 
>      1. playing DVDs (see my other posting for the hack I did)
>      2. playing MP3 files
>      3. having teletext
>      4. having some kind of EPG (speak, improve the EIT stuff)
>      5. controlling vbox
>      6. playing regular audio CDs (that would be my add)
> 

I like the idea of installing one packet and getting all of this!
On the other hand i don`t like the idea to grow VDR to one big program. 

>Carsten:
>I love the way Klaus has implemented it - lightweight
>with just a few lines of C++ code. I do not even want
>to install a db system on my video recorder, let alone
>learn how to use it.

All these things are really diffrent applications. What we want them to
have in common is easy installation with one call of make, and a common
frontend - a OSD UI.

I would prefer an architecture like this:

* A kind of logical device driver that is responsible managing the
resources:
  Which of the applications should get access to which of the resources
at what time.
  Applications: see above, 
  resources: Sattelite input channel, TV output channel, Videotext,...
of one or more cards.
  Of course the connections and priorities have to be taken into
account. Videotext can`t change the network while VDR is recording, ...

* A kind of Display Manager
  Input: Textual description of Menue structure
  Process: Interaction with user via LIRC or keyboard
  Output: Commands to the diffrent applications

* One program per application, connected only by access to the former
two modules.

I did some sort of generic Display Manager in my job some time ago. I`d
offer to help with this here too.

What do you think of this?


Michael