Lukáš Lalinský

Short version: I'm sorry, but today I had to block some applications from the AcoustID web service. If you were using AcoustID and now get an "invalid API key" error, please contact me.

The long version is that when doing some maintenance today, I've found a few applications that are using the service against the usage guidelines. I knew this would come and I would have to deal with it, I just didn't know when. When starting AcoustID, I have made it really easy to get new API keys, in hope to avoid copying them from other open source applications. I've also made it clear on the website, that the web service is intended for non-commercial use. If you want to use it for commercial purposes, you can contact me and I'm sure we will find a way to make it work, but the web service is by default intended for non-commercial users.

So I had to block a few applications and they should start receiving a HTTP 400 error, with the "invalid API key" error message. In order to avoid this in the future, please register your application on the website and make sure it has a valid e-mail address entered. That way I can contact you in case of a problem, rather than block the application.

I was not very happy when GitHub announced that it discontinues project downloads. I was using GitHub to host compiled packages for Chromaprint and the AcoustID fingerprinter, as well as release tarballs for all AcoustID projects, so I had to start looking for alternatives.

I could continue to use GitHub and host downloads elsewhere, but I like to have all project related files in a central location, so I've decided to move everything from GitHub to Bitbucket. You can now find all AcoustID source code and packages under the AcoustID account on Bitbucket.

I've not yet decided what to do with the GitHub repositories. They are still there for now, but should be considered out of date and not used.

If you are working with a local MusicBrainz database and want to search in it, there aren't that many choices. You can use the internal PostgreSQL full-text search or you can use the official MusicBrainz search server.

I've been playing with the idea of a customizable Solr-based solution for a long time. Creating a simple Solr index with the MusicBrainz data is not hard, but keeping it up to date is more complicated.

The mbslave package now includes a few scripts for creating and updating a Solr search index. See the README file for more information on how to set it up.

There are a few differences compared to the official MusicBrainz search server:

• Everything is in a single index, so there is no need to tell it which entity you are interested in. If you want to restrict the search to a particular entity, use filter query (e.g. fq=kind:artist).
• It's easy to extend the index to include more fields. There is no configuration file for this yet, but you can edit the field definition directly in the source code.
• It doesn't store as much data as the MusicBrainz search server. The intended workflow is to use the database for displaying results.

I wrote it primarily for my own needs, but if it ends up being useful to people, I'll probably make it more configurable and move to a separate package as it does not necessarily depend on mbslave.

Asynchronous importing of user submissions was always a big part of the AcoustID architecture. It makes things much easier to handle on the server side, allows database maintenance without turning the service to read-only mode (just delays the imports) and has many other benefits.

However, people often wanted to get back AcoustIDs for fingerprints they just submitted. It took about a minute to import the fingerprints, so the only solution was to wait a few minutes and then look up the submitted fingerprint to see if it's already imported.

This weekend I've done some changes in how the importing process works and one of the results is that fingerprints are imported within seconds, not minutes, after they are submitted. During normal operation, this means that submitted fingerprints will get imported practically immediately.

This change made it practical for the submission API call to wait a few seconds and collect the results of the import process. There is a new parameter wait which, which allows the client to set a timeout on how long is it willing to wait for the newly imported AcoustIDs. If the fingerprints are imported within the timeout, it will return the AcoustIDs and set the submission status to "imported". Otherwise, it will just return the submission ID and the status as "pending". These IDs can be used to look up the status later.

See the documentation on the submit and submission_status API calls for details.

I upgraded to GNOME 3 just over a week ago and when installing the Feanza icon theme, I noticed that there is a nice Dropbox folder icon included. Nautilus allows you to set icon for any folder, but only lets you select a specific image file, which doesn't look particularly good when scaled.

GNOME icon themes have icons in multiple sizes for each icon, so rather then specific image files, it's better to use generic icon names. I didn't find any GUI to assign an icon name to a folder, but fortunately there is a way to do it using the gvfs-set-attribute tool:

gvfs-set-attribute ~/Dropbox metadata::custom-icon-name folder-dropbox