DroboApp HOWTO: FUPPES 0.660


Edit: I migrated this HOWTO to a more definitive place: http://www.droboports.com/app-repository/fuppes-0-660. Look there for updated information about FUPPES.

This is a simplified “how to” compile FUPPES 0.660 (the latest version as of today) as a DroboApp.

Fuppes seem to be the media streaming app for gaming consoles out there. I don’t own a gamin console myself, so I have to thank davesbrain for supporting the effort and helping me test this one out.

In summary, the version that comes out of this how-to is able to stream to PS3s, Xboxes, pretty much any UPnP device. However, this version will not parse metadata and will not transcode data.

Metadata parsing was dropped because, although FUPPES is very amenable to cross-compiling, the metadata parsing libs are a pain in the butt to compile (as discussed here). On top of that, parsing metadata slows down indexing a lot, due to the slow CPU of the FS.

Also, due to the slow CPU of the FS, no transcoding is supported at all. I haven’t even tried to compile the dependencies because I know that it will only result in trouble. In other words, if the video you are trying to play on your Xbox/PS3/what-have-you is encoded in some format the player does not support, then there is nothing this version of FUPPES can do for you. In fact, there is probably nothing the FS can do for you at all.

Compilation summary

That being said, let’s get down to it. Make sure that the environment variables are correct in your VM (notice that we are not compiling in /usr/arm anymore):

export CFLAGS="-march=armv5te" export CPPFLAGS="-march=armv5te" export CXXFLAGS="-march=armv5te" export LDFLAGS=""

Here is the sequence of commands that takes you from source to compiled app:

[code]export DEST="/mnt/DroboFS/Shares/DroboApps/fuppes-0.660"

wget http://zlib.net/zlib-1.2.5.tar.gz
tar zxf zlib-1.2.5.tar.gz
cd zlib-1.2.5
./configure --prefix=$DEST
make install

wget ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-8.12.tar.gz
tar zxf pcre-8.12.tar.gz
cd pcre-8.12
LDFLAGS="-L$DEST/lib" CFLAGS="-I$DEST/include -march=armv5te" CPPFLAGS="-I$DEST/include -march=armv5te" CXXFLAGS="-I$DEST/include -march=armv5te" ./configure --host=arm-none-linux-gnueabi --prefix=$DEST --enable-pcregrep-libz
make install

wget ftp://xmlsoft.org/libxml2/libxml2-2.7.8.tar.gz
tar zxf libxml2-2.7.8.tar.gz
cd libxml2-2.7.8
CFLAGS="$CFLAGS -O" ./configure --host=arm-none-linux-gnueabi --prefix=$DEST --with-zlib=$DEST --without-python
make install

wget http://www.sqlite.org/sqlite-autoconf-3070500.tar.gz
tar zxf sqlite-autoconf-3070500.tar.gz
cd sqlite-autoconf-3070500
./configure --host=arm-none-linux-gnueabi --prefix=$DEST
make install

wget http://sourceforge.net/projects/fuppes/files/fuppes/SVN-660/fuppes-0.660.tar.gz
tar zxf fuppes-0.660.tar.gz
cd fuppes-0.660
PCRE_CFLAGS="-I$DEST/include" PCRE_LIBS="-L$DEST/lib -lpcre" LIBXML_CFLAGS="-I$DEST/include" LIBXML_LIBS="-L$DEST/lib -lxml2 -L$DEST/lib -lz" SQLITE3_CFLAGS="-I$DEST/include" SQLITE3_LIBS="-L$DEST/lib -lsqlite3" ./configure --host=arm-none-linux-gnueabi --prefix=$DEST --with-http-port=38737
make install

So, you can see we are compiling zlib, pcre, libxml2, sqlite3, and fuppes in the same destination folder. The ‘configure’ for FUPPES is really long because we have to specify the paths for each dependencies, even though they are all at the same place. Port 38737 has been chosen for a very geeky reason.

Packaging summary

The following sequence of commands takes you from compiled app to DroboApp:

cd $DEST
nano README.txt
# copy and paste the content of README.txt from below
nano service.sh
# copy and paste the content of service.sh from below
chmod a+x service.sh
tar czfv ../fuppes-0.660.tgz *

Content of README.txt:

Name: fuppes
Description: Free UPnP Entertainement Service
Version: 0.660
Includes: zlib pcre libxml2 sqlite3
Notes: This build does not support transcoding

Edit: I updated the content of service.sh to reflect the fixes done throughout this thread. This version should not cause the Drobo Dashboard to get stuck anymore.

Content of service.sh:

# FUPPES UPnP Media Server

. /etc/service.subr

