A multi‐source seeder for digital releases

MusicBrainz
, , , ,
510

Thanks for the report, it is appreciated. The a-tisket code performs an MB URL search using the artist Spotify/Deezer/iTunes links when loading the release, however this may not always return a valid result due to rate limiting or the search index not being updated (e.g. if the link was recently added). Given that this is a VA release I suspect MB rate limiting is the root cause of the issue.

I appreciate this is annoying but given that MusicBrainz prevents you from submitting duplicate data and it would take a disproportionate amount of time to resolve the issue, I’m afraid this is going to be filed under WONTFIX, as per my original announcement:

3 Likes
511

i don’t know if this has been noted yet, but there seems to be an issue with new itunes releases. for example, i can see the page source for this itunes page says upc":“00602435324920”. so i know this is the correct barcode, but when i plug it in, it still tells me it’s undefined.

i’ve tried this many times with releases from several different labels, and it seems to be an issue with every release that has a 2022 release date. this might not be fixable, but i just wanted to bring it to everyone’s attention.

1 Like
512

No, it’s 00602438665198.

Based on this, it sounds like you need to audit your recent edits to ensure you haven’t assigned incorrect barcodes to releases. I recommend you use GitHub - ToadKing/apple-music-barcode-isrc rather than incorrectly parsing the source code yourself.

7 Likes
513

Hey can anyone get the upc and isrc for this release on qobuz? Album Locked & Loaded (Hardwell Edit), Domeno | Qobuz: download and streaming in high quality.

Thank you in adv.!

514

It’s upthread. Most Apple Music release starting in December no longer work on a-tisket. No idea why this hasn’t been fixed with the lookup using ID’s instead of barcodes. Just like all the other fixes that have been needed for over a year, just go ignored.

1 Like
515

Because of this issue in particular, I’ve started opening Apple Music links manually, parsing the source code for UPCs and pasting those into a-tisket to use as a starting point. Often times it will return only Spotify and Deezer results, and I just add the Apple Music link back in while submitting the release.

516

i don’t understand? why does the wrong barcode show up in the page source?

1 Like
517

It doesn’t. On your link it clearly shows 00602438665198. UPC 00602435324920 is for Worldwide Torture. Look at the release name right before that barcode. The view-source has barcodes for other releases as well. If you use Toad Kings’ script, you’ll get the right one.

1 Like
518

How is this supposed to work? Apple Music IDs are worthless for looking up the same release on other services and if the iTunes API does no longer return results for some barcodes (or barcodes for Apple IDs) than that’s Apple’s fault, not a-tisket’s.

As it has already been mentioned multiple times in this thread, the only long-term solution seems to be using the paid Apple Music API which has two caveats:

  1. It’s not free.
  2. Someone has to rewrite the Apple provider from scratch.

While there have been volunteers to pay for an Apple license, nobody has volunteered to write the code. @atj has been communicating right from the beginning that he would only maintain the existing features and would not write new features, which I totally understand, because it’s a pain to write and test new PHP code for a-tisket (otherwise I might have put more work into it). And as long as nobody else volunteers to do that (or @atj finds the time to finish his Ruby alternative for a-tisket), you’re wasting your time if you’re repeatedly asking for this “fix” that would in fact be a new feature which requires more work.

FYI, the code is already using the Apple ID in favour of the barcode, provided the ID has been submitted with the form:

// The lookup part of the URL, depending on whether there’s an ID or not
$itu_lookup = $params['itu_id']
  ? '/lookup?id='.$params['itu_id'].'&entity=song&limit=2000'
  : '/lookup?upc='.$params['upc'].'&entity=song&limit=2000';
2 Likes
519

This is a volunteer project and you are not a customer. You do not get to demand things like this.

3 Likes
520

Did I demand anything? No. I said there are fixes that have been requested for over a year and no response. It’s about the communication. But it’s been obvious for over a year that changes are needed, but none are ever made. That’s all I’ve said. They weren’t demands. Currently, the mirror omits over 20 countries that Deezer has releases. The original didn’t. Just undo that. I can’t even use the mirror anymore unless it’s an Apple Music only release. And the vast majority of people who do use the mirror for Deezer releases, submit bad data because of this. Why hasn’t this been corrected? To me, omitting over 20 countries per release is a problem.

521

