What: An open-source jukebox.
How: Read on!
Recently I was tasked with creating a jukebox for a party. You can read all about my thoughts on the matter at the link; this article is to provide with the specifics on what software I used, and why.

• The Hardware

  The hardware I chose to use was rather limited in performance, which I think illustrates the efficiency of the software and solution which I designed. Components were as follows:

  • CPU: Pentium II 300Mhz
  • RAM: 384Mb SDRAM
  • Motherboard: Intel i440BX-based
  • Video: S3 Virge DX/3D
  • Storage: 4Gb, 5400RPM ATA HDD
  • Sound: Creative Sound Blaster Live! 5.1

  Obviously, I chose the software based on the known limitations of this hardware. Luckily I had a spare SoundBlaster Live! card, because I don’t think the system would’ve been able to reliably handle the music playback and the overheads of the user interface without it. Of course, whatever hardware you plan on using will probably be much faster. I really did pull this box right out of the stone age.

• The Operating System

  The operating system I chose in order to optimise performance was of course my favourite Linux operating system: Arch Linux. With the kernel, modules and all packages being i686-optimized, it was a good starting point for a “from scratch” jukebox system. More importantly though is that after installation of the base system, I had a basic, but fully working, command line Linux system at my disposal. This meant there were no unnecessary startup services, configurations and other settings which would have been useless, redundant or otherwise a hinderence to performance on this slow system.

• The Desktop Environment

  I chose to install XFCE as the desktop environment because it is the most lightweight of the ‘fully-featured’ environments. I would have liked to use an even lighter option, but of all the specialty and niche options available, I had never used any before, and this build was to be completed in a few hours. So, I chose XFCE which I found behaved no differently to GNOME, but was still relatively responsive despite limited system resources.

  To make the GUI look decent, I had to install a few additional packages that are not explicit dependencies of XFCE. They are listed below.

  • ttf-ms-fonts - the easiest way to make websites look nice is by installing this font package
  • midori - a lightweight, Webkit based browser for GTK+ environments. I chose this over Firefox due to the AJAX-heavy nature of the relaxx player. Webkit is supposedly superior in performance compared to alternatives

• The Webserver

  Now, you may be wondering why, with such a limited system, I was bothering with so many layers of abstraction between music, player and control. The reason is that none of the music playing applications I investigated (and there were quite a few) offered any functionality near that of a simple party jukebox. So, I had to use a web-based front end for mpd called relaxx, both of which I’ll talk about soon.

  The webserver of choice is lighttpd; a light weight simple web server, with all the features (and a lot more) required for what I had in mind.

• The Music Daemon

  Simply put: mpd. Or, Music Player Daemon, as it is less commonly known. I chose this system for multiple reasons: first and foremost, its awesome efficiency. With my 80Gb music collection catalogued and at my immediate disposal, mpd uses approximately three megabytes of system memory. Yes, you read that correctly: three. megabytes. If I go ahead and do something silly like, say, add my entire music collection into a single playlist, that number jumps to a staggering (!!!) eight megabytes. Yeah, I know. It’s ridiculous.

  Secondly, due to the daemon nature of mpd, you can use any frontend you like. You can use a text-based terminal application, you can use a GTK+, Qt or other, or you can use a web-based application, like relaxx player.

• The Music Frontend

  This is the party piece — the piece of the system that everyone gets to see. I chose relaxx player because it had some of the functionality that provides jukebox-like behaviour. Well, kind of. It essentially only had one major feature that made it stand out from a variety of other mpd front-ends: multi-user capability. Essentially, you could lock down certain features of the interface for anonymous users, and require a login for those functions. So, essentially that meant I could specify that anonymous users were only allowed to add songs to the playlist and press play. Meaning you had to log in to delete tracks, stop, pause or rewind, etc.

  The installation of relaxx was straightforward, but I had to install a few extra packages under Arch to make it work properly:

  • Arch wiki: Getting relaxx to work with Arch

  This was the only part of the system which didn’t quite work out so well. Its functionality was great, but due to the fact that it’s programmed entirely in AJAX, the old Pentium II powering the computer couldn’t quite keep up. It was slow to respond and not very nice to use, but it was usable. The music itself never skipped a beat (literally), but the performance of this frontend left something to be desired.

Preferred Editor: Notepad++
Microsoft VBScript: Language Reference
FFDeploy: Automated deployment of Firefox with extensions, themes, and pre-configuration

We don’t have many strict policies regarding installed applications at work; employees have their choice of web browser, for example. When it comes to using our Sharepoint intranet site, this poses a problem. By default Firefox will prompt the user for a username and password when attempting to login to the site, whereas Internet Explorer will automatically use built-in NTLM authentication to authenticate with the site using Active Directory.

Fortunately, Firefox can be setup to do this, however it does require some tweaking of sorts. In the about:config page, you’ll find an option called network.automatic-ntlm-auth.trusted-uris which will enable Firefox to use Windows’ built-in NTLM authentication; allowing users to simply open the Sharepoint site without hassle. Unfortunately, having to set this manually on all the computers on the network that were already using Firefox, plus the additional worry of setting this manually on any new systems or users who decide to use Firefox seemed like an annoying task.

I Googled for a solution, but unfortunately there weren’t any that immediately performed the actions I required. Fortunately though, there does exist a nice utility by the name of FFDeploy which I was able to take parts of — specifically, the VBScript — in order to make possible what I had envisaged.

Essentially, all my script does is check for the existence of a Firefox directory buried within Application Data of the user logging on; if this exists, we copy over a special user preferences file, user.js which overrides or appends to same-values set in the global prefs.js (reference).

The bulk of the script I will keep seperate, as it can be had by downloading FFDeploy. My simple use is as follows:

GetINIString is a function provided by the VBScript in the FFDeploy utility; though it would be relatively straightforward to reconstruct, or write a sub to perform the same action for this specific usage. The line FSO.CopyFile() near the bottom is where we actually copy the user.js file from the server. When the condition isn’t met, we simply exit the if block and do nothing.

Simple, huh?

Preferred Editor: Notepad++
Microsoft VBScript: Language Reference


Sometimes Windows, for reasons unknown, gets confused about printers. This is a problem in an office environment where people are printing almost non-stop. At my work we have about thirty employees, and in approximately six months, they’ve printed over 100 000 pages. I know this because one of the ink cartridges in the printer was recently replaced, and the printer keeps tabs on these kind of stats.

Anyway, an issue we sometimes encounter is that peoples printers simply don’t work. When they’re selected in the print dialogue of whatever application, the application locks up while the operating system tries to remember where the printer really is. I have no idea what causes this; if you do, please drop me a comment. In an effort to avoid this kind of behaviour, I’ve made an addition to our login script that removes and re-installs all the printers on the system. Hopefully by keeping the printers “fresh” in this way, I can avoid having peoples’ time wasted by silly, preventable printer problems.

The Script

Essentially, what the code does is grab the existing printer connections, delete them, and then re-add them. The in-code comments are enough to satisfy anyone with a web browser capable of looking up Microsoft’s VBScript references. What may not be immediately obvious is the last part — the script will re-add them in the order they existed, but without further input, will make the last added printer the default printer. This isn’t what we’re after at my workplace, therefore we need to fix that. However, I’ve just figured that in my particular instance I could re-add the printers in reverse — problem solved!