prog_dir=`dirname \`realpath $0\``




daemon=fuppesd  # daemon executable
daemon_args="--config-file ${config_file} --database-file ${database_file} --vfolder-config-file ${vfolder_file} --temp-dir ${temp_dir} --plugin-dir ${plugin_dir} --log-file ${logfile} --log-level 2"

  # make sure /var/run exists
  if [ ! -d /var/run ]; then
    mkdir -p /var/run

  # make sure ${config_dir} and ${temp_dir} exist
  mkdir -p ${config_dir}
  mkdir -p ${temp_dir}

  # make sure that we have the fuppes user for privilege separation
  id ${user} > /dev/null 2>&1
  if [ 0 -ne $? ]; then
    adduser -S -D -H -h "${config_dir}" -s "/bin/false" ${user}

  #make sure that the folders belongs to fuppes
  chown -R ${user}:${group} ${config_dir}
  chown -R ${user}:${group} ${temp_dir}
  chown ${user}:${group} ${logfile}

  # add fuppes libraries to the path
  export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:${lib_dir}"

  /sbin/start-stop-daemon -S -x ${bin_dir}/${daemon} -c ${fuppes_user}:${fuppes_group} -- ${daemon_args} > /dev/null 2>&1
  pidof ${daemon} > ${pidfile}

  /sbin/start-stop-daemon -K -n ${daemon} > /dev/null 2>&1
  while [ ! -z `pidof ${daemon}` ];
    sleep 1
  rm -f ${pidfile}

case "$1" in
    echo "Usage: $0 [start|stop|restart|status]"
    exit 1

The only interesting thing about this script is that it actually waits for the FUPPES process to die before returning from ‘stop’. This prevents problems while restarting FUPPES. Otherwise, it is the standard safety checks for folder/file presence and access permissions. Be careful with line-breaks when copying this over.

Installation summary

Recommended: If you have DroboAdmin installed, and your FS is called ‘drobo-fs’, click here to install FUPPES (Note: You can also adapt the URLs to match your Drobo’s name or IP address).

If you do not have DroboAdmin, but do not want to use SSH, then do this:
[]Download the FUPPES DroboApp, and place it in the DroboApps share.
]Restart the DroboFS. FUPPES is now available.
If you want to use SSH, then SSH into the DroboFS, then type the following sequence of commands:

cd /mnt/DroboFS/Shares/DroboApps
wget https://sites.google.com/a/droboports.com/www/app-repository/fuppes-0-660/fuppes-0.660.tgz
DroboApps.sh install

FUPPES has been preconfigured to work with both PS3s and Xboxes. However, you still need to edit the file “fuppes-0.660/config/fuppes.cfg” and add ‘dir’ items under the ‘shared_objects’ item. Once that is done you need to restart fuppes and go to the web interface at http://drobo-fs:38737/, options page, and click update database (or click here).


Fantastic ricardo.

I’ll try this out tomorrow when i’m back at home.

Thanks much!


hi im just wondering… is there a reason why the .cfg “needs” to be edited?
legal loophole or just that each xbox and ps3 has a unique code that is needed to be put there?


Huh? You just have to add the folders where your media is. No sneaky legal workarounds here, although I like how you think. :slight_smile:


thanks :slight_smile:
do you know if this will be able to work with my xbox 360, drobo v1 (or drobo v2) and a drobo share?


As it is now, no it won’t work on a DroboShare. However, it should only be a matter of finding the proper path for the DroboApps, and making sure you have the correct cross-compiler toolchain. I know the DroboShare toolchain is available somewhere, but unfortunately I have no idea where to find it.


ok thanks, im guessing if i can get my drobo(s) to be accessible from the xbox or xbox360 then it would be worth hooking up the droboshare…

if not then i guess i’ll just have to get a large usb stick and do it the hard way :slight_smile:

actually, there is a windows media server program… i might try that too.


Uhm, so I installed Fuppes 0.660 on my FS as per the instructions above (downloaded the .TGZ file, dropped it into the DroboApps folder, restarted), and, uh, the Drobo won’t boot properly. It hangs on the “Almost there… Your Drobo FS is in the final stage of starting up. This will only take a few more seconds.”

Anyone have any ideas…? I’m going to be pretty pissed if this app somehow bricked my Drobo…


Are you talking about the Drobo Dashboard? Because that thing does not always work. Can you ping the FS? Can you mount the shares without using the dashboard? If so, restart the Dashboard.

Pissed because…?


i found a tool chain here:


Sorry, not sure how to ping the FS, or how to mount shares w/o using the dashboard… How would I go about doig that?

