#musicbrainz

I will release the MIDlet under GPL or some other nice licence

any freebsd users in the house??

nugator: here you go:

Perfect!

:-)

howzthis look?

i think theyre clunky

djce: I think the amazon branch is ready.

But I'm rethinking the release this sat.

Perhaps we should do it on Feb 15th.

Sat seems a touch soon...

How's OPG/CCCP with it?

OH. Didn't I talk about that yesterday?

We got a solid NO.

oh.

So what's the branch all about then?

Solid NO until the lawyers respond on 13th.

Then... we'll see?

If MB can't then the CCCP is some serious issues.

Presumably the branch can't go live if the answer is No.

And they know that if we won't be allowed to do this, then MB will need to find another hosting solution.

So, I think the answer will be yes.

OK. Let's not merge until we know for sure.

Well, I was hoping to release it, but have a switch that disables the amazon features, but still lets the amazon asin/coverart urls be exposed via the web service.

But that seems pointless. So, lets hold off for now.

But, I should post something about it so people can test it.

I would like to release on the 15th.

Sounds good..

assuming a yes just before?

or in semi-crippled mode?

We release regardless. If the answer is no, we'll cripple it.

And start looking for a new hosting provider. :-(

But I think that is not likely to happen.

so, did we ever come to a conclusion on the 'serious weirdness mail' from whicken?

And when do we load the album release dates from whicken? I was planning on doing that for the release, but if the release is a ways off still we might want to do that before then...

I think we came to a conclusion.

Namely that there are still bugs relating to leading/trailing whitespace,

and still data in the DB with that problem,

so from time to time such errors will show up.

Not sure about the search index problem though;

certainly if the index is broke (for a given artist), then it won't "just fix itself"

not unless the artist name changes.

so, maybe enter an RFE for yalaforge for a tailing whitespace cleanup?

So what Wendell calls "serious weirdness" I might call "unfortunate bugs resulting in inconsistent data views".

yes, but it's not just a cleanup.

First, the server will have to stop accepting the bad data.

input validation as well.

Maybe something to seek out and repair index errors.

i.e. artistwords et al

Knio-school is now known as Knio

djce: got a favor to ask you...

shoot

can you whip up two queries for us?

First, what coverage of artist subscriptions do we have?

how many artists are subbed? and which artists are subbed more than others?

And how many albums have release types?

ok, give me a few minutes

super!

types? as live, single, album, remix?

yes

ok

ok, second one first.

this isn't the simplest way, but it illustrates the point.

create or replace view album_attrs as select id, name, artist, gid, attributes[1] as modpending, attributes[2] as x, attributes[3] as y from album;

select x,y,count(*) from album_attrs group by x,y order by 1,2;

as you'll see from the results it's a bit untidy... sometimes we have (type), sometimes (status), sometimes (type,status) or sometimes (status,type).

and sometimes neither.

you can then count "albums" by, for example: select count(*) from album_attrs where 1 in (x,y);

or "where 2 in"... for singles,etc.

sorry, I'm back.

ok

ok, here's a better SQL query:

do the "create or replace view" above first...

then:

create or replace view album_attrs_2 as select *, case when x between 0 and 99 then x when y between 0 and 99 then y end as reltype, case when x between 100 and 199 then x when y between 100 and 199 then y end as relstatus from album_attrs ;

then you can:

select reltype, count(*) from album_attrs_2 group by reltype order by 2 desc;

select relstatus, count(*) from album_attrs_2 group by relstatus order by 2 desc;

nice!

so I'm seeing that more than half of the albums have a release type.

Am I reading that right?

I think so.

nulls = no data, so that seems right

and most of the releases have a status. not nad.

bad, that is.

ok, on to subscriptions.

on bender:

select a.id, a.name, t.t from artist a, (select artist, count(*) as t from moderator_subscribe_artist group by artist) as t where a.id=t.artist order by 3 desc;

(top subbed artists)

(well all in fact; but most-subbed first).

meager. :-(

NIN is a the top. Go figger.

in histogram form:

select t as subscribers, count(*) as num from (select artist, count(*) as t from moderator_subscribe_artist group by artist) as t group by t order by 1;

(this shows that 6666 artists have one subscriber, 1 artist has 11 etc)

woah.

1 | 1386

5 | 10

6 | 8

7 | 5

that's on test.

then the same on the other axis, by moderator:

select t as artists, count(*) as num from (select moderator, count(*) as t from moderator_subscribe_artist group by moderator) as t group by t order by 1;

we must've gotten more subs.

are you going to keep the views around on bender?

I didn't create them on bender.

I did that here.

ok, back later maybe....

thanks!