My experience with Dreambox

Since the analogue TV broadcasting in Prague is going to be cancelled and replaced with DVB-T soon, I bought a Dreambox 500T. First I was considering a mainstream set-top-box with HDD, but none of them matched my requirements of being possible to be connected to a Linux PC. With Dreambox I expected good compatibility and no noisy HDD and/or fan in the box.

Since Dreambox 500 is the cheapest one of the series, it comes with some problems, however most of them should be possible to solve.

What concerns the information resources on the web, my impression is that there are only two types of them - either for lamers and Windows users, or for developers. So there is only few pages useful for advanced Linux users.

To the most difficult situation I got when I accidentialy damaged the flash image, so the box would not come up from flash. Most of the web resources suggest to use a windows program dreamup. I tried to run it under wine and virtualbox, but it said it couldn't open the serial port and died.

So I decided to follow another page that provided quite good description how to boot the box via NFS. It worked well, but to do it, one needs to have the files (kernel, and the root FS tree). But all I had was the flash image that consists of concatenated cramfs image containing the kernel and some clone of squashfs containing the root FS. So with cramfsck -x, I managed to extract the kernel from the flash image and that was all where I got with the standard tools.

When I tried to extract the squashfs part, I was getting some error message from zlib, so I suppose that either squashfs is endianity-sensitive, or the squashfs used in Dreambox is some strange clone, incompatible with the mainstream version.

So after several more hours of googling and trying, I ended up with booting Debian and from there I finally managed to flash the whole image.

This experience brought up another issue, and it is that there is internet resource where you could download the binaries as single files (or in some form that would be understood by x86 linux). So it is a good idea to make the backup with cp -a via NFS or CIFS, so you would have the NFS root drive ready in the case that you need to boot the box from network.

Due to this bad expreience with the available online resources I have decided to place the files you may need to boot your Dreambox from network to my page for others to download:

What in NGrab

What dreambox calls NGrab is really a combination of a outgoing (from Dreambox to server) TCP interface that transfers the XML commands to the streaming server and several streaming services on Dreambox side out of which I use streamts (the one on port 31339), however the original software (ggrab) is using different service on port 31338. The advantage of my solution is that the recorded movies can be seen and played back by Dreambox.

Bulding dreambox software from source

I have found web pages describing how to build Dreambox software from source. All the stuff is sort of obsolete and likely not maintained anymore and therefore only partly functional. It is aimed to build the whole flash image from source codes it downloads from various places in the net.

However building some parts of the system fails, it is possible to use the binaries extracted from the binary packages (ie. Gemini) instead. What is important is that Enigma still builds fine. So I played with the DVR recording feature and came to following conclusion:

Fix for the DVB recording feature

However I tried everyting I knew to make the network recording to work fine, it doesn't seem to be feasible, likely due to some hardware limitations of Dreambox 500. I get small glitches in the recorded stream every 5-10 minutes. However it is much better than it was on the original code. I have pretty much gave up and I am going to upgrade to Dreambox 600.

Following 3 files need to be patched to make DVB recording via CIFS to work better on Dreambox 500. The first 2 ones to fix the buffer-flush-duration issue, the third one to make Enigma aware that the recording feature is available.

Remote control keys remapping

You need to edit file /share/tuxbox/enigma/resources/rcdm5xxx.xml. The mapping that is used in the "normal" state of enigma when it is playing TV or a file are in the section called enigmaMain. There are some tricks that were (at least for me) hard to figure out:

So far I just needed to remap the key that toggles between the info panel and the recording control panel that is normally mapped to the "video" button on the bigger remote control that comes with higher versions of Dreambox.

The .TS format

While I was analysing why the DVR recording didn't work, I had to figure out some way how to check consistency of the .ts files produced by Dreambox. I figured out that the format consists of 188-byte blocks always starting with 0x47. Therefore it is quite easy to check if the recorded file is damaged. I have written a simple program that does this job.

More information to be added

Useful links

Dreambox 600 PVR

Since I didn't make Dreambox 500 to work as I wanted, I gave the box to my parents who needed a DVB-T receiver anyway and bought a Dreambox 600. I took the risk and bought the Chinese version. However, I couln't get the -T version, so I bought the -S version and bought also the terrestrial receiver card. This turned up to require some mechanical work since the holes of back panel of the box are not compatible with different versions of receiver modules.

How to build the software

The sofware in dm600pvr is a different branch and requires different build environment (see The opendreambox.org page). I applied the guide and it worked fine, it managed to compile the whole thing. I somehow missed whether it can create the image file (.nfi). So I used a part of the existing image and I just replaced /usr, /var and /etc.

The Movie Player and VLC

I decided to get rid of the recordable DVDs and store the data on the server's HDD and use Dreambox to play it. It requires VLC on the server side and Movie Player plugin in Dreambox. Since my Linux distribution I use on the server doesn't provide the binary package of VLC, I had to build it from source and it was itself quite tricky.

The Movie Player plugin is also tricky because its implementation in the version of Enigma used for dm600pvr is somehow incomplete. If you build the source as it is, the part of Movie Player that resides in the main Enigma executable wouldn't build. It requires symbol ENABLE_EXPERT_WEBIF that enables some unfinished parts of code. I went through the enigma's makefiles and added -DENABLE_EXPERT_WEBIF to CPPFLAGS. The current version of movieplayer doesn't support the latest versions of VLC (0.9.x). It requires some minor fixes to get it working, but I am definitely not satisfied with it. My major purpose for using the Movie Player was to play DVD images and AVI files stored on the server. But I failed to configure VLC to manage the transcoding to the format the Dreambox can play in realtime. So I used the Movie Player source as base for my own plugin that uses mplayer/mencoder.

If someone is interested in the modified sources for MoviePlayer, I can provide them, but I believe that it may be sort of redundant, since there are other clones of Dreambox SW that already include some enhanced versions of Movieplayer (ie. PLI-JADE).

Streaming with mencoder

I have created a plugin that works on slightly different principle that the original MoviePlayer. First I need to note that this SW is not BFU-ready and it is not its major purpose. So if it helps someone, that's OK, but I don't intend to please the mainstream users. Lot of values are still hard-coded in the sources, so you need to change them to match your environment.

It is sort of a hack made with minimum effort and as such, it suffers with limitations. It works using named pipes and a TCP connection to transport the stream from the server to Dreambox. On Dreambox side, I created a named pipe (/pipe.mpeg) and I have put there a daemon that listens on TCP port 4001 and puts the received data through a buffer to the pipe. When the stream seems up, the plugin starts playback of the pipe and exits. The limitations of this concept come clearly from the difference between pipe and an ordinary file:

However, there are also advantages to this copncept

On the server side, I have a simple perl script that listens on TCP port 4002 and accepts simple commands that provide the plugin with information about the files and directories and things on the DVD images (titles, chapters, audio tracks etc.). Finally it starts mencoder to stream data to the pipe on the server side.

Usage procedure is following: start the MplayerCtl plugin, select what you want to play, go to file mode and play file /pipe.mpeg. When you switch to playing something else, the streaming would stop and if you want to watch it again

Here is the software itself

This work is still unfinished, when I manage it to work, I will put more information here.

If you have any comments, please send me an e-mail.