In short... My favourite programming language and platform is C++ on Linux and I wanted another project to get stuck into, open source for a change. I was experimenting with getting away from VHS, and I had just returned to the shop a promising but non-working DVD Recorder. I scored a MVP for £20 in a sale (about $30 ?) but didn't realise its potential at first. Then I used the vdr-mediamvp software with VDR and realised that this was the way to get away from VHS and move properly into the realms of digital TV. Then I saw MVPMC, realised what they were doing and decided to start a project to combine the power of MVPMC by running software locally on the MVP, with the idea of it being a set top box running with VDR. Also, in the past I have experienced bad set top boxes and at the time I thought "I bet I could write that better myself"... So given the combination of the MVP and VDR, I decided to write VOMP.
The Hauppauge software that runs on the MVP is a thin client - most of the work is done on the server. All the menus are graphically generated on the server side and a modified VNC protocol is used to move the graphics to the MVP. Each button press has to be sent off to the server for processing. This makes it sluggish to use. The vdr-mediamvp plugin for VDR (and the new effort: MVPServer) by Dominic Morris replaces just the Hauppauge server side with new software. The client side is still the Hauppauge client software.
The MVPMC project created new client software to run on the MVP. It is a heavy client that does all its own thinking, graphics generation, button processing, everything. MVPMC is quick and responsive.
Now for some pros and cons. The thin client idea is very good for development - once the client is written the MVP side is done - most of the future work will be done on the server side, which is much easier and probably much faster to develop. The fact that vdr-mediamvp and MVPServer exist show this power - the standard Hauppauge client dongle for the MVP is used and yet it does something completely different.
However, this approach will always result in a sluggish interface - the round trip time of sending a button press to a server, receiving graphics over the network and then displaying them is long enough to irritate. The MVP is powerful enough to do its own processing and graphics generation - the VOMP and MVPMC projects have proved this.
There are some disadvantages to the thick client approach though. Firstly, developing for the MVP is more complicated than just developing for the local machine. You need: a cross compiler, a NFS root file system, a special kernel for the MVP, cross compiled libraries, etc. This means development is slower, can't be done anywhere and also means that not as many people will contribute to the project because of the daunting task of getting started. Secondly, although the processor in the MVP is nice and fast, the memory is on the small side and will be the limiting factor for any thick client project on the MVP. Out of the 16MB available to software, a couple is used for the dongle. Then the kernel boots up, busybox boots up and uses another couple. Then the actual client program loads and uses another 1MB or 2MB (it is big because it has to be statically linked). After that you need large buffers for MPEG video data... All this doesn't leave much spare. I have an idea for how to run more software on the MVP than there is space for, but I havn't yet investigated whether it can work on the MVP. Investigating this will quickly become a high priority task when the memory limit is hit!
So, be it right or wrong, my personal preference is to write fast, efficient and native code for the MVP.
Obviously I don't make it to these goals all the time :) But you have to aim high, right?
I am aiming for a squeaky clean set top box with a nice interface - a hard disk DVB receiver / recorder consumer set top box - but with the hard disk and receiver in a VDR server somewhere else on the network. This immediately brings two advantages: The hard disk is not making any noise near the TV, and multiple clients can use one backend - (tuner system and set of recordings).
I am not aiming for a generic media centre as the MVPMC project is doing, and as the MVP is sold in the first place. VOMP is more specific to being a set top box frontend to VDR. Having said that, I am not ruling it out - one day maybe, as long as it does not compromise the other goals. One specific exception to this is that I would like to be able to stream DVDs to the MVP using VOMP, so once the VDR integration side is done (!) that is where my attention will go.
Striked out items are done!
VDR timers support -
the ability to set a timer from the EPG, set a timer manually, view the timers list,
edit and delete timers.
Programme reminders - this is a feature available in most other set top boxes and there is no reason why it shouldn't be done for VOMP.
Information about recording playback. This is long overdue and is a good proportion of why I wanted
to write VOMP in the first place. Good on screen displays of length of recording, current position within
the recording, etc.
Pausing live TV - this depends on the timers support because the way it will work is to set a timer for the current channel and then switch to recording playback.
Backward scan through a recording.
A paged options screen - options will be split up into groups and displayed on seperate pages.
Integrated DHCP/TFTP equivalents in the server plugin to allow the MVP to boot without setting up
From more of a developer's point of view,
a better understanding of syncing audio and video is still
needed, MPEG timecodes need to be understood and implemented (so that recordings OSD can work), a
better font drawing system is needed and a better icon drawing system.
To see a full and more detailed list of bugs and features, see the SourceForge project site where
there is a tracker system for these things.
I have probably left out a lot of my thoughts about VOMP, but this is a start and should answer a lot of people's questions about the project.
Back to VOMP page
18163 hits since 21/Dec/05