HD900 IPbox

This page contains information regarding the HD900 satellite receiver. It contains configuration tips, information about how to set up your own software development environment, write and compile your own software, download mine, and other mostly HD900 Linux related topics.

Note: some topics are still marked either TBC (to be continued) or TBD (to be done). Check this page regularly for updates.

History

Fri Sep 5 12:48:21 CEST 2008 - added info about wget write problem
Tue Sep 2 21:48:26 CEST 2008 - added status update about RTC
Thu Aug 28 23:00:35 CEST 2008 - added info about MTD's
Sat Jan 24 16:02:23 CET 2009 - added updates w/regard new firmware

Index

HD900  Introduction  General  Forums Developing your own software for the HD900  Porting ntpdate (download now! [md5sum: 5bdc638b44c50612462be9c28e9261c9])  Porting micrond (download now! [md5sum: ae3dec3533b299713397fc23e7bf830c])  Writing plugin's Known problems  The RTC problem  The wget write problem Tips and tricks  Editing channels using the sqlite3 database  Interaction with sbox using named pipes  USB update details  Database layout and coherence  A bit about MTD's and databases  Executing scripts on the push of a button Delayed viewing on the Internet Notes

Introduction

I have been an avid lover of satellite TV since the early 1990's. Currently I own a multi-sat setup, which consists of two dishes, four LNB's, a digital HDTV receiver/recorder and a HD TV.

