Picard 2.1.3 freezes with slave server

I’ve been running my musicbrainz slave server in a VM for some time now, i use docker with the container from here: https://github.com/linuxserver/docker-musicbrainz

After updating Picard to 2.1.3 the program crashes when i lookup a new album, it disappears leaving no traces. I removed the container and installed the 23.03.19 update, reload the entire DB and Picard still crashes when i try to scan. I tried a clean install of Picard, without any plugins, it didn’t work. Changing Picard’s server to musicbrainz.org, port 443, the program works fine.

I don’t think the container is to blame since when i add a folder i already tagged before, it retrieves the data without a problem. Only when i add new media and click Lookup this happens. The AcousticID scan and the web interface both work fine with my VM. Lookup in browser works, it runs on port 5000, the same port i always used in Picard.

I tried to save a debug log but it just hangs and i have to end with ctrl+break. I don’t think it will help much but here it is: https://pastebin.com/UevLyvYT

The crash is logged on Windows event log:

  • 1000 2 100 0x80000000000000 5795 Application EDITED
  • picard.exe 5b8e995f Qt5Core.dll 5c4f4548 c0000409 0000000000028858 d8 01d4e4ffd9e5f5e1 C:\Program Files\MusicBrainz Picard\picard.exe C:\Program Files\MusicBrainz Picard\Qt5Core.dll 1c1677d3-3234-4850-9086-72acd84871d9

Using Win 10.

Musicbrainz do have thair own containers and this is how I’m running my own instance.

I would not expect using the containers from linuxserver.io to be much different

1 Like

No good idea what is happening here, especially since there seems to be no exception logged at the end. But can you try and see what your local server answers on the following URL:ó eu sei%29 artist%3A%28capital inicial%29 release%3A%28sonora%29 tnum%3A%2811%29 tracks%3A%2811%29 qdur%3A%28106%29

1 Like

Looks like a full response to me.


Looks normal, although this gives me an idea. It could be possible that the server is not responding with JSON data as it should. If you can try the following request using the “curl” tool (you can get it for Windows at https://curl.haxx.se/windows/) and post the output to see if my theory is valid:

curl -X GET -H 'Accept: application/json' -i 'https://musicbrainz.org/ws/2/release/86baa9d0-b610-4721-80ee-bc70f5c0680a'

The expected output here would be JSON data instead of XML.

1 Like

Here are the output from both servers

MYVM:~$ docker exec -it musicbrainz /bin/bash


root@mydockerid:/# curl -X GET -H 'Accept: application/json' -i 'https://musicbrainz.org/ws/2/release/86baa9d0-b610-4721-80ee-bc70f5c0680a'
HTTP/2 200 
date: Thu, 28 Mar 2019 23:27:09 GMT
content-type: application/json; charset=utf-8
content-length: 619
vary: Accept-Encoding
x-ratelimit-limit: 1200
x-ratelimit-remaining: 933
x-ratelimit-reset: 1553815630
server: Plack::Handler::Starlet
etag: "7f29fc59f9c248c5f80e0635af92438b"
access-control-allow-origin: *

{"disambiguation":"","barcode":"5099751351825","release-events":[{"date":"2003-10-13","area":{"sort-name":"Germany","name":"Germany","iso-3166-1-codes":["DE"],"disambiguation":"","id":"85752fda-13c4-31a3-bee5-0e5cb1f51dad"}}],"cover-art-archive":{"front":true,"back":false,"count":1,"artwork":true,"darkened":false},"country":"DE","id":"86baa9d0-b610-4721-80ee-bc70f5c0680a","date":"2003-10-13","packaging-id":null,"status-id":"4e304316-386d-3409-af2e-78857eec5cfe","text-representation":{"language":"eng","script":"Latn"},"status":"Official","packaging":null,"title":"The Focus","quality":"normal","asin":"B0000DELA9"}root@3d2b3e37d3d9:/# 

my virtual machine:

root@mydockerid:/# curl -X GET -H 'Accept: application/json' -i ''
HTTP/1.1 200 OK
Server: nginx/1.14.2
Date: Thu, 28 Mar 2019 23:28:40 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 619
Connection: keep-alive
ETag: "e0089bf4e9497fab66256ba98e45e20c"
Expires: Fri, 29 Mar 2019 00:10:00 GMT
Last-Mod i> fied: Thu, 28 Mar 2019 23:10:00 GMT
Access-Control-Allow-Origin: *


Sorry for late response to this thread but I have recently encountered this issue upon building and connecting a slave musicbrainz server to Picard. The result is the same for the latest available v2.2.3.

I managed to debug the issue to a line of code in Picards metadata.py (line 137 in v2.2.3) that calculates the probability of matches for metadata matches to a given album release. It consistently throws a filetype mismatch error as it trys to divide a (erronously returned) string by a integer when using a slave server.

The issue is undoubtably with the slave server configuration; however it would be an easy fix for the client. The following minor client change results in no further crashes when using existing slave server images/containers.

Change: sim *= (release[‘score’] / 100) to: sim *= (int(release[‘score’]) / 100)

1 Like

This is an interesting finding, and I generally agree that we need to handle this. There are a couple of more places where this score is used and assumed to be an integer. Also if we already deal with the score being sometimes a string we should also consider that it might not be a number at all (int() then raising a ValueError). I’ll take a look, we probably can solve this at a more central point.

However, I would like to find out more why your slave server is behaving differently. Could you show an example result of a simple release search like e.g. https://musicbrainz.org/ws/2/release/?query=neil+young&fmt=json but from your server?

1 Like

I added an issue for this:

1 Like

The fix for this will be in the next release. Thanks a lot for diving into this and finding the issue.

1 Like