I don’t think it searches through the countries by itu_id instead of upc. That’s where the problem is. I can do lookups on the API and get results whereas a-tisket can’t. For a long time, I thought atj had gone away like marlon, and just ignored this entire thread. Because it was almost a year that he did. I was not ever making demands, but asking for corrections to issues with a-tisket. But never got any responses at all. Not even a I won’t fix that because it would take to much time. Just nothing. So sorry if I thought the suggestions were just being ignored. How else would I take it. But a-tisket mirror (Marlons original works fine, btw) currently gives bad data on Deezer releases and now doesn’t work on Apple Music. Yes, Apple is the reason for the new problem, but if I know the barcodes and ids and put them all in the fields, than it should work. Currently it doesn’t. I give up. I guess the rest on here are ok with bad data. This issue isn’t new. Been here since December. The Deezer issue was first brought up when the mirror began. I understand that he might be worried about re-writing some code only to have Apple next week get rid of the iTunes API altogether. That makes sense to me. I guess I’m just frustrated because of the Deezer issue and lack of communication.

1 Like
522

Yeah, that’s how I’ve been doing it as well. Good for worldwide releases that are on all 3. When it’s an Apple Music only new release though, a-tisket just no longer works, sadly.

1 Like
523

Combining these two statements, my conclusion is that the Apple ID lookup is working if it’s also available on Deezer/Spotify, but not if it’s an Apple Music exclusive release.
I think I’ve never dealt with one, can you give me a quick example? (I know that there might be one buried in the existing hundreds of replies, but it’ll be easier if we are examining this issue based on a new common example.) Are these working on marlonob’s server? I don’t think so, that looks like it’s a general issue with the iTunes API again. It wouldn’t surprise me if the API did not return results for releases which can only be streamed on Apple Music but not purchased on iTunes (or is the shop also called Apple Music today?). If that’s the case we’re back at the previous problem: Someone has to write an Apple Music provider to make this work.

524

No. It’s not working. I just know by looking at the view source (Toad King script) that they have the same barcode. I have to manually add the link to the Apple Music releases when they share the same barcode. It just finds the Spotify & Deezer only. I have a list of counties that are Apple Music only territories (no Spotify or Deezer there) and check on Jaxsta to see if they are there or worst case look them up directly one by one. No, the new releases on Apple Music issue doesn’t work on either site. And on marlon’s if you leave the barcode blank, the whole page blanks out, so it’s actually worse on Apple Music releases. It’s like both have their advantages depending on what you want to do.

1 Like
525

@atj has already explained the reasoning why these countries are omitted, simply because Deezer is not available there. And I don’t remember anyone else disagreeing about the current approach of the mirror. I just had a look at the official list of countries again and I still have no doubt why we shouldn’t trust this list, it has even been updated since the last time I copied the country codes (I’m already preparing a PR for these changes).

Deezer is now available in 187 instead of 186 countries. It’s new in the Dominican Republic (DO), while it is no longer available in Belarus (BY) and Russia (RU). At the same time the API still returns 214 countries for some tracks, including Belarus and Russia, which supports my assumption that this is just a list of countries for which the track has been licensed - but not necessarily where it is available on Deezer.

I guess the only way to get 100% clarity regarding the discrepancy between the official list and the API results would be to write to Deezer support and ask them. You could do that if you’re still not convinced.

I might have been a bit unclear about that in my previous post, but what you describe is exactly what I meant with “is working”:

It’s unfortunate that we have to do this manually, but without an Apple Music provider this is the only solution…

1 Like
526

Because they are available on Deezer there. Marlon’s site works correctly. It is wrong to remove them just because they are not on that list. There has never been a release that I’ve found yet that the Deezer API said had it that Jaxsta didn’t confirm it. I mean if Deezer’s own API says they are there, then they are there. I really don’t see why we just can’t go back to how it is on marlon’s for this. I guess I’ll still use marlon’s for Deezer and the mirror for Apple Music.

527

Sorry but I’ve had enough. @tigerman325 please refrain from using my instance of a-tisket going forward.

I’ve tried to give you the benefit of the doubt over the last year or two, but frankly, I find you to be rude, arrogant and condescending. You have repeatedly made claims which are not only wrong, but easily verifiable, for example:

https://en.deezercommunity.com/deezer-catalogue-45/deezer-in-hong-kong-67687?postid=179248#post179248

At the moment, Deezer isn’t available in HK or mainland China. I’ll forward your feedback to our decision-makers here so that your suggestion has an adequate home.

You also demand that I should just add features like scraping Apple Music webpages for barcodes, as though it were trivial. This demonstrates that you have no understanding on a technical level, given that fetching, parsing and extracting structured data from a web page is much more complex and error prone than querying JSON APIs (which are specifically designed for this purpose). Adding this functionality would be time consuming on a well maintained and architected application, let alone a-tisket.