I, uh, I’m a pretty big noob when it comes to any of this networking/linux/etc. stuff; the reason I went with a Drobo in the first place was because of its “simplicity” and because of the usefulness of the DroboApps (none of which I’ve been able to get working properly…). If I know how to deal with all of the compiling, networking, ssh, dns, etc., I would have just built a Linux box… :stuck_out_tongue:

Uh, because my Drobo won’t work…?[hr]
Do you mean mount the drives directly through Windows (map a network drive)? If so, that doesn’t work. Powering off the Drobo via the dashboard and restarting doesn’t work; uninstalling and re-installing the dashboard doesn’t work.

Starting a thread in the DroboFS area; think it might have something to do with the administrator account, since my girlfriend can still access the shares on her laptop, and my WDTV Live still sees the directories; I just can’t see or mount any drives, make any modifications to the Dashboard settings, etc. on my main computer…


Well, it seems your FS is working if your gf’s laptop can access the shares. If you think fuppes is the problem, you can always access the ‘DroboApps’ share and delete the fuppes-0.660 folder. The scripts that ship with fuppes do nothing that is permanent, so deleting the folder should revert to its previous state.


interesting … i installed through ssh … and this build does indeed kill the DroboDashboard app … you can still get to the tools and data tabs … but the front page hangs as mentioned in an earlier post.

Also … can I just add my dir objects through the config page instead of manually adding them through textedit ?

Is there a way to disable transcoding in the version of Fuppes that comes from the DroboApps page ?? That is why i wanted this version.


That is the weirdest thing I’ve heard about the Dashboard. This version of fuppes opens port 38737 (for streaming) and 1900 (for the UPnP announcements). As far as I can tell, that is it. No other funky business.

The DroboShare main page data comes from port 5000 (you can telnet to it, and you get an XML file back), but it also opens ports 5001 and 5002 (as UDP). My feeling is that the Dashboard broadcasts a “magic” packet on port 5002, the Drobo answers it and the Dashboard then knows that the Drobo is there.

How exactly fuppes could interfere with that is beyond me.

The config page explicitly says it does not work, sooo… sure why not? Give it a try and see if it works. :slight_smile:

Maybe just by changing the config file? If you look further down the config file, you’ll see that there are options to disable transcoding at several spots. I’m not familiar with them, but maybe the fuppes documentation can help?

By the way, did removing this version make the front page of the Dashboard reappear?


Hey Ricardo, I’ve experienced the same problem with the build and yes removing fuppes does fix the dashboard problem. My theory is it has something to do with the way the service starts and it doesn’t ever report its status back to the startup process, so startup is perpetually waiting on it.


Thanks for the feedback, dave. I followed your hunch and I found something that was indeed wrong in service.sh. I used start-stop-daemon because supposedly it makes your life easier by generating all the auxiliary files, such as the pid file. Turns out in the case of fuppes that thing does not work.

If you care to check the generated pid file, you’ll see that the process number is always one off. This means that when you call “./service.sh status” it always tells you that the service is not started. My hunch is that since DroboApps.sh couldn’t reliably get the status of fuppes, it would get stuck trying and trying again to start fuppes.

Long story short: I fixed the pid file generation in service.sh, and now it returns the status correctly. I have replaced the file at http://commondatastorage.googleapis.com/drobofs/fuppes-0.660.tgz with the new version of the script.

To upgrade fuppes, just download the TGZ file and place it in the DroboApps share. Next time you either: (a) reboot the FS, (b) use the DroboAdmin interface, © use the DroboApps.sh command, the new version will replace the old. If you want to make sure, you can also just delete the old version altogether (but you will lose the file index database).

Can anyone test this new version for me? I have a feeling this time it’ll work.


woof. much respect to you guys; most of that was way over my head! thanks for updating, Ricardo, I’ll give this version a try when I get a sec!


Alright, I think I finally figure this one out. After many restarts of my Drobo, fuppes no longer breaks the Dashboard main screen.

The latest version replaces the old one at the same address: http://commondatastorage.googleapis.com/drobofs/fuppes-0.660.tgz

In summary, if service.sh returns any output while starting or stopping the app, the process that initializes the FS stalls, and does not finalize the procedure.

So basically what I did was to remove any and all output to stdout on both “service.sh start” and “service.sh stop”. That did the trick.

I would appreciate a lot if you guys could give it a try, I think this version is a winner.


Hi Ricardo,

I just got a Drobo FS and I am thinking of trying out your updated FUPPES build. Do I need to uninstall version 578 before installing 660? or will it upgrade over it? Thanks!


I have never even installed version 578, so my advice would be yes, uninstall 578 before putting 660 in.