The Boredom of Ramfree17

Raspberry Media Server is now online

Dec 29

ErinFLOSS, Gadget dlna, floss, raspberry pi, Tech, torrent 2 Comments

Hectic schedule but I finally finished having my own TorrentBox/DLNA/UPnP server out of the Raspberry Pis. One concern that got answered is if the system is usable as a media streaming server as there has been reports of slow throughput since the Pi’s ethernet (network) and USB system share the same memory space. Early on the file I/O throughput on the SD card I am using as the BIOS and operating system is a little bit slow, and as a techie friend (named Gideon[1]) pointed out its the class of the card itself that is the bottleneck.

The instructions are all over the net so Ill just reference the articles I used and add the other stuff I did to make it work on Pixie (the name of this Pi).

Safeguard against future problems
This is an update to the origal post. As can be read from my first mishap with my rpi, having the root user password changed to something you can access is going to be a time saver. Changing the root password (sudo su – ; passwd) and creating a backup of the final configured pi is going to be beneficial when you need it.

Mounting the external file systems
Before I can move all of my torrenting stuff into the Pi I first need to ensure that the partitions of my external USB hard drive is mounted properly, and with the proper file system labels to avoid confusing myself. I used a slightly modified udev automated mounting configuration posted in http://kissmyarch.blogspot.be/2011/10/usb-automount.html

The debian linux base already uses udev and the only change I made is changing the first uncommented line from:

KERNEL!="sd[b-z]*", GOTO="my_media_automount_end"

to

KERNEL!="sd[a-z]*", GOTO="my_media_automount_end"

The single character change is because the USB storage in the Pis will start at sda while the original post assumes that they will start at sdb because sda is already used by the host system. Tested the rules with a short reboot (and because I dont expect Pixie to be operational 24×7) to ensure that the partitions on the external 1TB disk gets mounted properly under /media.

Headless torrent box

I am already using Transmission as my bit torrent client in my desktop. To minimize the learning curve (or so I initially thought) I used the elinux.org torrent setup guide which is pretty straight forward. The guide contains a section on mounting an NTFS drive but I skipped it as I have already configured the Pi to auto-mount its filesystem in the previous section. I also skipped the virtual host configuration because of two reasons:

1. I dont expect to control transmission outside of my home network, and
2. I cant immediately map out that functionality in my router. 😀

This is where most of my time got spent because everytime I access the Transmission web front end I always get a forbidden error message because I am accessing from a machine that is not in the whitelist. I have tried setting the whitelist to a specific IP address or via asterisk masks, or disabling the whitelist altogether but I still cant progress past this error message. I modified the rpc port to another non-standard port but the front end still listens on the default 9091. Then it dawned on me that IT was using another config file somewhere rather the one in /etc/transmission-daemon/settings.json. Running the command “find / -type f -name “*.json” -exec grep 9091 {} \;” quickly showed that there is another setting file existed in /root/.config/transmission-daemon/settings.json. I stopped the daemon and replaced the rogue settings file with a symlink to the one I maintain in /etc/transmission-daemon/settings.json. I also found another one in /var/lib/transmission-daemon/info/settings.json which I also replaced with a symlink. Everything looked good so I placed the snippet below at the end of the /etc/rc.local to ensure that the transmission daemon only gets started if the FileStorage partition is mounted properly


df -kh | grep FileStorage 1>/dev/null
if [ $? -eq 0 ]
then
transmission-daemon &
fi


Until I rebooted the Pi and the issue came back again. The culprit is that the command I used cannot read the default configuration file in /var/lib/transmission-daemon/info/settings.json and created its own in /.config/transmission-daemon/info/settings.json. There are three ways to fix this: (1) fix the permission going to the of the /var/lib settings file, (2) replace the /.config/ settings file with a symlink, or (3) replace the transmission invoke command in the rc.local file with one that specifies a config directory.

I chickend out and went for #2. 😀 I am convincing myself that this is a temporary fix because I really wanted to validate that I can do the next section.

Stream multimedia!!!!

Streaming the multimedia files directly means less time for me to transfer files into the android devices in the house. This would also minimize the inopportune times that my wife asks me to replenish her playlist. 🙂

The install and configuration is the easiest so far. It involves installing a DLNA server and the MiniDLNA project already has a ready package for the ARM platform so it all boils down to invoking:

$ sudo apt-get install minidlna

and editing /etc/minidlna.conf to reflect all the directories in the attached hard drive that I want to serve in the house. The salient points in my config follow:


media_dir=/var/lib/minidlna
media_dir=V,/media/Multimedia/TV
media_dir=V,/media/Multimedia/Movies
media_dir=A,/media/Multimedia/Audio
media_dir=/media/Multimedia/Streams
media_dir=/media/Multimedia/Comics

media_dir=V,/media/Blackboard/QueueVids
media_dir=V,/media/Blackboard/TV
media_dir=V,/media/Blackboard/tor/complete
media_dir=V,/media/Blackboard/Movies
friendly_name=PixieDust


The local MiniDLNA database needs to be updated after each configuration change and the commands are:


$ sudo service minidlna restart
$ sudo service minidlna force-reload


The force-reload will cause the minidlna.conf file to be re-read and in my case it spewed out errors that some of my defined media directories are not readable. It turned out that all some of the directories are owned by another user. My first impulse was to change the permission bits to 755 but it would have been of no use since the minidlna daemon couldn’t even get past the middle directory. 🙂

After this its a matter of choosing the DLNA client on my Android phone. My Galaxy S2 has a built-in client named AllShare but the first few tries was a bust since it can only play the video files encoded in MP4 format which is barely 20% of all of my video files. I tested various clients before settling with BubbleUPnP combined with MX Player. The BubbleUPnP fetches the files from the DLNA server and hands it off to third party renderers like the MX player. As long as I configure the MX Player to use its software decoder I can even play the MKV files. BubbleUPnP also allows downloading of the content for later playback which is a bonus for my needs.

Not bad for half-a-day’s work and it shows that the RPi can be used as a streaming server. Granted that I dont have anything greater than 720p files but I dont see why it cant do 1080p as well if all are being served within the same home network.

[1] The G+ posting is going to be unviewable for most not on my Plus circles. I dont think Plus allows the changing of a post into a Public setting.

ciao!