In august 2008 I purchased an ABsat IPbox 900 HD, which is a Linux based HDTV receiver. The box is, as far as I know, identical to the Cuberevo Mini. It is manufactured in Korea and then shipped to Slovakia. From there it is shipped to resellers in Europe. The box is imported in the Netherlands by Astrasat in Groningen (http://www.astrasat.nl). Buying it set me back about about € 300, which included the HDMI cable.

General

The limited resources available should not scare you too much: it seems to handle most tasks quite well, probably due to the fact that many tasks are handled by dedicated hardware. To further enhance the swift handling of the various processes, the kernel has been compiled with the preemtive flag set. My experience with this box shows that it works quite well, though sometimes the responsiveness to the remote controller is sluggish.

Users, who are not computer savvy, preferably Linux savvy, should not buy this receiver. And when you do buy this box, be prepared for the occasional unexpected hang, features that are not (yet) working (properly) and lousy documentation / support from the vendor.

On the bright side: this little box turns out a crisp and clear image and good sound. It features good quality hardware, and it is said that a port of the Enigma software will be made available for it. The current (r7927) release of ABsat's own software may be a bit buggy, but in practice it works quite well already.

The 900 supports HDTV displays up to and including 1080i using HDMI (but SCSI and composite are also available). It can receive HDTV channels as well as conventional SD channels. It can record one channel, while you watch another, given that the two programmes are broadcasted on the same transponder. If you connect an eSATA or USB disk to it it supports time-shifting, recording of programs (direct or timed), and of course playback. It can play back MP3 files, can display photo's and has a network connection, so you can log in to it, or mount your own Linux boxes on it. The box also supports picture in picture, which allows you to view 2 programmes simultaneously (though they need to be on the same transponder too). I also had to purchase a CAM (Common Access Module), as the 900 does not have a cardreader and I want to receive some encrypted (Dutch) channels. My trusty old Aston CAM, which I still have from the good old days when I owned a Humax 5400, would not work with this receiver. Initially, I bought an inexpensive Matrix Reborn, which worked nicely, bar a problem decrypting Nederland 1 HD (Dutch National Television): the sound came through fine, but no picture. I then switched to the rather expensive Aston, version 2.19, and my problem was solved.

The user manual can be downloaded from the ABsat support site (requires registration).

Forums

We are not alone. A number of forums exist, that may help you to solve your problems. Here are my favourites: http://www.denktenk.com/ (requires registration), where a lot of plugin developers can be reached, http://www.sat-universe.com (requires registration), where a lot of friendly powerusers can be found, and http://dev.dgstation.co.kr/phpBB2/ (again, registration required), the official, though not very active, DGS developers site.

Developing your own software for the HD900

I have been programming C code since the early 1980's, and I still like C a lot. So, I wanted to be able to compile C-program's that would work on the HD900. To do so, you typically set up a "standard" Intel/Linux box, where you install a set of cross-compilers and additional development stuff to enable you to compile sh4 binaries.

Assumed: some Centos5 (5.2. final) host, with an active Internet connection and at least 1.4 Gb free disk space in the /opt tree. I also assume you have your own network at home and both the Centos box and your HD900 are connected to it. The Centos box needs access to the Internet too.

Log on to your Centos box and become root:

% su -
# wget ftp://ftp.stlinux.com/pub/stlinux/2.2/iso/STLinux-2.2-sh4.iso
# mkdir -p /mnt/cdrom
# mount -o loop,ro -t iso9660 -r STLinux-2.2-sh4.iso /mnt/cdrom
# cd /mnt/cdrom
# ./install -c sh4
installing...
error: Failed dependencies:
	libstdc++.so.5 is needed by stlinux22-host-iperf-2.0.2-3.i386
	libstdc++.so.5(GLIBCPP_3.2) is needed by stlinux22-host-iperf-2.0.2-3.i386

# yum install libstdc++.so.5
...
Installed: compat-libstdc++-33.i386 0:3.2.3-61
Complete!

# install -c sh4
Installing..
Preparing..
..
lots of package names and '#### ...' progression bars flash by
..
stlinux22-sh4-g++           ##################################################
# _

Good. You may unmount and discard of your ISO image, if you want to.

Now you have a sh4 development environment in /opt/STM/STLinux-2.2

Next, edit /etc/exports and add this line:

/opt/STM/STLinux-2.2 <hd900-ip-address>(rw,no_root_squash)

# exportfs
# service nfs restart

telnet into your HD900, username root, password ipbox, and type:

# mkdir /mnt/stm
# mount <ip-of-develpmentbox>:/opt/STM/STLinux-2.2 /mnt/stm

Next, we'll run one of the precompiled binaries that are part of the development environment.

# chroot /mnt/stm/devkit/sh4/target 

This will create a new shell for you. If you type 'ls' you will see the target directory which is actually located at the Linux PC. The mere fact that you have a shell proves that you can run binaries which were cross-compiled on a i386, but feel free try some of the commands in /bin.

Next, we are going to compile the everlasting "hello.c" on our Centos box and run the result on the HD900. On your Centos box, for example in the /tmp directory, create a file aptly named "hello.c" with this content:

#include <stdio.h>
int main(void)
{
   printf("Hello from STLinux\n"); 
   return 0;
}

Now type:

# export PATH=/opt/STM/STLinux-2.2/devkit/sh4/bin:$PATH
# sh4-linux-gcc -o hello /tmp/hello.c

You can ftp this binary over to your HD900, or execute it directly from the mounted partition on your HD900.

To finish off my development environment, I created a functional user satdev, which has /opt/STM as its home, and created a .bashrc to set up various environment variables:

echo "Welcome to the HD900 software development tree"
echo
PATH=/opt/STM/STLinux-2.2/devkit/sh4/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin

PREFIX="sh4-linux"
export CC="${PREFIX}-gcc"
export LD="${PREFIX}-ld"
export NM="${PREFIX}-nm -B"
export AR="${PREFIX}-ar"
export RANLIB="${PREFIX}-ranlib"
export LN_S="ln -s"
export CFLAGS="-g -O2"

You can use su to change over to this new user, which will put you in the proper directory and execute the profile. You're all set to create your own HD900 binaries.

Porting ntpdate

First, I logged on to my development system (see above). I already had the proper PATH settings in my .bashrc:

# export PATH=/opt/STM/STLinux-2.2/devkit/sh4/bin:$PATH 

I started by creating a directory and downloaded the software there:

$ wget http://archive.ntp.org/ntp4/ntp-4.2/ntp-4.2.4p4.tar.gz
$ tar xzf ntp-4.2.4p4.tar.gz 
$ cd ntp-4.2.4p4

Then I edited ltmain.sh and inserted some extra exports after line 27:

...

# As a special exception to the GNU General Public License, if you
# distribute this file as part of a program that contains a
# configuration script generated by Autoconf, you may include it under
# the same distribution terms that you use for the rest of that program.

############################# start additions
PREFIX="sh4-linux"

export CC="${PREFIX}-gcc"
export LD="${PREFIX}-ld"
export NM="${PREFIX}-nm -B"
export AR="${PREFIX}-ar"
export RANLIB="${PREFIX}-ranlib"
export LN_S="ln -s"
export CFLAGS="-g -O2"
############################# end of additions

basename="s,^.*/,,g"

...

Finally, I ran:

./configure --host="sh4-linux"
make CC="sh4-linux-gcc" CXX="sh4-linux-g++"

BTW: those of you that do not want to set up their own cross-compiler development area but do want to use ntpdate on their HD900 boxes: you can download it here.

Porting micrond

I wanted to be able to start up processes at certain times. On Unix (and hence: Linux) systems, the normal procedure is to use cron. Alas, no cron available on the HD900. Another user already tried to use the precompiled cron from the STLinux distribution, but reported that it did not work properly. So, I decided to compile my own. A bit of looking around resulted in a promising candidate: micron, John Schmerge's interpretation of a classical cron. It has a relatively small footprint (19K on the HD900)and uses the standard cron syntax. Check out http://www.speakeasy.org/~schmerge/projects/micron/, his website, to read about it.

This is the log of what I did to port it - in fact: it proved to be very easy. On the first lines you see me switching to my development environment using su:

# su satdev
Welcome to the HD900 software development tree

This sets the various environmental variables and the proper path. Then I create a working area for the software and fetch the source from John's website:

# cd
# mkdir -p src/micron
# cd src/micron
# wget http://www.speakeasy.org/~schmerge/projects/micron/files/micron-0.0.4.tar.bz2
Resolving www.speakeasy.org... 69.17.116.121
Connecting to www.speakeasy.org|69.17.116.121|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 91921 (90K) [application/x-tar]
Saving to: `micron-0.0.4.tar.bz2'

100%[=====================>] 91,921      97.2K/s   in 0.9s   

16:11:51 (97.2 KB/s) - `micron-0.0.4.tar.bz2' saved [91921/91921]

Now, unpack it, and compile it:

# tar xjf micron-0.0.4.tar.bz2
# cd micron-0.0.4
# ./configure --host="sh4-linux" --with-default-editor=/bin/vi --sysconfdir=/usr/share/sbox/config --localstatedir=/var 
# make  CC="sh4-linux-gcc" CXX="sh4-linux-g++"
# sh4-linux-strip ./micrond 

# cd /sbin
# chown relook.relook micrond
# chmod +x micrond
# mkdir /var/cron
# nice -n 19 micrond
# cat /var/run/crond.pid

Note: the nice -n 19 prefix starts micrond with the lowest possible priority. Giving it higher priority is not necessary and may produce an increment of short interruptions of your current program.

You're done. To test if it is really working, create a script /sbin/test.sh:

#!/bin/sh
/bin/date > /tmp/testcron
exit 0

# chmod +x /sbin/test.sh

* * * * * /sbin/test.sh 

micrond logs its errors to /dev/null and will send all output of any script it runs there too - you need to redirect your output yourself if you want to see it. As a final note: you can start up micrond with the -d (debug) flag. It will then run in the foreground and log to stdout.

BTW: those of you that do not want to set up their own cross-compiler development area but do want to use micrond on their HD900 boxes: you can download it here.

Writing plugin's

The HD900 software provides the option to write plugins. Apart from a working development environment (see the relevant section), you need subversion. Again, if you don't have it, but are running Centos 5.2, you can simply type yum install subversion. The SDK can be found at http://dev.dgstation.co.kr/repos/cuberevo/.

In your development environment, create a new directory and cd into it. Then check out the code:

 $ svn co http://dev.dgstation.co.kr/repos/cuberevo 
... long listing ...
A    cuberevo/plugin/service_info/main.c
A    cuberevo/plugin/service_info/Makefile
Checked out revision 21.
$ _

$ cd cuberevo/plugin/epg_ex
$ make
sh4-linux-gcc -g -O2 -I./ -I../../include/sbox -I../../include/modules -I../../include/tools -I../../include/st_drv -Wall -DDEBUG -DDEBUG_LEVEL=5   -c -o main.o main.c
sh4-linux-gcc -g -O2 -I./ -I../../include/sbox -I../../include/modules -I../../include/tools -I../../include/st_drv -Wall -DDEBUG -DDEBUG_LEVEL=5 -shared -nostartfiles -o epg_ex.plugin main.o
sh4-linux-strip epg_ex.plugin
$ _

The RTC problem

My initial hunch that setting the Linux clock before starting up the sbox application would set the clock correctly proved to be wrong. ntpdate would set the Linux clock accurately, as it is supposed to do, but that would not reflect within the sbox application. Even worse: if you used ntpdate to set the time, the sbox application got confused, the sound would stutter and the program would not respond anymore. I disabled the automatic start of sbox, booted my box, then set the clock using ntpdate (worked fine), then started up sbox manually. sbox came up fine, but with the clock set to .. 1.1.2008, 0.00 AM. And, to add injury to insult: it would also ruin my previously set Linux clock.

It took about a week of exchanging e-mails with one of the DGStation developers, but then it became clear:

• there is a RTC on board the HD900;
• but it has no backup battery, so it looses it's memory when the power is switched off;
• the Linux kernel is not able to read the RTC, hence Linux sets its time to nonsense upon boot;
• the RTC can not be set using for example 'hwclock' or another Linux application;
• you can set the Linux clock (by hand, or using ntpdate etc.), but that does not set the RTC;
• the sbox application however can read and set the RTC;
• the sbox application does not check the Linux clock
• the call used by sbox to set the clock is not part of the current SDK API of sbox
• DGS will make the call that sets the RTC part of the next release of the plugin SDK

Update: my HD900 broke down recently and I had to take it back to the shop. They could not fix it and hence replaced the motherboard in my unit, which, in as far as I can see, now works properly again. In the process, however, they also updated my firmware to version 8340. All in all this version of the firmware adds a much more tactile feel to the system; it seems to respond much faster to keypresses on the remote. I also noticed that the option to set the time from the satellite stream was removed. You now need to set the time manually. I wondered if that was all that had changed, and did some tests.

I created a script, that executed the 'ntpdate' command when I pushed the green button, see also the section Executing scripts on the push of a button to learn how to do this.

Now, when I pushed the green button, the ntpdate command would be executed - and presto, the time in the front-end software would be set correctly too, bravo! You'll need an active network connection and some ntp server to talk to, of course. You migth employ 'micrond' to set the time, or use the trick to program the green button to do it for you. You can also choose to have the system set it upon boot, but keep in mind that it only will work if you have a copy of ntpdate available and after the network connection is set up and works properly.

The wget write problem

While using the HD900 wget (on the HD900 wget is implemented as part of busybox) to fetch a rather large binary, I noticed that the resulting file differed in size from the original: it was shorter. Small files are written perfectly, though. I posted this on some forums and found that a number of other users were able to reproduce the problem.

But, to my astonishment, others were NOT. After a while we found the reason: these users were using the /tmp directory to store the file, where I was using the /bin directory. The obvious difference is that /tmp is on a tmpfs filesystem, so it is actually in RAM, where /bin is part of the root filesystem, which is a jffs2 filesystem on top of the MTD (flash) drive.

I guess that wget does a regular open(), and does not use O_SYNC and/or O_DIRECT flags. This means that the operating system will cache the blocks, and write them to MTD in the background. Perhaps the cache simply fills up during the download, as it takes the jffs2 filesystem quite a while to write the 'blocks' to the MTD - don't forget: a (flash) MTD is not a diskdrive, it only allows serial access and it can't do direct seeks, so it is relatively SLOW. I haven't got a clue what happens when the write-cache (in memory) is full and the kernel does not have swapspace to write too (as the HD900 does not have swap by default). May be that some blocks are simply discarded..?

Well, as both 'mv' (part of fileutils) and 'wget' (on HD900 part of busybox) are Open Source code DGS must be able to figure it out, and fix it. Next question then: how many other standard utilities that do file I/O behave like this, for example, can we trust 'tar', or 'dd'?

Tips and tricks

Editing channels using the sqlite3 database

After unpacking and installing my HD900, I had some problems with reception of BBC Four / Cbeebies. Another user recognised the problem and suggested that I manually entered the "PMT-PID" (come again..?) using "Relook PCeditor".

First, I needed to understand what a "PMT-PID" is. In short: satellites transmit their data as small, uniquely identified chunks called "packets". The PMT-PID is the unique identifier of a packet that contains information about a program: it contains data that describes which are the identifiers of other packets in the stream that belong to a certain program. So, if you have properly defined the PMT-PID of the packet that defines the Cbeebies program, the receiver will be able to destille the PID's of the video- and audio-streams it should receive in order to present the program.

Then I found out that the Relook PCeditor is only available for MS Windows systems. I don't own MS Windows systems, nor do I really want to. So, I had to find another way. As my HD box is connected to my homenetwork, I could simply telnet into it and start looking around. Some explorations showed that most data seemed to be stored inside a SQL-Lite database. Also, the HD900 supports the sqlite3 command, which can be used to manipulate the databases interactively.

First, I had to find out which tables where in the database. I logged into my box as root and executed these commands:

# cd /var
# sqlite3 ./db.dat
sqlite> .databases
seq  name             file                                                      
---  ---------------  ----------------------------------------------------------
0    main             /var/./db.dat                                             

sqlite> .tables
FAVGRPInfo       channelinfo      sch_id           sleep          
FAVListInfo      options          sch_items        tpinfo         
LocalFreq        providerinfo     scheduledinfo    wakeup_hour_min
TimerInfo        satinfo          scrambleinfo

Seemed to me that the table named channelinfo probably had the information about the channels.. so I checked the structure of that table:

# cd /var
sqlite> .schema channelinfo
CREATE TABLE channelinfo
(
        id                      integer primary key,
        shortname               text,
        fullname                text,
        org_network_id          integer,
        ts_id                   integer,
        service_id              integer,
        pmt_pid                 integer,        
        seq                     integer,
        sat_id                  integer,
        tp_id                   integer,
        provider_id             integer,
        scramble                integer,
        status                  integer,
        audio_mode              integer,
        audio_index             integer,
        service_type            integer,
        volume                  integer
);
CREATE UNIQUE INDEX ch_idx on channelinfo (id);

And lo! and behold, there was a field named pmt_pid. A quick check on King of Sat helped me to determine the correct PMT_PID, and all I had to do now was to enter it into the proper field:

sqlite> update channelinfo set pmt_pid=270 where shortname='CBeebies'; 
sqlite> .exit

BTW: there is a nice .help statement and most SQL statements will work. You can also execute oneliners right from the command line, which can come in handy if you want to write your own scripts that need data from the sqlite database:

/var > sqlite3 ./db.dat "select * from channelinfo where shortname like('CBee%') or shortname like('BBC FOUR');"
4447|BBC FOUR|BBC FOUR|2|2045|6316|267|3520|22|427|240|0|0|2|255|1|10
4457|CBeebies|CBeebies|2|2045|6318|270|3530|22|427|240|0|0|2|255|1|10

The central piece of software, that in fact implements all functionality your box offers you, and which interacts with all subsystems is 'sbox'. Sbox will handle chores like displaying menu-items, acting on the remote control, displaying the correct channel, displaying EPG data and many things more. In short: sbox sits in the center of your receiver, as a spider it its web.

To allow interaction with the outside world, sbox uses a number of techniques: it uses named pipes to communicate with the outside world and dumps files in various directories, where they can be picked up by various subprocesses (like the local web-interface).

Up until recently, ABsat did not really elaborate on the exact workings of the interface. However, we were able to reverse engineer a number of commands / interactions.

TBC ...

USB update details

Upgrading your box can be done in various ways: using the Internet (though I have not been able to do this succesfully yet), using a proprietary operating system and a special programme, which enables you to flash your system using an USB cable - or the most simple and failsafe method: using an USB stick.

As simple as this may seem, there are some catches, as I found out the hard way: the loader expects a VFAT16 filesystem and just one file - which should have exactly the correct name. Also, the necessary fumbling around with front-panel buttons requires exact instructions - or it simply won't work.

First, download the new image. It typically is a zip file, which can be unzipped using the standard Linux unzip utility. I sugggest you create a directory, put the zipfile in there and then unzip it. The zipfile typically contains a changelog or readme file (you may want to read it) and the image. Note that the name of the image should be usb_update.img.

For Linux folks, here are instructions on how to create a properly working VFAT16 filesystem on a high capacity USB stick (in my case it was a 8 Gb Cruzer):

1. Put the stick into a USB slot on your Linux system. I have been using Centos 5.2 (final), but other Linuxes aren't that different from Centos;
2. On Linux, a USB stick will be regarded as a disk and hence a SCSI device will be created for it. Open a konsole or xterm and check which new SCSI device has been appointed by the kernel. This can be done in various ways, I use to check the messages file:

   $ grep sd[a-z] /var/log/messages

   In this example, I assume /dev/sdc, YMMV.
3. As root, start fdisk and instruct it to create a 200Mb VFAT16 partition. 200 Mb is sufficient, as the typical upgrade image is about 20-30 Mb in size.

   # fdisk /dev/sdc
   n)ew partition
   p)rimary partition
   Partition number: 1
   First cylinder: 1
   Last cylinder: +200M
   t)ype 
   6) FAT16
   w)rite

