I've remembered that I did have the submission working immediately after upgrading picard yesterday, but sometime yesterday it stopped working and hasn't started since.

<self-congratulatory>On the plus side, at least you can see the error due to my change to the error logging! </self-congratulatory>

Submission is annoying. I'm not sure what to make of it.

I wonder if there is some dodgy data being generated by Picard which the server is rejecting. Can you enable debug logging and then post the log if you get these again? The POST data might be useful?

Indeed I was just able to replicate this when submitting some AcoustIds for files that had broken PUIDs in them.

D: <sip.voidptr object at 0x06F34938> 01:11:58 POST-DATA 'duration.0=258&duration.1=267&format=xml&fingerprint.1=SNIP&puid.0=usicIP%20PUID&mbid.1=dc449136-62d5-48a2-a1c9-b7048441bf03&client=0zClDiGo&mbid.0=33ac17a9-70af-496a-956c-470ae5268f3d&fingerprint.0=SNIP&puid.1=usicIP%20PUID&user=[redacted]'
D: <sip.voidptr object at 0x06F34938> 01:11:58 Last request to ('api.acoustid.org', 80) was 9946 ms ago, starting another one
D: <sip.voidptr object at 0x06F34938> 01:11:58 POST http://api.acoustid.org:80/v2/submit
D: <sip.voidptr object at 0x06F34938> 01:11:58 Received reply for http://api.acoustid.org:80/v2/submit: HTTP 400 (BAD REQUEST)
E: <sip.voidptr object at 0x06F34938> 01:11:58 Network request error for http://api.acoustid.org:80/v2/submit: Error downloading http://api.acoustid.org:80/v2/submit - server replied: BAD REQUEST (QT code 299, HTTP code 400)

Removing the corrupted PUID tags from files allowed it to submit. If you could get the POST data like the above for yours, possibly we can work out what's happening.

This is what I see in my log. It's quote different than yours, am I doing something wrong?

D: <sip.voidptr object at 0x02BAF410> 14:00:37 'Submitting AcoustIDs...'
D: <sip.voidptr object at 0x02BAF410> 14:00:37 POST-DATA 'client=0zClDiGo&user=[redacted]&format=xml'
D: <sip.voidptr object at 0x02BAF410> 14:00:37 Last request to ('api.acoustid.org', 80) was 400155 ms ago, starting another one
D: <sip.voidptr object at 0x02BAF410> 14:00:37 POST http://api.acoustid.org:80/v2/submit
D: <sip.voidptr object at 0x02BAF410> 14:00:37 Received reply for http://api.acoustid.org:80/v2/submit: HTTP 400 (BAD REQUEST)
E: <sip.voidptr object at 0x02BAF410> 14:00:37 Network request error for http://api.acoustid.org:80/v2/submit: Error downloading http://api.acoustid.org:80/v2/submit - server replied: BAD REQUEST (QT code 299, HTTP code 400)
D: <sip.voidptr object at 0x02BAF410> 14:00:37 'AcoustID submission failed: 299'

On a side note, the time stamps in the log are incorrect. It looks like they take on the time that the log window was last opened.

Re:timestamps, Yeah, that's an age-old known issue. There's a ticket in Trac somewhere; probably created by me.

At a guess, I'd say that it's trying to submit empty data? Perhaps the Submit button is incorrectly lighting up... it's probably a bug either way, so we should try and work out what's happening if possible?

I had the QT code 299, HTTP code 400 on every request since launch (even on lookups).

After replicating the request in cURL I noticed that the problem was the Content-Type. I don't know if QT is supposed to figure the content-type out by itself, but for me on Arch Linux 64-bit it just defaulted to application/octet-stream.

since we are actually sending formpart data, we need to use "application/x-www-form-urlencoded".
Setting this content-type for all POST-requests solved all my errors.

The Content-Type issue with Qt 4.8 is already fixed in Git:

https://github.com/musicbrainz/picard/commit/f3e6cde19fc2fbd9843e904772aded0a07364015

I had the same « AcoustID submission failed: 299 » problem today.

1. I scanned PUIDs with server address= musicbrainz.orga to avoid PICARD-134 + PICARD-66 + PICARD-141
2. I switched to AcoustID ( cf. PICARD-67
3. Woops I forgot to submit PUIDs
4. I hit Submit button to submit PUID but I'm now in AcoustID scan mode (shouldn't be a problem)
5. « AcoustID submission failed: 299 »

I think this could be avoided by fixing PICARD-67.

(sorry for the ticket flood)

Still getting this error in Picard 1.0:

E: <sip.voidptr object at 0x0369D1E8> 13:25:34 Network request error for http://api.acoustid.org:80/v2/submit: Error downloading http://api.acoustid.org:80/v2/submit - server replied: BAD REQUEST (QT code 299, HTTP code 400)

From debug log:

D: <sip.voidptr object at 0x06C93A58> 13:41:20 'Submitting AcoustIDs...'
D: <sip.voidptr object at 0x06C93AB8> 13:41:20 POST-DATA 'client=0zClDiGo&user=########&clientversion=1.0&format=xml'
D: <sip.voidptr object at 0x06C93B00> 13:41:20 Last request to ('api.acoustid.org', 80) was 333 ms ago, starting another one
D: <sip.voidptr object at 0x06C93BA8> 13:41:20 POST http://api.acoustid.org:80/v2/submit
D: <sip.voidptr object at 0x06C93BD8> 13:41:21 Received reply for http://api.acoustid.org:80/v2/submit: HTTP 400 (BAD REQUEST)
E: <sip.voidptr object at 0x06C93BF0> 13:41:21 Network request error for http://api.acoustid.org:80/v2/submit: Error downloading http://api.acoustid.org:80/v2/submit - server replied: BAD REQUEST (QT code 299, HTTP code 400)
D: <sip.voidptr object at 0x06C93C20> 13:41:21 'AcoustID submission failed: 299'

(My API key has been munged for privacy.)

I believe this should fix the problem:

https://github.com/musicbrainz/picard/commit/abe70f475aa97e9f887affcd85c0bb3f151c59cd

I see this when I scan, add to an album, delete the album then try and submit.
I'll see if the fix in 1.0.1 fixes it.

This was confirmed to still happen in 1.1:
http://chatlogs.musicbrainz.org/musicbrainz/2012/2012-12/2012-12-29.html#T17-18-13-48177