#musicbrainz

but they're always so messed up

releases themselves or just transliteration?

terrible romanization, half the artist names are actually in Japanese (because the damn "change artist credits" option is on by default when renaming artists)

that's more of musicbrainz's problem for either not providing proper batch-editing or musicbrainz's problem for not processing all requests in under .5 a second.

actually, the userscript is explicitly limiting the rate of submitting requests.

derwin: how dare you mention cyrillic here. you heathen!

it could certainly go faster or submit edits in parallel, but that was thought to be impolite :)

In soviet russia Cyrillic mentions you.

flamingspinach: in most cases, I think it's because they were added pre-NGS when there were no artist credits at all

(which doesn't make it less sucky though)

by default, i'm pretty sure the "change artist credits" option only selects artist credits that match the current artist name?

Blah, why does the wiki style level 4 and 5 headings the same?

yes, but often someone will enter a japanese artist by their romanized name first

And 3 for that matter

4 headings should be enough for anyone

2 headings should be enough for anyone, apparently

then as soon as someone comes along and rightly changes it to their real japanese name, all romanized pseudoreleases which originally had the romanized name now have the japanese name

I love how in the default html styles, H6 is smaller than body text :)

Can't use level 1 headings (that’s the mediawiki page title), and level 3–6+ are all the same (on Musicbrainz wiki)

kepstin-work: that's somewhat standartised, really. http://www.w3.org/TR/CSS21/sample.html

so you get 2 heading levels. :-(

well, at least suggestively, not forcibly.

hmm, I didn't realize that h5 was smaller as well.

I guess 0.83 was fairly close :)

hawke_1: they still would appear differently in TOC.

simukis_: yeah, but I care about the page itself, not the ToC

hawke_1: how does the styling on musicbrainz.org/doc compare to on the wiki for headers?

Actually being able to read the page (especially distinguishing the headings from stuff that's just bold) is more important than the ToC.

kepstin-work: not sure.

anyone have the url of that cyrillic edit?

oh, found it

h3 and h4 are the same on /doc, but h5 and h6 are proportionally smaller

which is kind of strange.

hmm, looks worse to me ;) has some nasty grey/blue skin that clashes with my window borders ;)

but it's mostly just that i'm used to using firebug from a while ago

... the built-in tool is missing the network panel too

given how often I'm working with ajax stuff, that network panel is key.

kepstin-work: it isn't missing the networking panel. At least in nightlies and aurora 😃

well, when that makes it to a stable release, I might consider switching :)

(my bitching about the heading styles is because of http://wiki.musicbrainz.org/User:Hawke/Proposal... — note how you can’t tell the difference between level 3, level 4, definitions, and other bold text)

hawke_1: I guess the only solution is to rewrite the page to have fewer heading levels

kepstin-work: I disagree. :-)

I formatted it for a sane table of contents and logical headings. Not my fault the wiki is misconfigured.

I think having more than half the toc length 3 levels deep under a single subheading is a bad sign :)

I suppose if I get rid of 'general principles' and 'guidelines' headings…

still leaves the examples headings looking nasty

jesus christ

why isn't there a retry button on the page!?

hawke_1: the whole concept is nasty anyway too IMO :p

there is one, after it finishes

reosarevok: which concept?

good thing it's not finishing because that "uploading" bar has been sitting there for ten minutes

…of having examples?

hawke_1: no, of doing silly things witht titles

this is truly incredible

you seem to be unclear on how this works

we have *two fucking devs*

if you want things to be perfect

go load an empty page and call it musicbrainz

reosarevok: Most of it isn’t silly, just the 'we need a separate field for everything' bits. IMO.

hawke_1: well, I still find the "'Allegro' is a correct work title" bit incredibly retarded

or you could do a crazy thing and try to fix it instead of being an asshole on IRC :P

reosarevok: eh, I like it — but before it should be recommended we need better work search (i.e. show the title of the parent work)

ianmcorvidae: the first half of his name is 'flaming' ;-)

Show *and* use in search the title of the parent work :p

reosarevok: …yes.

So, lots of work for nothing

Plus a fucking horrible mess for anyone who wants to use the database later

reosarevok: not quite nothing. It does save the occasional hassle of having to edit a bunch of works to change one thing.

ok, it's not so bad, I managed to cancel the stuck upload with ctrl+c in vimperator somehow, and then retried the submission

hawke_1: Well, sure, it just seems the worst possible way to solve that issue

that's quite workable

reosarevok: I think it’s just aiming for the end rather than what we actually have now.

I mean, "detect the same title in child works and offer the user to enter changes to those too" sounds at least as easy to code, and much easier to work with later

I wonder if the "stop button" in vanilla firefox does the same thing (i.e. stops AJAX requests as well as just the page load)

reosarevok: seems like it would be unreliable.

ianmcorvidae: sorry, it was just pretty frustrating

Well, then don't make it an option, just force it :p

It would need one manual change to make them same as the parent for the cases where they were not, sure

now that I've figured out how work around the weird decision not to have individual retry buttons on the bars, it's much nicer than the old CAA uploader

But it would also need one manual change to remove the main work title anyway

Ideally cover art uploads should timeout after a minute with no activity and retry several times before actually failing.

ianmcorvidae: IMHO a core design principle, maybe THE core design principle, for the mbz UI should be, "do not cause a user to lose manually inputted data"

flamingspinach: start writing code

sadly I don't know javascript or perl and don't really have the time to learn them right now, otherwise I would

hi all is there a place where I can log feature requests ?

ah ok

would really like 2 features:

madmouser1: but feel free to discuss them with us here first :)

#1 - a pause or cancel on "save"

madmouser1: for picard?

#2 - a way to save the current status of picard

yes both for picard

I think we already have a ticket for #1, but #2 would be very involved and a lot of work to change :/

hmm, #1

saving 10,000 songs but want to pause the save

madmouser1: please vote on http://tickets.musicbrainz.org/browse/PICARD-288 :)

as it is over a wireless connection currently and want to chagne to a decent wired connection

ah gr8

hmm? during the 'save' process, picard shouldn't need any network access

unless you're saving files on a network file share :)

yeah to make it even worse

source = on nfs share

target = local hdd

fun.

picard stacking up quite well with a 70k collection currently

heh

yeah, people complain about issues with lots of files occasionally, but it tends to not have issues on 64bit linux :)

I'm always amazed at people who open up a bunch at once

I can never get that to work

(on 64bit linux :P)

3.8.0-27-generic #40-Ubuntu SMP Tue Jul 9 00:17:05 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

of course, I also usually just can't process it properly with that many things in there

much easier to load one artist at a time

yeah so the approach I took

the new icons with stars to mark changes in the latest picard git make it easier to manage :)

1) load everything and see what is a perfect match

save them

then the idea is to do dir by dir (A,B etc)

and complete the tagging whilst correcting all the metadata on musicbrainz as I go alng

For importing new stuff, I do it an album at a time.

ah ok

so I might have gone down the wrong avenue here

but don't wanna kill picard now

then Amarok = prefered player

10-20 albums at once is usually fine for me

and I have a solr instance that I use to index all sorts of stuff

but I don't acquire music all that fast :P

music & movies etc

kepstin-work: same

I find myself wishing picard would let me select multiple directories.

ianmcorvidae, yeah this is more a legacy collection than acquiring at a rate

yeah

I still have some untagged stuff, I should really look into that at some point

Leftmost: I drag and drop; that works with multiple directories :)