The two scripts (browser extension and python script) that I would use both seem like they need to be updated. I opened an issue on the repo, but I dunno if the script author is even around anymore. Can anyone update it so it’s working again? The console says it’s a parsing error. It was really convenient.
1 Like
It seems vgmdb.info server is experiencing some problems (returns 500) and the developer hasn’t fixed it yet. The service has been down for about 2 weeks, but fortunately the server code is open-source so I was able to deploy a backup version here: https://vgmdb-y-young.cloud.okteto.net/. To fix the userscript, you just have to replace the API server address with my backup version, like this:
apiUrl = apiUrl.replace('https://vgmdb.info/', 'https://vgmdb-y-young.cloud.okteto.net/');
Some features like Amazon/Discogs/Spotify cross-linking are unavailable because I didn’t have the API keys, but basic features should work as normal.
8 Likes
Yes, only when it’s down did I realize we rely on it so much. 
2 Likes
Thanks! Do you know how I could set some default languages/countries, and map the Publisher (organization) as the Artist as well? I tried messing with it, but couldn’t get it to map properly. I’d be adding a lot of doujinshi works, so I’d be using the same name for Artist and Label.
artist_credit would map to apiDict.organizations
Country would prefill with Japan (107)
Language would prefill to Japanese (198)
Script would prefill to Japanese (85)
You’ll have to modify the artist_credit field and append a few extra fields:
artist_credit: apiDict.organizations.map(organization => ({
artist_name: organization.names.ja || organization.names.en,
joinphrase: ''
})),
If there’re multiple organizations, you need to handle the join phrase yourself.
// Convenient preset for doujin works
language: "jpn",
script: "Jpan",
country: "JP",
These might not apply to all albums, so be sure do visual check before submit. 
Also I you may change the title field to prioritize the Japanese title:
title: apiDict.names.ja || apiDict.name,
4 Likes
Thanks again for the help!
I noticed that the JSON include the Event information (Comiket, etc.). Would it be possible to include that element in the import under Release Relationships? VGMDB includes both the full name and the initialism/abbreviation, so an autofill should have a high chance of grabbing the correct event if it exists.
If we are updating the VGMdb import script, I’d hardcode the translation from VGMdb currency to MusicBrainz release country.
e.g., a JPY price means the release country is JP.
3 Likes
It’d be nice if the Notes section was also copied over into annotations, but that isn’t stored in the JSON it seems.
I’m afraid not since it’s not possible to set relationships on “add release” page, though I also find it dull to go to “edit relationships” page afterwards and add the event relationship.
1 Like
AFAIK, the notes section usually contains track and release relationships, so it’d be better to add those as relationships directly. Besides, the artist names are often romanized, that doesn’t conform well with MB guidelines.
1 Like
It seems that https://vgmdb.info/ is working again, so you may switch back to that if you want, but anyway I’ll continue to maintain my backup version.
3 Likes
I just now noticed that VGMDB marks catalog spans with a range (ZTTL-0087~96), but the MB style says to split them into individual numbers. Thankfully it looks like MB’s search syntax already lets you search for a range using ~, but the script should probably be adjusted so it splits the catalog numbers into individual ones if possible.
2 Likes
I opened a PR about this, waiting for approval: vgmdb_importer: split multiple catalog numbers by y-young · Pull Request #483 · murdos/musicbrainz-userscripts · GitHub
Thanks. ZTTL-0087~96 seems iffy, almost every time I try it, it won’t split, but then it randomly decided to split once. When I retry it though, it doesn’t split. Can you stress test that one a few times? Maybe the double digits at the end is interrupting the split. Though now I don’t think it’s that, because LC-2049~68 worked fine for me. It seems like this odd one out is causing problems for whatever reason.
Seems it works fine for me, how did you update the script? Have you refresh the page after modifying the script?
That’s confusing, are you saying it behaves randomly?
It might not be the case since I’ve already taken it into consideration. Is there anything else that won’t work?
I installed it directly from your repo. Maybe something on my end is interfering with it. It’s a minor issue and this is the only one I’ve encountered that gives me trouble, so I wouldn’t worry about it for now. Can you test catalog numbers that have letters at the end? PLYM-0002A~B only catches the first number.
I didn’t know there could be letters, I’ll fix that later. 
I think I’ve even seen catalogs that were just words. Not in any rush, thanks for the help so far with this.