Beatport requires barcodes to have the correct zero padding

[kellnerd]

Originally reported on the forums by DenizC:

I’ve seen a few cases where Beatport releases won’t show up on permalinks even after they are found. Usually this occurs when you searched for a release with a link from one of the other platforms, a Beatport equivalent is found, but it won’t be kept for the permalink.

One recent example of mine: Search with Apple Music link
A Beatport release is found among equivalents in other platforms.
Clicking on the Permalink however, the Beatport release isn’t listed, with the red box above explicitly stating that it wasn’t found.

Interestingly, this doesn’t occur when using the Beatport link as the primary search parameter.

The problem is the zero-padding of the barcode, Beatport complains that it couldn’t find the barcode without the leading zero. I only spotted this because the primary source (iTunes and Bandcamp in your examples) has returned the barcode with a leading zero.
If I add the zero-padding to the permalink, it starts working again.

Beatport is yet another provider which doesn’t return search results if the barcode does not have the right amount of zeros :person_facepalming:
Together with the permalink generation, which chooses the encoded GTIN from an arbitrary provider (because in theory they should have the same value and each provider should be able to handle leading zeros) this leads to broken permalinks while the initial lookup worked because it used the GTIN from the primary provider which had the correct number of zeros (by chance).

Ideally the Beatport provider should try multiple barcodes, but Beatport searches are already slow enough as is, so I will probably try to make the permalink generation choose a “better suited” GTIN first, I guess.

[kellnerd]

Ideally the Beatport provider should try multiple barcodes, but Beatport searches are already slow enough as is, so I will probably try to make the permalink generation choose a “better suited” GTIN first, I guess.

I improved the permalink generation in 48c6a0a, which solves the original issue report.

Contributions to make the GTIN search more robust are still welcome once we migrate from the slow HTML scraping approach to a hopefully faster API based implementation.