4. Create the VFAT16 fs:

   # mkfs.msdos -F 16 /dev/sdc1

5. Mount the stick and copy the image file:

   # mount /dev/sdc1 /mnt
   # cp /tmp/usb_update.img /mnt
   # sync
   # umount /mnt

6. remove the USB stick from the Linux system but do not plug it into your receiver yet

To install your image, proceed as follows:

1. do not plug the USB stick into your receiver yet
2. if necessary, switch on your IPbox; make sure it receives some program
3. switch the box into cold standby: on the front panel, press the I/O switch and the Ok switch simultaneously, the clock appears on your display
4. now, and no sooner, plug the USB stick into the USB slot on the rear of your IPbox
5. Push the front panel I/O switch and do not release it
6. Wait until "BOOTING" appears on your display (whilst still holding the I/O switch)
7. keep on pushing the I/O switch and press the Up key
8. "USB UPDATE" will appear on your display - release the front-panel buttons
9. ERASING will appear on your display, and a slowly incrementing number, this takes quite a while
10. FLASHING will appear on your display, and a slowly incrementing number, this also takes quite a while
11. Then, finally, "DONE" will be displayed: immediately switch of the box using the power switch on the rear
12. Remove the USB stick
13. Switch on your receiver, which will boot the new image

Database layout and coherence

