-----BEGIN PGP SIGNED MESSAGE-----
After a lot of thinking and a lot of playing around with various things I
think I can better propose an overall architecture. I encourage anybody to
critcise, flame, or what have you. Discussion is a good thing.
This basically allows anything to talk to anything and handles scheduling. In
- - API: A single interface to pretty much anything available in the daemon
itself and in the other components (acting as a proxy). This API can be
accessed programmatically, from the command-line, and through a web
interface. Think a cross between 'xawtv-remote' and KDE2's 'dcop' command. I
(scroll down to the 'DCOP Interfaces' heading to see it in action)
- - Events: Anything executed on or in the daemon will generate an event to
which you can attach other API calls. This can be used to easily define
behaviour. Here's a theoretical example:
"A 'change channel' event is created and set to occur whenever
'tv.channelup', 'tv.channeldown', or 'tv.channelset' are executed. The event
is also set to execute 'osd.displaycurrentprogram' so that the current
program information is displayed."
- - Preferences: These can be stored in a database and may be read or set
through the API. These preferences may include: program scores (good, bad,
okay, kinda cool, if there's nothing else on), topic scores, genre scores,
channel scores, desired recording quality, or anything else
- - Scheduling: Any internal or external process can be scheduled. This is most
important for recording shows, changing channels, or downloading program
data. These schedules can be set by events or directly through the API (from
an on-screen or web-based interface)
I've been playing with a few ways to create this and it looks like the
Twisted Framework at http://twistedmatrix.com/ is my favourite at this point
because it's easy to develop with, can be modified on the fly, and
automatically saves it's state upon exit. The state saving is perfect for
something like this. It's quite reminiscent of the factory machine design I
used to do in a previous life as an embedded developer.
I should note that my use of Python here is for prototyping. Changes can be
quickly made and the architecture can be thought through fully before porting
to something like C (boo) or C++ (yay). Of course, if it works adequately
enough for everyone, it can stay in it's prototype form...
Media Player Daemon:
This is basically a wrapper for your favourite media player so that the main
daemon can play anything at any time (at the user's request, of course).
I created a program that runs continuously and wraps Mplayer. After *a lot*
of screwing around, I've found that control should be done through a 'fake'
LIRC daemon. You can use X events, but they don't work on the framebuffer.
Of course, Mplayer could be it's own daemon in the future, but this works for
I haven't played with GStreamer yet as I have to upgrade to ALSA 0.9, which
means I'll have to recompile a ton of other software. I'm not exactly looking
forward to that as I'm a total RPM fiend and that's a *lot* of RPMs:
rpm -q --whatrequires libasound.so.1 | wc -l
That includes KDE, which takes a day or two to compile/package...
- From what I see, GStreamer is most likely a *much* better fit for this
project, though. I think I'll set it all up this weekend.
LIRC (remote control interface):
It's probably best to let lircd send remote control events to the OpenPVR
daemon which can process them appropriately (thumbs up/thumbs down, for
example) and proxy them to applications that already support LIRC such as
Mplayer. This requires some minor hacking of lircd but can save the hacking
of individual applications later. This we only have to do once.
This is what I've been playing with tonight. I'm thinking of creating a fake
remote control driver. The interface seems simple enough. (famous last words)
A thin wrapper for v4lctl, in the main daemon. See 'man v4lctl' for more
This is pretty straight forward. Set the channel via V4L and record it. For
each program recorded, a corresponding XML metadata file is created
containing the XMLTV data.
The on screen stuff is probably the hardest part, but it looks like GStreamer
can do a lot of the heavy lifting (overlaying onto live video).
What we want the OSD to display:
- - Program/channel info
- - User interface, widgets and all
- - Setup/preferences
Of course, it'll have to be themeable.
That's all I can think of right now, as it's late and I have to get to bed at
Do remember that this is up for discussion and is in *no way* set in stone.
If you think I'm on crack, then by all means, tell me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
-----END PGP SIGNATURE-----