Linux

I've made some much needed updates to my Music Collection Browser, and thought I'd mention it. It now does a case-insensitive sort of artist names, while ignoring leading special characters ( "'",":","(", etc), as well as throwing away leading "The"s for sorting. This was a big deal to me since it annoyed me every time I had to scroll through 50 The Whoevers to get the band I want.

I also fixed the compilations piece, so linked that back in. I just settled for big ugly links for soundtracks/compilations and individual artists at the top of whichever page is loaded. It sucks but there's really not much of a better way to go.

Now I just have to re-tag a few albums and artists to make things consistent, since some artists have both a "The" and "non-The" variant in the list, but at least now they're right next to each other.

Also, I want to vent about Gracenote. Fucking Gracenote. That is all. ... For many artists who have lots of featured guests, it appends all the "feat. whoever"s to the Artist tag. That is wrong. It should be appended, preferably in parentheses, to the song title itself. It's the only way to maintain a reasonable collection.

Of course, iTunes is stupid enough to create different artist folders based on this idiocy, so now I have 15 Bootsy Collins directories on the FS.

The goal list for this project, after 24 hours, now stands at:

Here's where I justify not crossing the rest of the items off my list:

(1) I've barely bothered to look at iTunes XML files because every time I open one and try to make sense of it, I end up weeping to myself. I think what it's going to end up being is me taking my iTunes DB and munging into either sqlite3 (probably) or MySQL (unlikely), in a stripped down version of the same form that Amarok built its sqlite3 databases. I can't help but think that all the searches I run against the DB would be slow as hell if I was searching an unindexed XML file every time I do anything. So now I just need to write a perl script to parse the iTunes XML database file and puke out SQLite3 in a schema my site already handles.

(2) I don't personally care much about searching. The point of this tool is so that when I'm in a record store or otherwise away from my computers I have quick access to an accurate copy of my CD collection, so I don't purchase dupe CDs or whatever. Or if someone asks me if I've heard of some band I can pull it up. Also, helpful links to YouTube, Wikipedia and Amazon searches for each artist. That's pretty useful really. Searching is irrelevant. The only place it would really be handy is if I send the page to someone else and they want to quickly find an artist or song, to which I say "Suck it up and scroll".

(3) I was thinking of porting it to PHP just because I've written like, 6 lines of PHP and figured I should know it. This thing could stay Perl until Unix time rolls over and I wouldn't care at all.

[music | Nick Cave and the Bad Seeds - All Tomorrows Parties]

This week both Ars Technica and Fark, both of whom get decent traffic, have basically begged users not to use ad blockers. I think people would be less likely to use ad block if your ads didn't kill our browsers, below are some examples.

Just to wrap up, and in case you are lazy like me, give you a whole file worth of subroutines. It's my toolbox and I'm giving it to you. I put this in a secure location and just call it from my other scripts. This makes the code much shorter in my other scripts, nearly auto-commenting, and avoids bugs because if it works in one, it will work in others.

NOTE: This uses the foundations in parts 1, 2 and 3. You can find them here: Part 1 Part 2 Part3

More foundational work. This stuff will configure for your site, and the routines that follow will regularly rely on them.

First, let's declare our modules:

#!/user/bin/perl
use strict;
use Net::LDAP;
use Authen::SASL;
use IO::Socket::SSL;
use Digest::SHA qw/sha1_base64/;
use Mail::Sendmail;
use Crypt::SmbHash;
use CGI;
use CGI qw/:standard/;