[MPlayer-dvb] Using mplayer as DVB watcher

[Nico Sabbi]

On Wednesday 13 February 2008 00:29:19 Alfredo Pironti wrote:
> 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 ;-)

if it's clean and doesn't interfere with other stream types I'll
commit it

>
> 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.

post patch

>
> Feature:
> - Hierarchical grouping of channels
> Solution:
> - Create an OSD menu that read an xml file (chan_group.xml)

xml is strictly forbidden throughout the whole mplayer. A text file
such as 

[group1]
channel1
channel2
[group2]
channel3
channel1

is fine

> 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

uhm, it's something that probably belongs much more to a frontend
than to mplayer itself

>
> :-)). 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

patch welcome if you consider what I wrote