the boredom of ramfree17

Yesterday pixie, my RPi serving as the torrent/dlna box, stopped responding. Rebooting it doesnt help as it eventually reverts to only having the red LED on which I have started to interpret as the system is not yet booted.

I pulled pixie out of its nook and hooked it to my monitor before rebooting it. It showed that the boot process is encountering errors when reading from the SD card. The process stopped while asking for the root password to start the file check maintenance, or Ctrl-D to continue the boot process. I plugged a keyboard and here lies the conundrum: this is a debian system and I have been administering it as the pi user. I have been relying on the sudo mechanism and never replaced the root password so I cant provide it. That realization blows.

No other recourse now but to pull out the SD card and have the partition checked on my desktop. A “sudo fsck /dev/sdb2 -y” command (because sdb2 is the partition assigned to it by udev) and ten minutes of automated fixing later pixie is back online serving its DLNA goodness.

Now I made sure I have changed the root password so this can be fixed without booting the desktop. Come to think of it, I am doing it also on my Ubuntu desktop.

ciao!

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).

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!

I had some difficulty in locally procuring Raspberry Pis because even if there is a local RS branch, they initially sold a single batch for almost twice the price. When we last checked they are no longer selling them unless we are ordering by the hundreds to make it their while to import it. They said we could order directly from the UK office. Bummer.

Then I heard that Filepp, a colleague from a previous project, is on a short-term assignment in UK. So we grabbed the chance to ask a favor to procure a couple of RPis for us and now they have landed and the cases were given as gifts. (Note: Thank you Filepp. I’ll try not to torture you too much if I get to work with you again. Crap, we know I cant keep that promise ).

RPis come with only the board itself so the buyer needs to buy the case, SD card (for the BIOS and operating system), HDMI/RCA jack for connecting to your TVs or monitor, cables and power supply. The power is supplied via a micro-USB connection but the catch is that the current needs to be about 5V but the kicker is that the amperage should not go down below “.7A”. Most smartphones have charges that output anywhere between .2 to .6A. Tablets usually have chargers that output more than 1A so I had no choice but to buy two outlet adapters from the ever accessible CDR-King:

I still have a couple of spare micro-usb cables and I sacrificed the SD card that I use for my old car’s mp3 transmitter and this is the result:

The next challenge is that I dont have a spare USB keyboard so I had to move my work table around and “untangle” my desktop’s keyboard. After a few grunts this is my reward:

From what I can see, running X with a light desktop manager will have minimal hit, however I was able to max out the CPU cycles by running one of the bundled python games while launching a browser. Not bad for an hour’s work. Next steps are

• hunt down that spare microSD card that used to be in the Tab7.7
• load one of the RPis with the XBMC image
• procure either a compatible USB WLAN adapter or a WDS compatible router so I can cover the TV and Wii downstairs when I place one of the RPis there to function as a media center
• And one of those Rii mini keyboards.
• Wait for the batch of “free time” to be delivered

A slice of Geek heaven.

ciao!

This guide is created to show how to use the SmartBro USB Internet dongle in Ubuntu Linux. The dongle comes with the Windows installer that enables the SmartBro application to be installed in most computers. From within that application the user is able to send and reeive SMS, and connect/disconnect their Internet subscription. It allows more operations like access to the Smart portal but for the duration of this guide only the SMS send/receive and Internet configuration is covered. The instructions should be portable to the plug-it kits of the other telcos.

From my experience, Ubuntu has easily supported the USB dongles and tethering devices as early as Karmic Koala. I no longer have my Sony Ericsson K618i that I just connect via a USB cable to my MSI Wind U100 Netbook so this is what I will use for the guide. My netbook is sporting Natty Narwhal during the time the screenshots are taken.

Lets get cracking. Caveat though that I had to recreate some activities in two different locations so don’t mind the clock too much.

Configuring data connectivity

• Boot into Ubuntu and connect the dongle. Wait for a few second while the system recognizes the device.
• From the system tray, click on the network-manager applet and enable the “Enable Mobile Broadband” option. Select the “Edit Connections…” entry, and add a new entry under the “Mobile Broadband” tab.



• As can be seen below, Ubuntu has already detected the chipset of the USB dongle. Click on the Forward button.



• Select the provider (which in this case is Smart). Click on the Forward button.



• On the billing plan dialog, accept the default selection and click on the Forward button.



• Confirm the summary of the selected settings by clicking the Apply button.



• Visit back the settings of the created connection and ensure that there is no username and password in the Mobile Broadband settings page. Save any changes made and dismiss the wizard to go back to the desktop.



• Click on the network-manager applet and click on the mobile internet entry created above.



• If everything goes well and the signal is strong enough the user should be greeted with an established connection message.



• Click on the network-manager to validate the type of connection.

Configuring SMS capability

The setup above can fail if the SIM card used is of the prepaid type and there is no credit loaded on the account. SMART imposes a Php10/30mins rate but there are promos that can be activated by sending some keywords via the SIM account. This implies that the SMS send and received facility should be accessed. Fortunately the wammu project provides this capability.

• Install the wammu application by invoking the command below:

sudo apt-get update && sudo apt-get install wammu -y

• Start the wammu application. If the wammu application doesn’t find its configuration files then it will trigger a wizard for first time-configuration.



• Click on the Next button to start the Wizard and select the following options in the succeeding windows:

– Configuration Style: Guided Configuration
– Configuration type: USB Cable (as the unit is plugged in a USB port)
– Phone Type: None of the above (unless future versions provide an option for the chipset)

– Connection Type: AT based
– Driver to use: Generic AT over serial line or it’s emulation
– Phone device: /dev/ttyUSB0


The above part is trial and error. If the test doesn’t succeed select the next option. If it succeeds then information about the model of the dongle will be shown. In my experience it is almost always /dev/ttyUSB0 but then I do have another device that emulates a serial connection via USB.

– Complete the remainder of the next dialog windows using the default option.

• Once the wammu phone configuration is done, start accessing the USB dongle by invoking the Phone->Connect menu item.



• Once the dongle is active, test the connectivity by receiving existing messages.



• After the operation succesfully completes, select the Messages item in the left treebox to view all retrieved messages.



• Next is to try the SMS sending capability under the Create menu. The editor is dated compared to the built-in provider interface but it would suffice. In the screenshot below, the bucket promo of Always On is being triggered.



• Check the Sent folder if the message was successfully sent.



• After a few seconds/minutes, retrieve the messages again to check the result of the promo registration.

And that is basically it. The instruction in this guide, with minor tweaks, should be applicable to any of the USB dongle. Enjoy your USB Internet dongle in Linux.

ciao!

Too much tinkering killed the cat. Now I am bummed out.

Time to watch another episode of The Walking Dead to pick myself up.