Upgrading to SlimServer 6.3.1 to 6.5b3
SlimServer 6.3.1 just wasn’t doin’ it for me. Having the server freeze ever few songs was becoming more than a nuisance, it was bad enough that my wife learned to SSH in to the server and restart SlimServer. Nothing special for most computer geeks, but my wife isn’t a comptuter geek. She’s a computer user, but not one that wants to get her hands dirty under the hood. If SlimServer was crashing out often enough that she was going in and restarting the service, it was a bad sign.
In addition to 6.3.1, which SlimDevices lists as the most stable version, they also have 6.5b3 available for download. Yep, beta software. I’m not adverse to trying beta software, but I don’t usually put it in high-use applications and SlimServer is definately high-use around our house. Still, I figured it was worth a try. Based on my experience going from 6.2.2 to 6.3.1, I assumed the upgrade would be trivial. I was wrong.
Assuming the upgrade would be trivial was my first mistake, but not backing up the /usr/local/slimserver directory before the upgrade was the one that really nailed me. No, sweat, I figured, I download the beta release, use the rpm upgrade command, restart the server and find out if there were any improvements. But I was lazy and didn’t backup the slimserver directory before I started. The upgrade went smoothly, with no warnings or errors, and was able to restart SlimServer without any problem. But when I went to view the admin interface, I discovered that my entire library of 7000+ songs was not to be found. A quick check revealed that the music directory /var/music was still intact, so the problem had to do with the new version of SlimServer. No problem, right? Just re-scan the music directory. No joy. It typically takes an hour to re-scan the music, but now it was instant. And it didn’t find any music.
Next, I made the mistake of changing the theme. I wanted to get back to the default theme and clicked on something else, just to see what it looked like. (Not so good.) But I lost all the pull-down menu options so I had no way to control the software through the GUI. Turns out that this is easy enough to overcome, just point a browser to http://slimserver:9000/Default—the “/Default” triggers the default interface. Whew. Now I could control the software, change the music directory and get the configuration settings back to where they should be but I still didn’t have any music.
Back to the problem at hand, no music. The first thing I did was to go in and check the MySQL database I have running behind SlimServer. It was upgraded to 6.5b3, but completely empty. The rows were all there, but no data. No good. Next up, check the SlimServer configuration file, /etc/slimserver.conf, and to verify the database settings. They’re all correct, the right database, right username, right password. WTF? Maybe something with the installation caused one of the files to become corrupt? Now is when I would have gone back to check the files with 6.3.1 but… wait… I didn’t back the damn directory up. At least I had the 6.2.2 backup but I don’t see anything out of the ordinary, the file permissions and ownership are all what they should be. Maybe it’s time to uninstall and reinstall SlimServer.
By this time it was getting pretty late at night, and I made my third mistake. Instead of using rpm to uninstall 6.5b3, I just deleted the directory and tried to re-install from scratch. But rpm didn’t like that—I couldn’t do a clean install because it though the software was already installed and it wouldn’t let me uninstall the software at this point because the directory was deleted. Damn. Damn. Damn. Tried to force the uninstallation, but you can’t force an uninstallation with rpm. But you can force an installation, which is what I ended up doing—deleting the configuration file and any remnants of the old installation, then forcing a complete new installation with 6.5b3. The new installation went through fine, but of course I had to change the configurations back to work with my existing library and SqueezeBox player then re-scan the entire library.
So it took a couple of hours instead of 15 minutes. What went wrong? Aside from my obvious blunders, there seems to be a significant change between 6.3.x and 6.5—SlimServer now includes a separate MySQL installation apart from the MySQL database that I was running before. Why? In the past (6.3.x and earlier) SlimServer relied on a flat file database to store information about songs, albums, artists, etc. Some clever people wrote a hook so that SlimServer would use MySQL instead of this flat file database, after all MySQL can hold more information, and can access it faster, than a flat file. I had been using MySQL behind the scenes since I installed SlimServer back in March but something happened during the upgrade. Now I had two complete MySQL installations and two SlimServer databases, the original that I installed in March that used to hold all SlimServer’s information, and the new one installed during the upgrade. I think this confused the upgrade script. The original configuration file pointed at my old MySQL database, which the upgrade emptied, but the music might have been in the new database which wasn’t being used after the upgrade. Once I re-installed everything, I realized that there was a new instance of MySQL and a new database. After re-scanning the music, the new database was populated with all the missing information.
I can see why SlimDevices decided to bundle a separate installation of MySQL in with SlimServer. It will make it much easier for the average person to get SlimServer up and running quickly and without the legwork to setup MySQL separately, and they’ll have all the benefits of a full MySQL database instead of a flat file. But what I don’t get is why this change isn’t better documented in the upgrade and installation instructions. I’ll admit that I don’t read every set of upgrade instructions in detail, but I didn’t see this mentioned anywhere.
Despite the troubles, I think the upgrade to 6.5b3 was worthwhile. I no longer hear any clicks or static between songs, and the fist second isn’t cut off. More importantly, SlimServer has been absolutely stable. Very nice. Another nice change is that mplayer and flac are no longer needed to play Apple Lossless files. Now SlimServer sends the Apple Lossless out to ALAC for decoding, then on to the SqueezeBox. I think this is a big factor contributing to the system’s stability, and it certainly has decreased CPU utilization.