The Curious Case of the Box Fan

I bought an ESATA box to replace the crappy Synology RAID thing. It’s a very simple external enclosure with no brains whatsoever, so I can just string four ESATA cables out of the computer in the cupboard to the enclosure, and run standard Linux soft raid.

I installed four 5900RPM Seagate Green disks into the box, which has the snappy name “RaidSonic Stardom ST5610-4S-S2”.

It seems to be working fine.  It’s much snappier than the Synology box, especially when traversing large directories and displaying small pictures, which is something that my music browser does a lot.

But the design of the cooling system is rather odd.

A Box!

There’s a nice and big fan at the back. But it’s rather noisy, so I unscrewed the back cover and removed the fan to see what was going on.  It turns out that the fan blows straight onto that red backplane there.  There are three holes in the backplane, but they are completely covered up by the disks on the other side of the backplane.

It’s rather puzzling.  As far as I can tell, there’s virtually no cooling of the disks themselves with this “design”.  I could detect no draft from the front while the fan was working like crazy at the back.

Oh well.  I guess that this means that the fan is non-functional, so I just unplugged it.  That means that the box is quite silent, which is nice.  And that the disks will die a lot sooner, which isn’t.

All hardware sucks.

Funny Looking Chocolate Not Actually Amusing

Look!  Exciting!

As a rule of thumb, chocolate that looks all fancified often isn’t very good.  (There are a number of exceptions to this rule.)

But this one looked too intriguing for me to pass up.  As you can see, it’s blueberries and lingonberries suspended in white chocolate.  I was wondering how they did that.

And the second picture shows how: They’ve freeze-dried the berries, giving them the approximate texture of crumbly styrofoam.  And the approximate taste of styrofoam, too.  All that remains is a hint of bitterness.

The white chocolate itself isn’t particularly good, either.

Coloured Styrofoam or Freeze-Dried Berries?

I’m now slightly nauseous, and am throwing away the rest of this awful product from Emil Gustavs Chocolates.

More Input Devices

Targus Wireless Presenter and Emacs Volume Control

Finding wireless input devices (for controlling the stereo) that are

1) not too ugly and
2) works reliably and
3) has a range over a few meters

isn’t trivial.  I’ve experimented with a few thingamabobs, and one device I’m pretty satisfied with is the Targus …  er…  I can’t find any model name here.  AMP02EU?  Anyway, it’s a “wireless presenter” (with a laser pointer, so I could entertain a cat if I had a cat, but I don’t *sob*), so, of course, it isn’t really geared towards music playing.  But since, these days, all input devices show up as input devices in Linux, you can use it for whatever you want, with a bit of configuration.

The first thing to do is to put the following in /etc/udev/rules.d/90-itron.rules. It has to be “late” in the udev chain so that other rules don’t overwrite the name we want.

KERNEL==”event*”, BUS==”usb”, SYSFS{idVendor}==”195d”, SYSFS{idProduct}==”7777″, MODE=”0666″, NAME=”input/itron%n”

I chose the name “itron” since that’s what lsusb claims that this device is:

rocket-sam:/etc# lsusb
Bus 002 Device 018: ID 195d:7777 Itron Technology iONE Scorpius wireless keyboard

Now that we know where the device will show up (i.e., /dev/input/itron*), we can route events to the commands we want to execute.  I googled around for a while before deciding to use evrouter, which gives us pretty simple access to all events.

“Itron Powerful Receiver” “” any rel/1/1  “Shell/emacsclient –server-file=rocket-sam –eval ‘(jukebox-decrease-volume)'”
“Itron Powerful Receiver” “” any rel/1/-1  “Shell/emacsclient –server-file=rocket-sam –eval ‘(jukebox-increase-volume)'”
“Itron Powerful Receiver” “” any key/272  “Shell/emacsclient –server-file=rocket-sam –eval ‘(jukebox-pause)'”
“Itron Powerful Receiver” “” any key/104  “Shell/lights 0”
“Itron Powerful Receiver” “” any key/109  “Shell/lights 1”

The first string is the name of the device (yes, that’s what it calls itself.  How masterful).  “rel” is the mouse.  “key” is, er, a key.

So this decreases volume when the mouse goes down, increases when the mouse goes up, pauses the music when I press the big button down, and switches the lights in the room off/on on two of the other buttons.

Which still leaves me with more unused buttons, but I haven’t found a use for them yet.

Then start the event routing in a startup script like so:

$ rm -f /tmp/.evrouter\:0.0
$ /usr/local/src/evrouter-0.4/src/evrouter -f /dev/input/itron*

(The first “rm” is needed because evrouter doesn’t seem to clean up after itself always…)

The only minor problem I now have is that although evrouter picks up the events, they still get passed on to X.  So when I increase the volume, the mouse cursor goes upwards.  I haven’t bothered trying to investigate how to make X ignore certain input units, but if anyone has a pointer to a conf example, please leave a note in the comments.

Live TV!

Still can’t get my camera to focus on the TV

