-
Bug
-
Resolution: Unresolved
-
Normal
-
None
-
2.1.3
-
macOS
This report is based on the experience of the following release: https://musicbrainz.org/release/43c25bd7-91e5-4b2b-a75d-cd6834a2bd70
(By the way, I had the same problem with the following release: https://musicbrainz.org/release/04f3530f-d71a-43b5-b229-609957129c6d – a one track release with a long length)
"Submit AcoustIDs" results with this error message:
E: 03:19:34,841 webservice._handle_reply:383: Network request error for http://api.acoustid.org:80/v2/submit: Error transferring http://api.acoustid.org:80/v2/submit - server replied: BAD REQUEST (QT code 302, HTTP code 400)
E: 03:19:34,844 acoustid.manager.__fingerprint_submission_finished:100: AcoustID: submission failed with error 'Error transferring http://api.acoustid.org:80/v2/submit - server replied: BAD REQUEST': parameter "duration.0" must be a positive integer
The release has 3 tracks, submitting AcoustIDs of the tracks 1 and 3 work, but the track 2 fails. The lengths of the tracks:
1: 7:19:57 = 26397 seconds
2: 9:34:52 = 34492 seconds
3: 5:20:38 = 19238 seconds
I suspect the problem has something to do with the lengths of the tracks and the data type of a parameter.
The magic limit might be 9:06:07 = 32767 seconds. This is the upper value of a 16-bit data type, which has a value range from -32768 to 32767.
The tracks 1 and 3 are below this limit, the track 2 is above this limit.
If my guess is correct, the problem would be the data type of a 16-bit parameter.
Thus, the problem could be solved by changing the data type of the parameter from 16 bits to 32 or 64 bits.
Am I right with my assumption?
By the way, these time conversion tools helped me:
https://www.tools4noobs.com/online_tools/hh_mm_ss_to_seconds
https://www.tools4noobs.com/online_tools/seconds_to_hh_mm_ss
- has related issue
-
PICARD-1688 "Submit AcoustIDs" fails with many tracks
- Closed