#musicbrainz-devel

oh, and then the sha1 is base64'd

that part is reversible, but the sha1 isn't

ianmcorvidae: It's a long time since I wrote the discid generation code in flactag, so I couldn't remember exactly how it's derived :)

I'd forgotten there was an sha1 in there.

libdiscid is the recommended method anyway

so if you used that you wouldn't have seen that anyway

I might actually be using that thinking about it!

So are you saying that (for example) flactag should be passing in the toc as well when it does the discid lookup?

yes!

Aha, that's new. I'd better add that to my TODO list :)

I don't know when that was added; it's certainly not well-advertised

but you will get better results if you do, for things that don't have discids already

so you should do it :)

Do I know that there's been a fuzzy match in the response? (As opposed to a 'definite' match on the discid)?

bonus: it means we know someone who's using that feature, and provides a route for bug fixes on that feature to end up on our plate :P

not sure

I'm about to go look at the code

Because it'd probably be a good idea for flactag to say "I've found these matches, but they weren't on discid, you might still want to submit the discid"

hm, I don't see anything that would disambiguate

There was talk of putting in a percentage match or something?

I think there was a ticket for it somewhere...

currently it uses a hardcoded value of 10000

the significance of which I don't totally understand because it's passed to the postgresql cube extension

good morning

ianmcorvidae: iirc, that means 10 seconds leeway

yeah

the create_bounding_cube function is rather long

I was working through it slowly :)

adhawkins: one hack, though, is that the discids are returned in the result

adhawkins: so you can assume it's a fuzzy match if the discid you passed in isn't one of the ones in the release

e.g if you look at http://musicbrainz.org/ws/2/discid/I5l9cCSFccLK..., I5l9cCSFccLKFEKS.7wqSZAorPU- is among those returned for the matched medium

since it'll only fall back to the fuzzy match when the discid one fails, that provides a way to tell them apart, though it's a bit hacky I guess :)

As you say, a bit hacky, but would probably work.

reosarevok: another dentist on that post.

The structure of the xml is different for a discid match and a fuzzy match

you have aonly a release-list tag if no match was found

else you have a disc tag

* oliver.g.charles: Remove constraints that haven't been applied to master

* ollie: Revert "Remove constraints that haven't been applied to master"

hrm, site seems slow.

--- zaphod.musicbrainz.org ping statistics ---

that's not good :(

no trouble here

other than with beta, which is perpetually somewhat slow

ianmcorvidae: ok, so hopefully it is "just" a problem with some ISP on the way.

seems to have resolved itself now

17 packets transmitted, 17 received, 0% packet loss, time 16016ms

yes, everything seems fine again.

* warp: MBS-4627, highlight cover art with pending edits, schema changes only.

* ollie: Add track_name != '' constraint which is now live on totoro

grr. one of the tests just stalls.

yay, musicbrainz-data learnt its first test https://github.com/metabrainz/musicbrainz-data/...

what's musicbrainz-data?

nes

Oh :)

Yay then!

FUCKING HELL CARTON

god damnit i can't wait to leave this hell

:D

did it pull in windows 8 as a dependancy or something?

it's sort of my fault because I use perlbrew I guess

which perl is /home/ollie/perl5/perlbrew/perls/perl-5.10.1/bin/perl

but the scripts use /usr/bin/perl

which for some reason makes it stop finding Moose

ok migration running, time for lunch

oh good, the entire migration runs and doesn't ever show exit codes

so it might be failing but chomping up errors, great!

\o/

i think this is when having a huge zfs disk would help and I could just 'rollback' my entire database cluster

btrfs!

kepstin-work: any problems?

you really do like bleeding edge, don't you? :P

snapshots and subvolumes are cool :)

btrfs/zfs would play really nicely with nix

(nixos.org)

ocharles: only problems I had were due to buggy firmware on my hybrid hdd/sdd in my laptop

There was some reason I didn't want to do it when I installed this machine, but I can't remember what it was.

firmware upgrade fixed that :)

btrfs is known to be somewhat slower at most operations than ext4; and has some issues with fsync() in particular

the fsync stuff is supposed to be fixed in linux 3.7

There was a while when btrfs was a pain to boot from if using Umbongo

grub2 supports btrfs reasonably well, but I still recommend having a separate /boot using ext2 or whatever. just makes life simler

what exactly does an issue with fsync mean?

ocharles: fsync() is slow. dpkg and some other programs do a series of fsync() operations one after the other

those applications make the whole fs feel slow.

:)

yeah :)

the patch to improve fsync speeds is known as the "turbo-charge fsync" patch :)

i should resubscribe to lwn

ocharles: saw the 3.6 postgresql article?

was a rather subtle thing involving postgresql's user-space spinlocks and kernel logic for balancing processes between processor cores but trying to keep processes on shared cache if possible.

which ended up bouncing the postgresql threads between cores too much

kepstin-work: yea, I saw that

ollie: Various schema change process improvements:

ruaok: hi

hi

the data imported. all indexes applied cleanly.

Project musicbrainz-server_beta build #187: STILL FAILING in 24 min: http://ci.musicbrainz.org/job/musicbrainz-serve...

ollie: MBS-5290: Add replication support for CAA schema

then the data cleanly migrated.

now dumping the data.

next reimport

I did a full migration today

i imported 1010 in master, and migrated as a standalone in the beta branch

it bought up a few problems, which have now been pushed to beta

I've also done an export while in the beta branch, and that seemed to go ok

there is one 'failure' in the migration, but i've downgraded that to error but carry on (which seems to be the correct thing to do here)