#musicbrainz

ah, I don't know, do we want to copy anything?

I'm biased, since I wrote that, so I can't answer objectively :)

well, hopefully we won't throw our everything...

biased yes, but you know best in this area :)

as in what do you think works well and what you'd want to rewrite

its clear the aritst and release pages will need to be nearly completely redone.

well, we definitely need a different layout for the release page

the artist page is actually ok as it is, once we get release groups

the artist header doesn't work well with credits though

yes, we need to get rid of that

slightly OT... are you waiting for the start of SoC to start hacking on NGS?

MBChatLogger: off

is not logging

is logging

hi murdos!

hey

but at least it has been clear to me that I need to learn a lot more to qualify

hey luks: For the ISRC table, mimicking PUID, do you see a reason why we need a join table like puid_join?

If an Amzon listing has all the right tracks but in the wrong order, do I count that as the correct ASIN? I suspect an Amazon data entry monkey has got their track listing muddled

I get the impression that | id, FK to track, ISRC | is all we need.

if we don't need any oother metadata abgout the isrc, then one table should be enough

I can't think of anything.

lookup is not too relevant.

client version doesn't apply.

we might want to track the origin of the isrc, maybe

as most of them are probably going to be submitted automatically

but thats just anohter column on table ISRC, right?

hm, yes, that would actually work better than in a spearate table

source? origin?

[22:56]<ruaok>lookup is not too relevant. <= do you mean lookup by ISRC?

murdos: counting how many times an ISRC has been looked up.

lookup by ISRC is obviously important. :)

oh... right

sure :)

table isrc: http://musicbrainz.pastebin.com/m67c42591

thoughts?

modpending?

oh yeah.

man, we need to pull all those out into a separate table.

and ISRC is not CHAR(36) :)

oops. do you know what it is?

not sure

ah, 12 characters

12 charaters.

according to wikipedia

Bleh.

chefkoch_ is now known as chefkoch

hmm, we even might want to track the parts of an ISRC separately

like country?

yes, or registrant

I don't know yet what for, but it seems it could be useful for somebody some day

It's country, registrant, year, and numeric id iirc.

Those being 2, 3, 2, 5 chars in length.

I'd be inclined to add some meta index table then, rather than now.

ok

aCiD2`: we badly need tests :(

see github code review

write some

what bought that up :)

luks: what's the point if ngs is just gonna rip the whole current object model out

pronik: = is valid

I don't know, but if pronik wants tests :)

:)

aCiD2`: sure?

pretty certain

are those up on test?

yup, sohuld be

pronik: how about now, I'll add stricter TT checks, and write Test::WWW::Mechanize tests that do a get request on all pages, and ensure at least that they return sucessful

you could, but I'd prefer something with workflow along the way, selenium for example

test::more with selenium should suffice for the start

When catalyst debug mode is on, I'll tell TT to be very strict, and I'll also use Catalyst::View::XHTML instead of Catalyst::View::TT (which forces serving as application/xhtml)

no, selenium is for javascript

I'm not using that for HTTP tests

www::mechanize::catalyst doesn't even need a server, it's the best way to test this

selenium is rather for site usability, but if you want to just find 503s the other stuff might be fine

as long as those are tap-tests, I don't care :)

Anyone have a good suggestion where to paste up image scans of album back as corroboration for MB edit?

Hopefully, something as convenient as patebin?

s/pate/paste/

thoughts?

aCiD2`: test seems to work even though http://perldoc.perl.org/perlop.html#Comma-Operator doesn't accept = as a fat comma

because it's not perl

it's template toolkit

ah, could be

I know that wouldn't work in perl :)

ok, then ignore my comments on github

:)

:)

we need tests, if only to stop you criticizing meaninglessly ;)

murdos: sounds sensible, but I know nothing about how it was done before :)

aCiD2`: got me there :)

murdos: I'm not sure about ARs

hehe

I wouldn't count adding a performer credit as an artist change

but on other other hand the performer credit would be a release change

aCiD2`: how it was planned (and failed): http://wiki.musicbrainz.org/?title=Last_Update_...

relationship should probably change the source (ie, it would be a release change)

it needs some more detailed logic

aCiD2`: it depends on the AR, really

yea

there are both directed and undirected ones

and even the direction is not always consistant

luks: more detailed logic: for ARs? or all this update feature?

murdos: for last update triggers based on ARs

based on end point entity type or on some specific AR?

specific AR type :(

ok, I'll postpone that and try later to see how it applies to each AR meaning

what about other cases? I'm a bit hesitant about the "album(.release_group)" case

I have found a release that was not only sold as a single disk, but also as disk 1 of a 2 disc set. Should I clone it so that I can add the (disc 1) suffix?

Munger: no, the disc 2 should be titled using "(bonus disc)"

But it wasn't -- http://trhosking.com/~tim/albumart/00_Untagged/...

Here is disc 1 --- http://musicbrainz.org/album/39727bac-11f4-4394...

Here is disc 2 --- http://musicbrainz.org/album/fd0c1bac-9917-4659...

it doesn't matter, since there's an edition with only the first disc: it's implicitly a bonus disc

murdos: changing album.release_group will possibly change release_group_meta.firstreleasedate, so I'd say it's ok to update the timestamp

ok

btw, what edit type are currently missing for release-groups?

So, I add disc 1 to the first one, which would imply that this was always a 2 disk set.

but propagating release event changes to the label is probably going to cause performance problems, no?

murdos: moving release to a different release group

murdos, That causes horrible problems when tagging

Munger: I would remove the "disc 1" on the first disc

luks: for release event changes to label, I'm not sure... but it makes sense :/

murdos, It doesn't currently have disk 1. The 2nd disc inthe set even has a different title 'Atomix'

murdos: I'd do only the trivial ones for now

I'm not sure it can cause performance problems

I think this could be better done in batches

e.g. hourly from replication packets (another use case for the DB importer from my lucene soc proposal)

hm, and I think PUID changes should not propagate to tracks

murdos, Lok at the front cover of the 2 disc set -- http://trhosking.com/~tim/albumart/00_Untagged/...

I'd expect PUID changes are the most frequent changes in the database

PUID: yes, that's not my plan to do it

I just added them to the list in order to have a complete view of the problem

murdos, As opposed to the single disc --- http://trhosking.com/~tim/albumart/00_Untagged/...

Munger: the second disc is titled "Atomix"?

Correct, but when shipped as a set, the artwork was entirely different. I think this qualifies as 2 releases, even though the track listings are identical on disc 1

Munger: you should read http://wiki.musicbrainz.org/WhatDefinesAUniqueR...

Hmmm. The first disc is just going to have 2 ASINs

that's fine