Using mplayer as DVB watcher

Hi all,
my ol' good TV broke some weeks ago, so I decided that I shall use my 
DVB(-S) PCI card that I installed two years ago (and never used until now).

I'm looking for some software that is as easy as using my old TV.

I tried different softwares for doing that. Freevo and VDR are simply a 
burden to get configured. Moreover they are over-featured wrt what I'm 
looking for. MythTV could be OK, but it does not support channel 
grouping nor sorting, and it becomes unusable, since DVB-S has 1500+ 
free-to-air channels. Implementing channel grouping in MythTV is being 
carried out, but I'm still too fascinated from the simplicity of

mplayer dvb://MyChannel

instead of having a backend MythTV process running as root, and running 
a frontend on it...

However, in current state, for my purpouse, mplayer is still not usable 
as a TV drop-in replacement. But I think few and not-intrusive effort is 
required to get that.

Here I propose some features I'm interested in, and possible 
implementation sketches to get them. I would really like to get some 
feedback from you. Once we have found together a reasonable solution, 
I'm quite motivated in implementing it, provided there's some hope that 
the patch get eventually included in mainstream, so I don't have to 
repatch and recompile mplayer each time it is updated ;-)

Feature:
- have 9 (or 99, or 999...) favorite channels that I directly reach by 
typing their associated number on my remote (like you would do on your TV).

Solution:
- Create a lircrc-dvb file associating each key (sequence) of the remote 
to a particular "set_dvb_channel" command. Then launch mplayer pointing 
it to the right lircrc-dvb file.

Feature:
- Hierarchical grouping of channels
Solution:
- Create an OSD menu that read an xml file (chan_group.xml) containing 
groups hierarchy, and channels belonging to groups. Then the user browse 
this menu and select a channel. (pressing OK on a group lists all 
channels belonging to that group and to all subgroups; pressing RIGHT on 
a group only lists all its subgroups)

In order to populate the chan_group.xml file, an external ad hoc tool 
could be used (I could write it). It is not viable to populate this list 
from scratch within mplayer, by using a remote. Just putting 300 of 
1500+ channels into groups requires a mouse/keyboard/monitor and 
dedicated software.

If the OSD menu only reads the chan_group.xml file and then browse it, 
then it is a menu like all other menus. In particular, its non volatile 
state is held in the chan_group.xml file, which is read-only.

However, once you have populated your chan_group file with the ad hoc 
tool, immagine this use case:
I seat on my armchair, zapping ungrouped channels, and I find a channel 
I really want to put in a group. I don't want to stand up from the 
armchair to
- get to my desk
- close mplayer
- open the ad hoc program
- add the interesting channel to the desired group
- restarting mplayer
- coming back to my armchair

For single channels, it should be possible to add them to groups within 
mplayer, so I don't have to stand up from my armchair. This means that 
the mplayer OSD menu should change its non volatile state, by upgrading 
the chan_group.xml file. A "write-through" approach (i.e. write to the 
file each time user modifies an entry) is not viable, it requires too 
many resources uselessly. So we should use a "write-back" approach (i.e. 
store all channel grouping changes in memory during execution, and write 
the file only when mplayer is going to be closed - if it does not crash 
:-)). This second approach is a bit more intrusive, because we should 
add a function pointer like

void (*on_exit) (void *);

to the "menu_info_t" struct. And this should be applied to all existing 
menus (not much effort indeed - we can set it to NULL for menus not 
using this function). Finally, the mplayer code should invoke this 
callback on shutdown (again, not so much effort).

Oh no, I said too much (I haven't said it enough).

What do you think about this?

Cheers,
Alfredo