diary at Telent Netowrks

ANN Sledge (We're lost in music)#

Mon, 08 Dec 2014 07:16:18 +0000

As a person with a large ripped CD collection at home
I want to find and listen to that music from work/on my phone
So that I don't have to talk to the people around me

Sledge is a program that you can run on a computer with

It indexes all the music in the directories you tell it to look in, and then it serves a web page with a search box and some buttons on it, which you can access on a device (computer/phone/tablet/etc) that

It's also the first useful[*] thing I've written using Clojure and Clojurescript and Om . Get it at https://github.com/telent/sledge - no jar file download yet, so you'll need leiningen to build it

[*] defined as: I'm using it.

Standing on the shoulders of github

The heavy lifting was mostly done by others. In addition to the above-mentioned, it uses

Future plans

It's reached MVP, as far as I'm concerned: aside from a couple of bugs it meets my use case. But I do have more planned for it as time permits:

A long long time ago

Previously: "I started looking at all the UPNP/DLNA stuff once for a “copious spare time” project, but I couldn’t help thinking that for most common uses it was surely way over-engineered". In the four years (and two days) since my opinions haven't changed but my tools have.

clj-webdriver with recent Clojure/Firefox#

Sun, 14 Dec 2014 23:06:29 +0000

At the time I write this, the latest release of clj-webdriver is 0.6.1. There are two separate problems with this version, at least as far as I can make out

1) some kind of bug which causes it to fail with the message No such var: clojure.core.cache/through. I haven't tracked this to its root cause but am guessing that the [org.clojure/core.cache "0.5.0"] in clj-webdriver's project.clj was too old a version for some other dependency I am pulling in. I added an explicit [org.clojure/core.cache "0.6.4"] in my project and that seems to have fixed it. See clj-webdriver issue 132

2) The version of Selenium it pulls in is 2.39, which is too old to work properly with even the vaguely recent version of firefox I'm using (33.1.1). Fixing this is again just a matter of adding the more recent versions of Selenium stuffz as explicit dependencies in project.clj

With those two changes clj-webdriver now seems pretty happy and I can start adding some basic smoke tests to Sledge so that I don't have to manually test client-side behaviours whenever I change it

Done: use reference cursors instead of channels for enqueuing/dequeing tracks

Next up: use a channel for xhr search instead of quite so many callbacks

Forthcoming: more work on UI/UX. Add tabs to switch between search view and play queue, unify the different-for-no-good-reason "search" and "filters".

The branch/commit policy from hereon in is

Note that the tests currently depend on having a music collection containing at least four tracks by Queen. This is not ideal and I will fix it some day but in the meantime you'll just have to work around it somehow. Maybe try leaving a USB stick in the car for two weeks or something

Using the HTML5 audio element in Om#

Mon, 15 Dec 2014 00:07:51 +0000

A quick one: if you want to render the HTML5 audio element with Om and do stuff with the events it raises, you will find that the obvious answer is not the right one. Specifically, this doesn't work

(dom/audio #js {:controls true
                :autoPlay true
		:ref "player"
                :src bits
		:onEnded #(do-something)
               })

This might be because React has to be taught about each event that each element can trigger and it doesn't know about this one, or it might be because (it is alleged that) event handling in React is done by placing a single event handler on the top-level component and then expecting events on subelements to bubble up. According to Stack Overflow, audio events don't bubble

The workaround is to add the event listener explicitly in IDidMount, and to call addEventListener with its third parameter true, meaning that the event is captured by the parent before it even gets gets to the sub-element to be swallowed. Like this

core.async with aleph#

Tue, 16 Dec 2014 07:34:29 +0000

(More sledge retrospective)

There was a point about three weeks ago when I thought I had a working audio player, then I tried using it on the phone and I got awkward screeches every thirty seconds through my stereo when I told it to play Ziggy Stardust. No, I'm not talking about David Bowie's voice here, this was genuine "a dog ate my CD" style digital audio corruption. The problem seemed to appear only on Wifi: I could replicate it on my laptop, but it didn't show up on localhost and it didn't show up over an ssh tunnel: I suspect it was something related to buffering/backpressure, and facing the prospect of debugging Java code with locks in it I punted and decided to try switching HTTP server instead.

Documentation on HTTP streaming from core.async channels with Aleph is kind of sparse, at least insofar as it is lacking a simple example of the kind of thing that should work. So here is my simple example of the kind of thing that worked for me: wrap the channel in a call to manifold.stream/->source and make sure that the things received on it are byte-array

(defn transcode-handler [request pathname]
  {:status 200
   :headers {"content-type" "audio/ogg"
             "x-hello" "goodbye"}
   :body (manifold/->source (transcode-chan pathname))})

(from server.clj )

I'm sure there are other things you could put on the channel that would also work, but I don't know what. java.nio.ByteBuffer doesn't seem to be one of them, but I'm only going on git commit history and a very fuzzy recollection of what I was doing that day, it might be that I did something else wrong.