I upgraded to 7.1.1 this morning and ran through some new albums. I’m finding that these new albums all lack the URL_DISCOGS_RELEASE_SITE tag, which I used to lookup some info from Discogs. With a bit of clicking, I can now get the tag URL_DISCOGS_ARTIST_SITE but this doesn’t do me much good.
What happened with URL_DISCOGS_RELEASE_SITE?
Where can I download an older version of Jaikoz?
Thanks.
HI, Ive replicated your issue so yes there does seem to be a problem. Ive just tried Jaikoz 7.1 and the problem still persists, do you know what version you were using previously before updating to 7.1.1 ?
Checking the jaikozuser logs, my previous upgrade occurred on Apr 6, 2014. Checking the release dates of the versions, I’d say that I was almost certainly using 6.1.1 until a couple days ago when I upgraded to 7.1.1.
If it matters, I purchased this on Aug 11, 2012, and I started utilizing that tag shortly after that.
Thanks, it still works in 6.2.0 and is broken in 7.0.0 Ive raised http://jthink.net:8081/browse/JAIKOZ-886
I’m working on a new version of Jaikoz at the moment but its a major release that will probably not be available before November, so in the meantime you can download Jaikoz 620 from the links below, although unfortunately this will not work as well for Discogs. The whole purpose of the Jaikoz 7.0.0 release was to improve discogs matching by using my own server which has a copy of the dicogs database rather than disocgs directly. So you may be best to stick with the latest version of Jaikoz and just make use of Correct Metadata from Discogs
OSX
http://jthink.net/jaikoz/jsp/manualdownload620/jaikoz-osx.dmg?val=138
Windows
http://jthink.net/jaikoz/jsp/manualdownload620/jaikoz-windows64.zip?val=138
Linux
http://jthink.net/jaikoz/jsp/manualdownload620/jaikoz-linux.tgz?val=138
Could you walk me through that? Nothing I’m trying gets that tag added to my files.
I just mean run Action:Remote Cotrrect:AutoCorrect Metadata from Discogs, does that not work for you. I just tried it myself and it was fine, are you running against a proper sample or just trying to fix one album.
I have absolutely no idea what you mean by “a proper sample”.
If I select all songs in one album and do what you say I do not get the URL_DISCOGS_RELEASE_SITE tag added.
Nor if I select all songs from 2 albums.
Nor if I select all songs from 1 album and choose Match Songs To One Discogs Release.
Nor if I select all songs from 2 albums and choose Update Metadata From Discogs.
Under no circumstances do I ever get the tag URL_DISCOGS_RELEASE_SITE added to these songs.
I mean try it on more than one album.maybe it cannot find a match for that one album for some reason, but try it on a 100 songs to see if it matches any that shows other whether or not the field ever gets populated.
On my ninth try I finally found an album that got that tag. Turns out that album was scanned with the old version of Jaikoz. So I went hunting through all of my new albums. No URL_DISCOGS_RELEASE_SITE, only URL_DISCOGS_ARTIST_SITE.
So I got a clean version (untouched by any taggers other than the ripper) of an album which worked fine with the old version of Jaikoz. I selected all tracks, right-clicked, chose Action… Remote Correct… Autocorrect Metadat From Discogs. Then I saved changes and opened in MP3Tag to view the extended tags (as MP3Tag calls them). There is no URL_DISCOGS_RELEASE_SITE. Here’s the before-and-after view of the extended tags from 1 song:
Then I did the whole Autocorrect routine that I configured about 2 years ago. Still no URL_DISCOGS_RELEASE_SITE tag. Here’s the before and after of the Autocorrect:
I’m not sure what you’re doing differently to get the
URL_DISCOGS_RELEASE_SITE tag, because all I get is
URL_DISCOGS_ARTIST_SITE
Also note, that using the previous version of Jaikoz failed to get URL_DISCOGS_RELEASE_SITE on only 1 album out of 2,681 albums I’ve scanned with it.
These arent Jaikoz screenshots are they, why arent you looking in jaikoz itself ?
Because I don’t care what’s in Jaikoz’s database, I care about the tag. This is not an issue with whether or not Jaikoz gets the info, the issue is that the tag is not written to the file. As I said in the first post, “… I’m finding that these new albums all lack the URL_DISCOGS_RELEASE_SITE tag…”
Yes, the info is in the database, but not written to the file. So if I view the Relations tab, I can see the “Release Discogs Url” but that information does not get into the file as a tag, so that information is useless to the other programs I use.
URL_DISCOGS_RELEASE_SITE does not exist in the file.
URL_DISCOGS_ARTIST_SITE does exist in the file.
d:\music\FLAC\Blue States\Man Mountain>grep URL_DISCOGS_RELEASE_SITE *
d:\music\FLAC\Blue States\Man Mountain>grep URL_DISCOGS_ARTIST_SITE *
Binary file 01 Metro Sound.flac matches
Binary file 02 What We’ve Won.flac matches
Binary file 03 Colouration.flac matches
Binary file 04 Only Today.flac matches
Binary file 05 Studio 20.flac matches
Binary file 06 Bare Bones.flac matches
Binary file 07 Season Song.flac matches
Binary file 08 Man Mountain.flac matches
Binary file 09 The Winfield Audition.flac matches
Binary file 10 Doublespeak.flac matches
Binary file 11 Halfway Highway.flac matches
Binary file 12 Adrift.flac matches
This is beginning to sound like a tagging problem. Here’s what Jaikoz 6.2.0 did to the file where I posted the screenshots above:
So 7.1.1 Autocorrect added 5 tags, but the same Autocorrect routine in 6.2.0 added about 30.
I misunderstood your problem to be that Jaikoz was not filling in the discogs_release_url field after matching.
But if you open the file in Jaikoz are the tags shown because if they are that means they are within the file itself NOT just the Jaikoz database. If they are in Jaikoz but the application you are viewing them in then that means either Jaikoz is writing them incorrectly or your program is reading them incorrectly. Or possibly there is just some incompatability between the two applications but as nothing has changed recently in the read/write routines and there are no flac options Im unclear what that could be.
Please check and let me know.
I don’t see where these tags could possibly be shown in Jaikoz. If you point me to the screen you desire, I’ll check, but every screen I see does not show these tags at all. None of the ID3 tags show data. View ID3 Merged, View ID3v1, view ID3v2 and the ID3 Edit tabs are all blank - not a single field shows a value. I see that “Metadata browser filter is not active” but I have no idea how to enable this, as it’s not mentioned in the manual, Google does not find that phrase, and I can’t find a place to enable it.
I deleted all version of Jaikoz and removed the directories. I grabbed a clean set of FLACs from 1 album and made two directories - one for version 6.2.20 and another for 7.1.1. I installed 6.2.0 and performed Autocorrect, saved, and viewed the tags in multiple programs. I uninstalled 6.2.0, installed 7.1.1, and performed the identical Autocorrect, saved, and viewed the tags. All other settings are identical in both versions - I made no preference changes at all.
Please open the images and compare. I’ve highlighted the pertinent items in red outline.
6.2.0 - Relations Tab
7.1.1 Relations tab
Note that the 6.2.0 shows Artist Discogs Url as blank, but 7.1.1 shows a value.
6.2.0 Tags from MP3Tag
7.1.1 Tags from MP3Tag
Note that 6.2.0 shows the desired URL_DISCOGS_RELEASE_SITE, but not URL_DISCOGS_ARTIST_URL.
Note that 7.1.1 shows the inverse.
Grep confirms this:
D:\music\__New_Music\620>grep URL_DISCOGS_RELEASE_SITE “01 - World In My Eyes.flac”
Binary file 01 - World In My Eyes.flac matches
D:\music\__New_Music\620>grep URL_DISCOGS_ARTIST_SITE “01 - World In My Eyes.flac”
D:\music\__New_Music\620>cd …\711
D:\music\__New_Music\711>grep URL_DISCOGS_RELEASE_SITE “01 - World In My Eyes.flac”
D:\music\__New_Music\711>grep URL_DISCOGS_ARTIST_SITE “01 - World In My Eyes.flac”
Binary file 01 - World In My Eyes.flac matches
It should be extremely clear - it is to me anyway - that 7.1.1 does not write the URL_DISCOGS_RELEASE_SITE tag to the file, but 6.2.0 does.
The fact that MP3Tag sees all the other tags shows that this is not a tagging incompatibility issue. It can see the tags when they exist, but not if they don’t.
The use of grep confirms this.
If you’re still not convinced of the tagging compatibility, then test this yourself with an MP3 tag reading program of your choosing - other than Jaikoz - and I will install and test this. Again, I am not interested in what’s in Jaikoz’s database, I’m only interested with the tags written to the file, and the regression issue with this feature. I’ve tested this with 2 MP3 tag reading programs, grep, and my own Python script which I’ve been using for the last two years to read this tag.
Simple put, again, 7.1.1 does not write the URL_DISCOGS_RELEASE_SITE tag to the file, but 6.2.0 does.
[quote]If you’re still not convinced of the tagging compatibility, then test this yourself with an MP3 tag reading program of your choosing - other than Jaikoz - and I will install and test this. Again, I am not interested in what’s in Jaikoz’s database, I’m only interested with the tags written to the file, and the regression issue with this feature. I’ve tested this with 2 MP3 tag reading programs, grep, and my own Python script which I’ve been using for the last two years to read this tag.
[/quote]
Please try not to second guess how Jaikoz works if you could just do what I ask its going to be alot easier for me to resolve the issue and you;ll waste less time on it. Now you’ve showed me a screenshot of Jaikoz 7.1.1 showing Url Discogs Release field being populated but its look like that is after doing a match but before saving so its inconclusive. You need to save the changes, close Jaikoz and then reopen if it has a value for that field it is saved, if it isnt it is not.
The we can take it from there.
Please read the post.
“If you point me to the screen you desire, I’ll check…”
This will go a lot faster and you will stop misunderstanding what I’m writing if you actually read what I write.
Is this what you’re looking for? Opened, autocorrected, saved, program closed, reopened, Action…Remote…Autocorrect Discogs, save, close, re-opened.
And NOWHERE did I try to second-guess how Jaikoz works, I’m just telling you what it’s not doing, despite all your disbelief in the fact that it’s no longer doing what older versions did.
In your first thread you said I’m finding that these new albums all lack the URL_DISCOGS_RELEASE_SITE tag, which I used to lookup some info from Discogs which certainly read to me as Jaikoz wasnt filling in the Dicogs ReleaseUrl and when I tested it I found it wasnt and raised the issue I referred to earlier
Then it becomes clearer to me you mean the field in the file itself, but it is still not clear whether this is because Jaikoz is not finding the field and then not saving it or it is finding it but not actually saving it to the file. That is what I was trying to ascertain as your screenhosts and responses did not make this clear.
I do not disbelief in the fact that it’s no longer doing what older versions if I did I would not have raised a JIRA issue. My problem was simply not clear exactly what was going wrong Filling in Fields after matching from Musicbrainz/Dicogs or saving changes to file and certainly the first option has had alot of modiifcations and the second has not.
I have certain tasks to do before the weekend which are higher priority than this so I wont be able to anymor euntil next week - it would be helpful if you email me your support files (Advanced:Create Support FIles) then probably best if you temporarily install the Jaikoz 6.2.0 release as a workaround for now.
Clarified that the issue that I believed to be there was there. A regression in latest version of Jaikoz meant that Update Metadata from Musicbrainz and Correct Metadata from Musicbrainz would never fill in the Discogs Release Url field, this is now fixed.
I havent yet worked out if the alleged second part of the issue is there for Flac files, but can confirm no problem with mp3s
Since I don’t understand your clarification, and I have absolutely no idea what “alleged second part” you’re referring to, I’m not sure that we’re both on the same page about this issue.
At this point, this issue is no longer worth any more of time. Do what you want with it.