» Home Page

Setting up a squeezebox receiver without a controller

I stumbled upon some difficulties when following the instructions on the Net-UDAP page and thought I’ll just write my solution here, in case anyone else encounters similar problems.

Problem: after setting all the required parameters, the squeezebox receiver (SBR) stays in ‘init’-mode, that is, the LED blinks red, totally unimpressed by all configuration attempts.

First of all: if your squeezecenter software, or squeezebox server, or logitech media server (or whatever it’s called this week) is not running on its default port 9000, don’t worry about that, the server address doesn’t accept a port, and the player will find it on its own. Also, you need to set BOTH server_address and squeezecenter_address, so:

set server_address=192.168.1.147 squeezecenter_address=192.168.1.147

and finally, and this is where I got burned: after a firmware reset, you will have to watch out for this:

UDAP [1] (squeezebox 162101)> list
             bridging: 0
             hostname: mute
            interface: 128

The interface is set to 128. If you don’t set this to 1 (which is wired), then the SBR will stay in config mode! After you set it to 1, and the SBR connects to your server (the LED turning white), you should set the interface to 0, and you’ll be fine.

You may or may not encounter the same problem, so YMMV.

deciding on a new general purpose template engine

I’ve been using velocity for a long time and I’ve decided to let it retire. Now the question is what will replace my beloved velocity? And maybe more importantly: Why does it need replacement at all? I will come to that. But first…

(more...)

get rid of groovy recompilation

Compilation time for a groovy script adds a relatively high overhead to the running time of an application that is supposed to run very often. Granted, the GroovyScriptEngine does on-demand recompilation, but the compilation units don’t survive a restart.

I’m working on a project that contains a little command line application that is supposed to run very often. Every overhead adds up costs very quickly. I’ve measured more than a second overhead to compile two very small groovy scripts.

In this entry, we will create a mechanism that stores compiled groovy classes in a temporary directory and reuses them if none of the scripts have any changes.

(more...)

« - previous posts