Monday, January 23, 2017

Install gnomeradio in Ubuntu 16.04

In a previous post, I got my old Haupagge 350 PCI card tuning in local radio stations.  I'm pretty comfortable with comandline programs to get things done but I wanted to find at least one GUI program that actually just worked.


The best option I could find isn't even packaged for Ubuntu 16.04 any more so I installed the Ubuntu 14.04 package instead.

   It sounds wrong to do this, but it does work.

sudo dpkg -i gnomeradio_1.8-2ubuntu32_amd64.deb

Monday, January 16, 2017

Hauppage 350 FM Radio in Linux

I'm not sure why, but lately I've been getting interested in radios.  I was digging through my desk the other day and I stumbled on my old Hauppauge PVR 350 Tuner PCI Card.  

If you're still using Ubuntu 14.04, you'll have to manually load the ivtv drivers to use the card.

However, it turns out that Ubuntu 16.04 recognizes the card and installs the drivers automatically. You only have to install a few programs to control the tuner after that.


'ivtv-radio' has to be my favorite tool I've found so far to listen to the radio.  It simply works will little overhead if you know the stations you should be able to receive.

$ sudo apt-get install ivtv-utils 

$ ivtv-radio -f 99.5set to freq 99.50Running: aplay -f dat < /dev/video24Playing raw data 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
Simply CTRL-C the program and rerun it with the frequency you want to switch too.


This package deserves an honorable mention. It gives you some simple control over the tuner and no direct playback.  It is useful if you want to scan the bands for a station or simply control the tuner and record the station to a file.

Install fmtools:
$ sudo apt-get install fmtools

To scan:
$ fmscan -d /dev/radio0
I found that fmscan missed every station on the band that still came in clear enough in my opinion. The fact is I'm using a simple dipole antenna in the basement of my house might be the problem but I also noticed something in the man page:
If your card's hardware cannot report signal strength, it will not produce useful results.
It might be that the Hauppauge 350 can not report signal strength.

Tune to a station:
$ fm -d /dev/radio0 89.9 65535


Wednesday, January 4, 2017

Copying Files off a Harddrive from a Western Digital NAS

Buddy (names withheld to protect the stupid) came to me with a drive  saying he couldn't get his data off it.   Buckle up folks, this story got convoluted fast, and took me forever to get out of him.  I'll skip the step of turning that into a narrative and save you the trouble of having to read that by giving you the Reader's Digest version.

It all started with his son rage quitting on his laptop and destroying the motherboard in the process.  Turns out that the hard drive took a good hit too and was toast. Buddy had to take the drive to a professional data recovery firm to get his data off the drive.

I suspect that they required him to supply a new hard drive to dump the recovered files on to.  This where it gets interesting technically.  He pulled it out of some sort of Western Digital NAS.  It had a bizarre layout for a single drive NAS:

Layout of the drive from the WD NAS

Who puts a RAID array set on the same drive?  Alas, that was not the weirdest thing.  I knew that the data partition must have been /dev/sde4 as it was the largest.  When I tried to mount /dev/sde4, 'mount' errorred out and the following showed up in my syslog:

[ 1080.819587] EXT4-fs (sde4): bad block size 65536

Turns out that sde4 is actually an EXT3 or EXT4 filesystem with a 64k block size instead of the usual 4K block size.  A bit of googling later I learned that the Linux kernel when running on an x86 platform, can not do a 64k block size.

FUSE to the rescue!

Luckily, there is a work around.  Seems that other owners of the WD NAS's pull the drives out of the NAS for what ever reason and get stuck with this problem.  So with /dev/sde4 being the WD NAS drive and /dev/sdg1 being the new Windows friendly drive here's what was done:

sudo mkdir /mnt/sdg1
sudo mkdir /mnt/sde4
sudo mount /dev/sdg1 /mnt/sdg1
sudo apt install fuseext2
sudo fuseext2 -o ro -o sync_read /dev/sde4 /mnt/sde4
sudo rsync -ahv  --no-perms --no-owner --no-group /mnt/sde4/shares /mnt/sdg1/
I'm going to leave out the commands I used to prepare /dev/sdg which was a new 'WD My Passport'.  I figured it was best to reformat the drive  both so it would be easier to move files on to a VFAT filesystem rather then an NTFS filesystem and there is the odd story about viruses and other junk that is preinstalled on some consumer drives.

Unmounting the drives

Before ripping the Passport drive from the USB port, it's very important to unmount the filesystem. Simply run this:

umount /dev/sdg1
umount /dev/sde4

Problems I encountered

The rsync command did take a while and I did run into some problems with the process just stalling a few times.  'iotop' would show no disk IO and there was no indication anywhere about something had gone wrong.  I'm not sure why that happened but once I added the '--no-' options to the rsync it worked fine.  Perhaps it was luck, perhaps there was something fundamental about that.


While is was a tiny bit of challenge,  it was pretty straight forward to pull the data off the WD NAS drive.   If you find yourself in a similar situation, I hope this helps out.