It's a great little system, that connects multiple hardware audio players to an open source backend server, written largely in perl, which manages the library, and enables a bunch of plug-ins (eg BBC iPlayer, RSS readers for the hardware displays etc).
It's got a great feature which synchronises multiple players (less good on Wi-Fi, but great on ethernet)
There's a software version of the client which could easily turn a Rasberry Pi with a decent audio card into a headless player, given that Logitech are not going to make any more, I can make them cheaper!
But there's one thing I absolutely despise about it. It's web front end. I spend a HUGE amount of time in front of this thing, and while five years ago, I thought it was just fine, these days it just looks dated.
I have an itch. That itch needs scratching. So I will build my own UI that I actually like.
Bit more technically, here's a list of gripes.
Ajax is so not 2013
My server is tiny, my Mac Book Pro is awesome
Modern browsers have IndexedDB, File APIs etc. I want the app to copy and synchronise the entire database to the client and perform searches locally.
It looks like a piece of $hit
Ok, so I like the iTunes 11 user interface - and I never thought I'd ever like anything about iTunes. In particular I like this view - I like seeing the albums laid out with their covers.
I'm meticulous at making sure that I have album art - though of course with a large library this isn't perfect. I like the way that the colours of the UI match the album cover, it's graphically very pleasing. I want the same thing for my squeezeboxes!
Time to roll my own
- node.js - I'm not much of a perl head, and I want my solution to sit alongside the existing code. I don't want to interfere with the squeezebox server code base. These additional pieces
- nginx with Web Socket support for exposure outside my home network (I use Dynamic DNS)
- Webkit ONLY! Who cares, this is for me, I don't need to support IE. Long term I may well wrap the whole thing in Chromium embedded anyway.
- Web Sockets
- FileReader/FileWriter API. Every cover is cached in the client using persistent storage.
- IndexedDB. The database is (largely) copied from the server to the client on first run
- ColorThief - Thanks @lokesh, that saved me a bunch of time!
- Single page app. No page refreshes
Where am I so far?
Here's what I have so far:
- Library synchronisation. But this needs rework, as it takes three hours at the moment (but only the first time the app is opened)! I think this is because the squeezebox server likes to stat every track when pulling back the list. That sucks.
- Playlist synchronisation.
- Search is super fast - cached in IndexedDB, but loaded entirely into RAM in the client as well. I've observed the app using up to 500MB of memory, but that bothers me none, it doesn't (seem to) leak. I discovered that I built in support for regex searches, by accident, which was nice.
- Aggressive artwork caching using FileAPI
- Drag and drop to change playlist order, or to drag in tracks from albums
- Sweet CSS animations
- 'New' Music view
- Super sexy fullscreen now playing view.
- Might pull in the songkick api.
- Display a view of 'titles' in the search - it's just artists, albums so far (though the search itself is done)
- I scrobble all the tracks I play. I'm going to add the last.fm api to pull this back somehow
- bugs bugs bugs bugs bugs
- Multiple player support
- Saving/Retrieving playlists.