#musicbrainz-devel

Project musicbrainz-server_beta build #323: SUCCESS in 18 min: http://ci.musicbrainz.org/job/musicbrainz-serve...

Ian McEwen: Flip orientation of event layout template for sidebar changes.

Has someone ( jesus2099 ) written a user-script to link from musicbrainz.org to acousticbrainz.org ? If not, that would be nice!

anyone have the link to the google doc with the acousticbrainz research results to hand?

ruaok: is there any way to cancel recurring monthly donations?

I think I'm missing something

no, the donor themselves needs to cancel it.

that's on the side of payment processor, right?

I guess we don't have to implement an interface for that

correct on both

I won’t likely be back online until much much later today.

heh http://acousticbrains.wix.com/acousticbrains

http://acousticbrainz.org/statistics-graph there's a rather voilent spike, i assume that's a bug?

Well, stats on the homepage are still low

So maybe

Looking at stats, 500k uniques, awesome!

Think I managed to add about 10-15k unique lossless over the past week.

sigh

elasticsearch

just because there's a field that says date - don't expect it's a date and crash when you can't parse it

huh, the track information on http://acousticbrainz.org/898aa05e-bd9b-4ced-97... looks very weird

bad id3 tags? that could never happen! ;)

no id3 tags at all, it's a flac file :P

ok, audio tags

anyway, data on musicbrainz seems "more valid"

yeah, but the artist "[" looks like the json parsing went wrong somewhere

I've also seen that track number issue before.

did you report a bug?

I was planning to fix it myself, so no. :)

I only just got a setup working yesterday.

hm, weird, http://acousticbrainz.org/898aa05e-bd9b-4ced-97... looks totally fine

Mineo: note, it says "artists", not artist

wait, where?

I suspect the workflow is: 1) no key called artist, 2) set artist = "[unknown"], 3) because we thought artist was a list, artist = artist[0]

in the low level

"[unknown]"[0] == "["

and why is http://acousticbrainz.org/898aa05e-bd9b-4ced-97... now looking correct?!

oh, maybe because I ran abzsubmit again to check if it wasn't sending weird data

also, this is interesting now

because we whitelist

so it seems to be a problem with data that was submitted at the very beginning of acousticbrainz because http://acousticbrainz.org/fe65b13e-6edc-40b8-a0... (same album, submitted around the same time) has the problem as well

really? it seems to me like it's a metadata problem

e.g. http://acousticbrainz.org/96685213-a25c-4678-9a... has a tag called "artist", not "artists"

tags are dumped directly from taglib to essentia to the json

https://gist.github.com/mineo/fa9922224d8a29e34914 shows the tags of both files

and I've not retagged them in the last 5 months

let me rebuild essentia to the version used for http://acousticbrainz.org/fe65b13e-6edc-40b8-a0...

wait

are you assuming that you're the only person who's submitted this track?

I've told you. there's a tag called "artists", not artist

we know that we're not showing the "correct" track for a duplicate. it's on the list

ah, yes, I assumed I was the only one that submitted it

good data point for that page: "number of submitted tracks"

that would be great :)

also, what's the scale for the "danceability" value?

0 - we don't know

ok

according to the source code, about 3

annecdotally, 0-1

with wayyyy too many tracks at 1

I'm having errors uploading images to the blog

it looks like it uploads it, then says "an error occurred"

ah, I reloaded the edit page and it's ok

I'm under the impression that caa is no longer included into replication packets since the 17th of november

are you already aware of it ?

in fact a "grep cover" of the latest dbmirror_pending gives no results

ianmcorvidae: Still hunting the edit search performance issue; may I see the output of “SELECT attname, most_common_vals, most_common_freqs, histogram_bounds FROM pg_stats WHERE tablename = 'edit' AND attname IN ('status', 'type')”?

chirlu`: huh. no histogram_bounds at all for status, that seems questionable

rest of it, one sec while I get it somewhere web-accessible

Histogram bounds are only needed for range queries, though, so not really applicable here.

http://mbsandbox.org/~ianmcorvidae/type-status-... anyway

(Though I don’t know why Postgres would know we don’t do range queries on status. :-) )

perhaps it doesn't include a histogram when it has the entire set of possibilities in the most_common_* bits

(which it will there)

Ah, that may be.

Unfortunately, this output doesn’t explain why the problem is there, either. :-(

Or perhaps it does, because the searches currently don’t time out.

Searches for some historic edit types are still slow, because they make up for a relatively high percentage of all edits, so the planner uses a table scan; which takes much longer than estimated because there are no recent edits of this type.

Don’t see a way to improve this without cross-column statistics.

splitting up the edit table is the way to fix that

and using a hierarchy

but that's a pain

ruaok: what's it for?

AB

I used it at strata today.

I needed *something* :)

looks quite nice... certainly better than my BookBrainz logo at http://waveplot.net:3000/

(well, not ascii)

ah ha. thanks yeeeargh!

ruaok: he pm'd them to me, so I dont' think anyone else as seen them :)

oh, heh.

sigh. ok

things to do

hmm - new-release editor seems to have messed up. first it stopped showing correct info for mediums 2&3 (after using track parser for quick update), then it stopped showing any edit info on Edit Note pane

enter edit resulted in "Can't call method "id" on an undefined value at lib/MusicBrainz/Server/Controller/WS/js/Edit.pm line 247, <$fh> line 1. "

and http://musicbrainz.org/release/44a648f3-de51-48...

guess i'll have to start over :-(

ianmcorvidae ruaok bitmap: Ping? Did you see xram's question earlier?