#musicbrainz-devel

understood.

single string

k

finalmente...

metadata : audio_properties : bit_rate ?

sure

codec there too?

I still don't know if bit_rate will be a string or a number

I'll try and make it a number

yes on all counts

hmm, I suppse the dsd_* codecs should probably be considered lossless as well

alastairp: all the key checking is implemented and deployed.

and DB purged.

so, you'll be the first one to have a working client, so submit floyd again.

will I have to update my essentia build, or only the acousticbrainz client?

essentia

ruaok: do you know when dmitry will be back? because I can commit something to a branch, but I don't know if he'll want to accept it :)

so we won't have a "final" until he merges everything

not soon, but he says he will be online.

ok

give us a branch to work off for now.

we can pester him to merge this asap.

I think I'll have the patches done in an hour or so.

(hah!)

i trust he doesn't merge on a timely basis then?

nah, he's pretty good at fixing stuff

https://gist.github.com/alastair/951eaa5aef8a87... *dances*

filename vs file_name?

but that looks freaking great.

can never please some people

yeah, and I need to strip dirname too

nah, no problem

k

ok, the home page now has a track count on it.

is it 0?

1

me test case.

which is your old test case.

let me nuke the db again

reset.

ready for your submission. :)

gonna run off and grab dinner.

back to rescue my linux VM and get analyzing my music after that

ruaok: trying to submit but I see nothing in the db

and requests isn't throwing an error, so I guess you're returning 200 anwyay

hmm

if I use this virtualenv thing, will those commands only install it within the directory I say?

yes

oh. I had filename in properties, not tags

http500!

ok. we're waiting on rob to fix the server now, but after that it'll work

from the new branch I posted

nikki has changed the topic to: Freeze week | Agenda: general discussion, making more edit types autoedits + mbs-3462 (nikki), ie8 (nikki)

ruaok: So we can go crazy with the AB client now?

Freso: net quite yet.

alastairp: lemme see.

alastairp: ping

hi

does the key lossless only get submitted for lossless files?

so, I had a few bugs in my doc, but I think I fixed them

oh

no. maybe I'm not submitting it...?

I'm using it but not requiring it.

ah

you're not.

:)

should I fix my code or do you want to fix your side?

read: should it be required or optional?

I'll fix it

it should be required

k

fixed and deployed.

features["metadata"]["audio_properties"]["lossless"] = lossless

it should not properly complain

I /am/ adding it

your error messages are in html

not sure if that's something you want to keep

yeah, I hate this setup. :(

in a sense I feel I should return no text.

empty doc.

but that is not nice to api users.

but I hate returning json.

for errors.

ah

your call

its a battle. on one side I want the data I return to be modeled properly.

where are you looking for lossless? because I add it

on the other side I want useful errors.

you can return HTTP error codes and *also* return a JSON body

data['metadata']['audio_properties']['lossless']

I dislike that, but I'll do it.

which would seem to be the correct approach here

anyone have suggesttion for the format of the json?

do you dislike it for a reason? I'm trying to figure out what the issue is you're trying to get past XD

if you have some api arrors which aren't programming errors on the client, you really should return them in some way that can be parsed by the client and displayed to the user in a reasonable fashion.

I dislike putting error messages into JSON.

it conflates the data model with OOB error nonsense.

but really, this isn't about my preferences. I need to STFU and return json.

{ error : "You fucked up." }

that enough?

If that means you return an http error code and a text/plain body with messages on errors, then so be it, just document that.

that's generally the approach I've seen, having { error: whatever }. and I guess I've mostly just assumed the data model doesn't apply for non-200 responses, it's just also-JSON so it doesn't require clients to have multiple parsers

ruaok: I've seen {status: {result: ok/bad, details: blah}, response: {........ }} before

so that errors and real messages have the same format

ruaok: http://www.eurovelo.org/routes/

wow. :)

I could bike home with 4 interchanges. :)

http://www.pirinexus.cat/ is the catalan one

so, are you sure the the lossless key is in your data?

I'm requiring it now if you want to try again

yeah, sorry. I was just cleaning out tabs in order to open more

oh, actually

in the sample I set, no

I just realised, I was dumping the result directly from essentia and didn't add everything in

http://acousticbrainz.org/0e11c0fd-a1da-4b88-a4... ok, works with curl

:-)

looks good to me/

ok, trying again client

yep, client works

:-D

and have at it

sigh.

*flask* returns an HTML erorr.

if you send bad JSON, you get an HTML error before I ever get to handle the request.

not much I can do about that.

ok, fuck it.

returning HTML error messages for now.

yeah, no problem

can you sumit a file so I can check something?

no, because my submitter won't resubmit my test album because it's already been sent ;)

nah, give me a sec

moar stuff!

alastairp: you can just delete the log file to resubmit stuff, right?

kepstin-laptop: yep

ruaok: submitting

requests.exceptions.HTTPError: 400 Client Error: BAD REQUEST

can you see the error message that was sent?

let me work out how to do that

<p>key 'metadata : tags : musicbrainz_recordingid' was not found in submitted data.</p>

ok, my bad.

hang on

try again

Mineo: good patch. you beat me to it :)

ruaok: da39a905-7b84-4e2a-bbcf-74de3d6ebd03 just submitted

confirmed

Mineo: can you make it pass os.path.abspath to process_file? because we write it to the log file

statistics haven't updated :(