TBD ...

A bit about MTD's and databases

The HD900 stores its programs and data on Memory Technology Devices (MTD's), which are better known as "flash drives" or "flash devices". MTD devices support a limited number of writes, have 32K block sizes and if just 1 bit is changed, still require a total erase/rewrite of the 32K block that contains that bit, decrementing the usable life of the entire 32K block. Errors in a block are not corrected by the device, but need to be detected at the device driver level. So - don't fuss around with these devices too much.

A telltale sign of the limited lifespan of MTD devices might be the EPGInfo database (/var/dbepg.dat) which still can be found in even the most recent images. Some investigaton show that this database is never filled, in fact: not even referred to by the image. So, why is that stub there?

Consider the way a database (like the sqlite3 database in use on the HD900) operates: it cares about its data and consequently writes the data to permanent storage ASAP, even minor changes. Also, it typically uses a limited range of disk-blocks, it is quite good at re-using existing blocks.

Now, I guess that the guys at DGstation started off storing the EPG database on their flash drives, hence the stub we still find in /var. Then they switched on their prototype and EPG data poured in: blocks and blocks of data, changeing very frequently, and the receiver stashes these changes away in the sqlite3 database, which dutyfully re-uses the same blocks over and over again, which in turn results in massive erase/rewrites to the very same blocks on the MTD.. 10.000 writes, that sounds like an awful lot, but when you write hundreds and hundreds of changes on a daily basis, your receiver will probably die after a few months. I guess that is what happened, hence: the EPG database was retired and the current mode (storing the EPG data in core) was introduced.

However, there are also voices thay say that DGS simply forgot to remove a database that reportedly was part of a predecessor of their software. Also, the sqlite3 database engine indeed tries to reuse space but quite often is not able to do so and then simply extends the database. In effect, the database will grow and grow. If this really becomes a problem, for example, when you run out of space, you can compact the database as follows:

sqlite3 database
sqlite> vacuum
sqlite> .quit

TBC..

mount -t jffs2 /dev/mtdblock3 /mnt

The HD900's sbox application (the front-end stuff that interacts with the viewer) contains functionality that allows you to execute a custom script (or compiled program) on the push of a button. To be exact: if either the red, green or yellow button is pressed on your remote, the system checks to see if there is a corresponding script (aptly named red.sh, green.sh and yellow.sh in directory /var/bin and executes it. The blue button is already used to stop recordings, so you can't program it.

To test it, you could write a simple script /var/bin/red.sh, i.e.:

#!/bin/bash
echo "User pushed red $(date)" >>/tmp/red.test 
exit 0

.. then ..

chmod +x /var/bin/red.sh

If you are away from home, for example, on a holiday or on a business trip, you may not always have access to your favourite programmes. Nor can't you always arrange your holiday or business schedule around the broadcast times of these shows. Sure, you can have the HD900 record your favourite shows for you - but you'd have to wait until you were back at home to see them. This section describes a solution that allows you to view the recordings of your HD900 by using a standard browser on the Internet.

When the HD900 records a file, it simply stores the files as MPEG2 or MPEG4 streams on your hard disk. Linux systems (like your HD900 is) can run software that converts MPEG streams into other formats, for example: the broadly supported Flash video format. By using one of the many freely available flashplayers, you can serve the flash files using your webserver. That's all there is to it.

As the HD900 already has Linux and even runs a webserver, it it tempting to do all the necessary work there: record, convert and serve. This is represented by the blue line in the figure above. However, an out-of-the-box HD900 does not have the proper software to do it. It might be possible to port this software to the HD900, but running that program can require quite a lot of memory and clock-cycles. This may lead to PANIC's or hangs, or inacceptably slow performance of your receiver. Also, this would require that you allow direct connections from the Internet to your HD900, not such a good idea.

As the HD900 is able to share it's hard disk with a PC, we might decide to do the conversion on an external PC and might also consider having that machine serve our converted files to us. This is represented by the green interconnection in the above figure. This solves the problems regarding clock-cycles and memory, but still requires incoming Internet IP traffic in your local network. If you either have an unreliable, unsafe or low-bandwidth Internet connection, you may employ the third option: convert the files locally and transport them to some external webserver. This option is represented by the red line.

Finally, you should ponder a while on how you are going to prevent others from seeing what you recorded, e.g. you could use a SSH tunnel, SSL/client side certificates, username/password protection or other more or less safe methods. Note that if you openly publish recorded programs on the Internet, you may be prosecuted for copyright violations.

Now, to the details. I assume you have the HD900 set up and connected to your house network. I assume you have some decent Linux box connected to your house network (I used Centos 5.2, but other distro's will probably do just fine).

We start by mounting the IPbox on our Linux box. For that, we use the samba protocol, not because it's such a good protocol, but because it is what is available by default on the IPbox. First I needed to figure out what the IPbox provided, so:

$ smbclient -L address-of-my-hd900 
added interface ip=145.66.56.30 bcast=145.66.255.255 nmask=255.255.0.0
Password: 
Domain=[IPBOX] OS=[Unix] Server=[Samba 1.9.18p8]

	Sharename      Type      Comment
	---------      ----      -------
	root           Disk      System root directory.
	tmp            Disk      RAM disk
	Configuration  Disk      Flash partition. /var
	Harddisk       Disk      The harddisk. /media
	IPC$           IPC       IPC Service (Ipbox network services)

	Server               Comment
	---------            -------
	DG400                Ipbox network services

	Workgroup            Master
	---------            -------
	IPBOX                DG400

Yes, that's right: DG400..

As I want to access the harddisk, I will mount the 'service' Harddisk on my Linux host:

# mkdir -p /mnt/hd900
# mount -t cifs -o "user=ipbox,password=ipbox" //ip-of-my-hd900/Harddisk /mnt/hd900 
# ls /mnt

Your recordings can now be found in /mnt/hd900. To find out which files there are available, search for files with extension ".trp", e.g. find /mnt/hd900 -name "*.trp" -type f. The filename contains the programname and date, to make it easier for you to identify your file. The filenames are postfixed with a .trp extension, regardless whether the file contains a MPEG2 or a MPEG4 stream. Also note that the HD900 chops up longer recordings in 2Gb sized chunks.

I suggest to use ffplay to play your streams. If you don't know about ffmpeg and ffplay yet, you might consider Googling along a bit to find out where to obtain it, I may write a bit more about compiling and configuring these tools later, for now I will focus on their usage. ffplay will play MPEG2 (SD) files without any problems. I have experienced problems with HD (mpeg4) files, which may be due to limited processing capacity or my not-quite-up-to-date version of codecs and player. YMMV.

ffmpeg can be used to convert between formats, and can convert MPEG2 streams to FLV (Flash Video) files. To convert your recording (let's say: Pietpraat.-20080813-00_49_3900.trp into a flash movie, you could, for example, use this command line:

$ ffmpeg -i ./Pietpraat.-20080813-00_49_3900.trp -f flv -qscale 6 -deinterlace -ab 56K -ar 22050 -ac 1 output.flv

The resulting Flash movie - e.g. output.flv - can be played in any webbrowser that supports the (freely available) Flash plugin, but you need an additional wrapper/player. The wrapper, in essence a Flash program with some Javascript controlcode, loads Flash, displays a screen and controls (such as start/stop buttons, scrollbars to allow positioning inside the stream and volume controls) and initiates the download of the stream. I like the JWF FLV media player, which can be downloaded for free and works just fine.

To synchronize the files between your external and internal server, I suggest you use rsync. You might consider compressing the files, but as most video files contain highly irregular and random data it often is not really worth your while.

If you'd like to automate the process, some additional work is required. For example, you could..

1. make a local copy of your remote webserver document tree (if you don't already have one)
2. mount the 'share' that represents your external disk drive on the Linux PC, let's say on /mnt/hd900
3. create a script that
   • finds new recordings
   • converts them to FLV files in your local webserver documenttree
   • create the necessary adjustments to your webpages
   • initiates a rsync with your remote webserver
4. have it run at least once a day using cron

An example of a CLI snippet you might use:

find /mnt/hd900 -iname "*.TRP" -daystart -ctime -1 -amin +240

This finds all files that have been created after midnight, today, and have not been accessed for over four hours, -amin +240. -amin +1 (not accessed the last minute ) would probably do fine too, as the only reason this clause is there is to prevent us from converting files that are still being recorded. To change this into "created in the last 24 hours and not accessed for over four hours", simply delete the -daystart.

If you want to see / hear the results of my experiments, check out: this page. In case you wonder: that's how my native language sounds.

Note that I converted the sound into mono (-ac 1), which I like best for this type of linguistic/educational show.

dvbsnoop -tsraw -tf -s ts -if  stream.trp

dvbsnoop -tsraw -tf -s ts 0x14