I stated right from the start that, given the state of the code, I would do my best to keep the site working, fix minor bugs and add minor features, but it was highly unlikely that there would ever be significant changes to the functionality. Being perfectly honest, the comments you have made on this thread have made me less motivated to work on a-tisket. Have you ever considered the idea that spending time and money running and maintaining something for others to use (for free) only to then be treated like an idiot would be quite demoralising? The phrase “you catch more flies with honey than vinegar” comes to mind.

For other users reading this, I’m sorry that the iTunes / Apple Music functionality isn’t fully working at present. This is the result of a change made by Apple, and I believe that they may very well deprecate / retire / nerf the iTunes API in the short to medium term. It may be feasible to add support for Apple Music API in the future once things have settled down, however the new API does not support performing searches by barcode, so it’s highly unlikely that we will ever have the same level of functionality as we did with the iTunes API.

I think it might be a good idea to create a new thread specifically for comments and questions relating to my instance of a-tisket, and leave this one for those who wish to carry on using the original instance.

7 Likes
528

I think you have missed to whole point on the Deezer issue. When a release on marlon’s atisket says it’s in China, but not your mirror, then it’s licensed there in the least. On digital, release countries are where a release is licensed, it’s not where it’s available only on Apple, Deezer & Spotify. If the Deezer API say it’s in China. Then it’s licensed in China. I’ve yet to go to Jaxta on these and look at a distribution list directly from the distributor and not be correct. Why can’t you just not delete countries that an API is giving? And I really didn’t think it was a big deal to ask to use the UPC that Apple is giving. How is a UPC currently found on atisket? It’s not by API, because their API doesn’t give it on any releases. Any release that has it in the .jpg it shows up. It’s because it is found by looking for it in the “.jpg” filename. When Marlon set it up, this was the only way to know a barcode on iTunes. UPCs have been available on the Apple Music pages in the view-source for over a year at least. I made a suggestion that instead of using the “.jpg” filename which may or may not be correct (it has been incorrect many times in the past) to just use the barcode that the “view-source” instead. So, a-tisket already is scraping the Apple Music pages. I’m not suggesting adding that feature, just change the way it currently does scraping of the pages. There should never be an instance anymore when one enters an Apple ID that a barcode isn’t found. If that is a big ask to fix. I’m sorry. You are right. I’m not tech savvy. But this is the first time you have said anything about it. You just ignored it. So, your claim that I’ve asked you to do something radical is wrong. If it’s not an easy fix, then ok. Seems like it would be, but whatever. I’ll just continue to use the “view-source” data. I never said anything about any other aspect of Apple Music pages other than the recent 2022 releases. I asked if we could search by ID instead of UPC, because the APIs can still be used looking up ID instead of UPC. That’s been addressed. While I think for the community, it would be worth a shot to just a least try to see what would would happen if you replaced in the code on the country lookups ID instead of UPC and see if it works. Have you done that? Doesn’t seem like it. All I see is a “well, Apple may do this in the future”. If it’s more detailed than just replacing a simple upc with itu_id, than fine. I feel I’m being attacked because I pointed out flaws, that I know you aren’t 100% responsible for but you ignore. I really, thought you just never looked at this anymore. Why wouldn’t I? You didn’t respond for almost a year. I’ve never treated you like an idiot. If you took it that way, it wasn’t my intent. Not sure why or how you could ever think that. You are obviously very smart. I’ve liked every update you’ve made here. I respect your abilities and if I seem arrogant or condescending by just asking questions or making suggestions, then I don’t even know how to respond to that. That’s all I’ve done. All I’ve said that may remotely sound like an attack is that you’ve ignored suggestions. Which you have. I’ve never made any demands on anyone; I’ve done nothing but ask questions and make suggestions. Once again, thanks for all you’ve done.

1 Like
529

hey! i just wanted to add a bit more insight on the curaçao issue.

i recently pulled my own release from russia and israel (purposely), and it is now suddenly not available in curaçao either. before, it was worldwide, including curaçao, but it’s just been removed with no explanation. i did not exclude curaçao when i pulled them, but spotify just removed it without telling me.

this doesn’t seem to be done by atisket, because it shows up as excluded through the isrc-submit site, too.
https://d.ontun.es/#/explorer/album/1VlH9dYgcC1MFUlH8xFYKg

3 Likes