Tag: torrent

Lately transmission on my RT-N16 has been acting a little too unreliable. Since I have 2 spare Raspberry Pi sitting in my drawer, I’ve decided to start utilizing them as my Bit Torrent client. At the same time, I’ve had plan to turn the Pi into a baby monitor. Great!!! Since the router is not far from the infant bed, I could setup both on the same Pi.

First thing first, is to get the Pi up and running. I chose to use the default Raspbian image as I’m more familiar with Debian and for maximum compatibility, in case I need to compile any software. I won’t go through the setup as there’s plenty of “Getting Started” tutorial online for the famous Raspberry Pi. Since I need to connect a webcam to it, I was guessing I’ll need at least the X11 desktop as it involved video. Also based on my prior experience in video streaming via VLC, which needs to run in a window. With that in mind, and my plan to run this headless, I’ll need to setup a remote desktop next.

TightVNC is the de facto Remote Desktop package for Debian. After doing a little bit of reading, I found that x11vnc is actually a better choice, as it utilized the existing instance of the desktop powering the display, which means less resource hog. Using TightVNC on Linux would be akin to using RDP in windows, though TightVNC behaves as x11vnc when running in windows. Instruction to setup x11vnc can be found here.

Now it’s time to tackle the video streaming. I was in luck this time, as my Sensonic Webcam 8000 works out-of-box with Raspbian, and I found a good alternative to VLC, motion. Although motion was meant to do motion detection, but it also serve MJPEG via it’s built in web server. After following these instruction, all I need to do is to turn off motion detection and my baby monitor is done, yeah!!! Wait, where’s the audio? Well, since I live in a small house, my wife doesn’t need audio streaming, which allows more resources for my torrent client >-)

The video stream default to http://my_raspberry_pi:8081. Testing it on the desktop works flawlessly, but the opposite when viewed from an Android phone. The default Android browser tries to download the file. It does work on Chrome running on my SGS3, but it’s too heavy to be installed on my wife’s Xperia Mini. I then downloaded a few popular browsers and non of them work with the stream. Later on I found out that MJPEG is not supported oob in Android, bummer. Luckily I found an app called Mjpeg Viewer. Simply key in the URL and “click” Show. Voila! No complicated configuration or lengthy trial and error.

Now it’s time to work on my torrent. I ran the Shibby mod of TomotoUSB firmware on my router. It comes with transmission and I’ve downloaded more than 100GB of “stuffs” using this setup, though it has a few glitches which I could bare with, until it time traveled back a month one day. A few of my downloads goes from 100% to less than 20%. Doing a “Verify Local Data” or force recheck is just too taxing for this little 200Mhz CPU, and it crashed transmission repeatedly. Don’t get me wrong, I love this router. It just didn’t do the “extra” that well.

So now I’ll move the “extra” job over to the Pi, with 700MHz CPU, the task of hashing file should be, chestnutty though not peanuts :p. Setting up wasn’t any tougher with these instructions. I only followed the part for transmission and ntfs-3g (Default ntfs driver from the kernel is readonly) and skip the hard drive setup as I’m using my existing torrent drive, a 600GB external hard disk. Automount on Raspbian is helpful too, allowing me to avoid editing the error prone fstab.

To make this copy of transmission recognizing all the previous progress, I need to copy the content of resume and torrents into /var/lib/transmission-daemon/info/. After firing up transmission, it listed all my torrents but all 0% with error “No Data Found”. Weird, so I decided to have a peek into the files inside resume and found that the existing path pointing to the actual file is hardcoded along with some cryptic resume data. I would normally avoid editing hundreds of resume files, but it’s not easy to move the mount point to the expected path, which is /tmp/mnt/Torrent/ while it’s currently mounted at /media/Torrent/. The shortcut to this is to create a shortcut a.k.a symbolic link which I can allow transmission to access all the data via both path.

That only solved 80% of the torrents. What happen to the 20%? It must have been caused by some glitch on transmission with the path pointing to /mnt/Torrent/. Well, another symbolic link to the rescue, and now I have all my torrent back, ready to seed and download. It’s time to go back to the future, by “Verify Local Data”, and sure enough it doesn’t crash this time.

It’s 1am now, time to sleep -_- {zzzzzz

PS:Any veteran linux user would notice a potential problem. No prizes but give it a guess.