I haven’t really missed having live TV for a decade, but it would be practical if guests wanted to watch the news or something.  So it just occurred to me that doing live TV would be trivial with the current infrastructure.

I have an Emacs (on a machine in the closet) doing the PVR thing, so I just had that one listen to an emacs-server socket, and then just say emacsclient –eval ‘(pvr-choose-channel “CNN”)’ to change the channel.  In addition,  I have an inetd entry to spew out the programme itself:

8040 stream tcp nowait larsi /bin/cat cat /dev/video0

Close-ups work fine, though.

And then some new commands in the Emacs-based movie browser running on my movie browsing machine, and Bob is a close relative.

Everything is on github, as usual.

Digital Audio Extraction from Emacs

Triple Threat
SATA Multilane Connector

So my CD ripping situation is that I put a CD into the CD reading thing there (more about that in a thrilling later blog article), hit a key in Emacs, slap a CD cover onto the scanner, hit another key in Emacs to say that the format is (usually RET), and then inspect the CDDB data that Emacs presents me with, and then I `C-c C-c’, and then I repeat. Since I have three CD players, I can do three CDs in parallel.  The time to process one CD is about two minutes, but with the parallelism going on, I can usually process about twenty CDs in ten minutes.  (Unless the CDDB info is missing and I have to type stuff in.)

I started on this journey in 1997, when mp3s first became viable.  So over the years, I’ve ripped CDs as I bought them.  The earliest mp3-encoded albums started sounding pretty crappy to me, since the early mp3 encoders were pretty crappy.  By 2007, disks had gotten so cheap that it was viable to store the music in a lossless format, so I decided to re-rip them all and store the music in flac.

Now, I have around 4K CDs.  Ripping them all in the traditional, sequential way would just take too long.  I don’t really deal well with repetetive, boring, manual tasks.  And since I had ripped all these CDs before, all the data was already in freedb, so it would be a totally mindless manual job.

So I bought the Addonics cabinet seen above, which has a SATA multilane connector, and put three DVD readers into it.  The only problem in getting it to work reliably was that since all the readers were identical (I mean totally), and the SATA cabinet would bring them up in random order, the poor Linux udev system would name them /dev/scdX at random.  So I would never know how to address the top one until after trying 0, 1, 2.

Until I came up with the brilliant idea of uploading different versions of the available Optiarc firmware on each DVD reader.  They worked just as well with any firmware, but the firmware versions allowed me to create udev rules to differentiate.

scsi 7:0:0:0: CD-ROM            Optiarc  DVD RW AD-7170S  1.02 PQ: 0 ANSI: 5
scsi 5:0:0:0: CD-ROM            Optiarc  DVD RW AD-7170S  1.00 PQ: 0 ANSI: 5
scsi 6:0:0:0: CD-ROM            Optiarc  DVD RW AD-7170S  1.03 PQ: 0 ANSI: 5

With the 3-way parallel ripping setup I think I did all 4K over four nights, if I remember correctly.  While listening to music very loudly, and watching some tv series on DVD (Smallville?), and being totally shit-faced drunk.

Ah, fun times.  At least I think it was fun.  I can’t really remember, for some reason or other.

Anyway, here’s the source code for the Emacs parallel DAE interface.

Useful Consumer Review

I got a new phone today.  The Nokia E7.  And look!  It’s perfect!  It runs Gnus under ssh! Look how pretty Gnus is on the phone!

(The only thing that would have been perfecter would be if it actually ran Emacs on the phone itself, but I guess that’ll have to wait until somebody produces a useful Meego phone.)

I think I’ve got the appliance review thing down now.  This blog will be the next Engadget.

Scanning Record Sleeves

A CD Rippin’ Cupboard with an A3 Scanner

In the continuing story of bits and pieces related to my music playing Emacs@Home installation, here’s the sleeve scanning function.  It’s basically just a tiny data base of common CD/LP/tape sleeve sizes. There’s a lot of sizes, unfortunately.

But what I really wanted to have was something that could detect the image area automatically.  Why doesn’t that exist?  I mean, I couldn’t find it when I googled for it half a decade ago, so it can’t possibly exist now.

It should be pretty easy to detect the image area, you’d think.  Record sleeves are usually kinda square.  So you could use…  rectangle detection…  to find the image. On the other hand, I have CD sleeves that aren’t rectangular.  And I have sleeves that have a square border, and then blackness outside the border, so just detecting the square might over-crop stuff.

I thought about using green screen techniques.  If I painted the inside cover of the scanner cover a particular green colour, then I could probably whip up a technique to…  do something.  But I fear that there’d be colour leakage, with the reflected green light giving off a green tinge to paper sleeves that aren’t very thick.

So, I don’t know.  The result is that sleeves that are half a millimeter larger than the standard sizes I have tend to be slightly over-cropped.  It’s annoying, but not annoying enough that I ever bother to re-scan the offending sleeves.  And hand-editing a scan — you know, in Gimp or something — is so ridiculous that I have to laugh.  Just see:  “Ha ha.”

The ignomity of it all.