SongKong Jaikoz

SongKong and Jaikoz Music Tagger Community Forum

local correct - artwork issues

I am noticing an issue in 3.8.1 that I did not have in 3.8 or earlier versions. I have all my albums broken down into folders, and each folder as a folder.jpg cover art image in it. Most are around 450px to 500px, though they can vary from 75px to 600px.

I selected all the artwork that was already contained in the id3 tags in jaikoz and deleted it. I then selected all the newly empty Artwork fields and did a Local Correct -> Correct Artwork. This typically will update all the tags with the matching jpg I have in the folders. However since upgrading to 3.8.1, only about 70% of the albums updated. The others did not. I manually double checked the ones that it did not update and verified they had artwork in the same folder as the mp3s. They did, some were low quality as low as 75px x 75px, and some were better quality as high as 500px x 500px.

I also tried exiting and going back in and loading the files and that did not make a difference. On the images that did not update, I verified I could load them in other players, as well as in windows. All the files appear to be good. I verified the preferences, under the Local Correct tab, Artwork Correct tab, and they all appeared to be correct. I did however notice one thing odd. The “Ignore artwork smaller than this (pixels)” slider would let me move it all the way down to 50, but yet after I saved it and went back in, it would default back to the line between 50, and 150, 100?, It wont let me save it to anything below that line.

Any ideas?

Just an update. I uninstalled 3.8.1 and reinstalled 3.8.0 and it appears I am still having the same issues. Though I did not see them previously. I don’t know if there were some files left over from the previous install, or if this was something that was in the earlier version as well, but never manifest itself.

Verifying image sizes, out of the 30 albums that did not update. I show most were around 500x500 with just a handful around 130x130 which would fall under the filter that I can’t update. Also checked all the mp3s, images, and folder permissions and all our readable and writable, none are marked as system, read only, or hidden.

Another update. I can click on the Artwork cell gray tab to bring up the Update Images box. I then click select file, and it brings up the Open box. In that open box the image preview does show up on the right side. I then click on the Open button. A mini thumbnail shows up next to the Select File button in the Update images box, and the drop down shows " Cover (front), but the field in between the thumbnail and the drop down remains blank. I toss in some text into that box, typing in “folder” and then I am able to click on the Add button. It then shows up in left column of the update images box. I then click OK and it shows up in the ID3 Edit and Edit views. So it appears I can manually point it to the file and it will take it, just not auto correct from local correct.

Also another thing I just noticed that I don’t believe I saw previously, is my sorting is not staying the same between the Edit tab view, and the ID3 Edit tab view. For example, the Track No is showing up in Edit as 01-71 and in the ID3 Edit as 71-01. Not a big deal, just haven’t noticed it before.

[quote=greengeek]The “Ignore artwork smaller than this (pixels)” slider would let me move it all the way down to 50, but yet after I saved it and went back in, it would default back to the line between 50, and 150, 100?, It wont let me save it to anything below that line.
[/quote]
Yes there seems to be a bug setting this value to less than a 100 pixels (but images less than this are very low quality).

Yes it would be, this is the description field which is now optional (before 381 you had to enter a value)

You dont need to, you should already be able to click Add

[quote=greengeek]
So it appears I can manually point it to the file and it will take it, just not auto correct from local correct.[/quote]
Hmm, I wonder why - when you run the Local Artwork Correct on the folder what does the console say, doe sthe jaikozdebug0-0.log give any additional info

Dont undertsand because in the Edit tab, there are two fields track no and track total, but in the ID3 edit field both are stored in a single trackno field

[quote]
So it appears I can manually point it to the file and it will take it, just not auto correct from local correct.[/quote]
Hmm, I wonder why - when you run the Local Artwork Correct on the folder what does the console say, does the jaikozdebug0-0.log give any additional info[/quote]
Can you just try recreating the database as described here http://www.jaikoz.net/jaikozforum/posts/list/1246.page
I wonder if the database hasnt been updated properly during upgrade

[quote=paultaylor][quote=greengeek]
A mini thumbnail shows up next to the Select File button in the Update images box, and the drop down shows " Cover (front), but the field in between the thumbnail and the drop down remains blank.
[/quote]
Yes it would be, this is the description field which is now optional (before 381 you had to enter a value)

[/quote]
It wouldn’t take unless there was something in this field, but I am guessing from what you posted here, it was because I was doing more testing after I had already downgraded to 3.8.0.

[quote=paultaylor][quote]
So it appears I can manually point it to the file and it will take it, just not auto correct from local correct.
Hmm, I wonder why - when you run the Local Artwork Correct on the folder what does the console say, does the jaikozdebug0-0.log give any additional info[/quote]
Can you just try recreating the database as described here http://www.jaikoz.net/jaikozforum/posts/list/1246.page
I wonder if the database hasnt been updated properly during upgrade
[/quote]
I uninstalled Jaikoz and did the force uninstall. I then deleted the folder out of my program files. I then went in and cleared out my profile’s temp folder as well as deleted my profile’s jaikoz folder that stores the database to get rid of anything that might be remaining. I then just now downloaded the latest version of jaikoz again and installed it.

So tried it again now with a clean install of the latest version. Using the same folder as before, I ran the local correct on the artwork. This time it did find more files that it did not find last time which was good. However it did not find all of them. So I double checked the files it could not find. This time it was only 3 albums, 2 of which had 125x125 images (yes, really poor image quality, unfortunately the best I could find from vinyl records that are over half a decade old :frowning: .) Though only one showed up in the console as being skipped for size, the other had no mention made of it. The last one was 500x500. That one gave a reason in the console which maybe you can explain to me. It said:


Any ideas as to why it skipped this folder? Is it because of the amount of mp3s in it? If so is there an option to disable this check?

EDIT: I switched the slider on the minimal image size as low as it could go. It then picked up 1 of 2 that had the 130x130 image size files. It still skipped the other without reason in the console or log file. That is when I had no filters on. When I filtered to just the one album that had the smaller artwork that was skipped, and ran the local correct, it then picked it up. I am not sure why it would skip it both times with no filter, but yet tag it with the artwork when the filter is on to only show it. Also the one I listed above is still being skipped giving the same reason about it looking unlikely to be a release folder.

Dont undertsand because in the Edit tab, there are two fields track no and track total, but in the ID3 edit field both are stored in a single trackno field[/quote]

Shrug. After the clean install this part is working again. If I sort by Track No, it will stay sorted in both tabbed views.

[quote=greengeek]The last one was 500x500. That one gave a reason in the console which maybe you can explain to me. It said:


Any ideas as to why it skipped this folder? Is it because of the amount of mp3s in it? If so is there an option to disable this check?
[/quote]
Yes the amount of mp3s in the file, often users try and process a single folder of songs from all kind of sources, so in this case it wouldn’t make sense to add the same artwork to all these songs, The only way I can guess when this is happening is if there seem to be too many songs in one folder for it to represent a single album. There is no way to turn of this switch so you’ll just have to manually drop the artwork on or use the dialog.

Yes that doesnt make sense, try setting log level to -l7 and reran the test then immediately send me your support files, that should at least pick up why the other file is not being processed, what format is it ?

They are all mp3 files with jpg graphic files. How do I go about setting the debug level to that? I had already saved that batch of files, but had loaded another roughly 2000 files. I noticed it did something similar. On the first local correct it only picked up about 70% of the folders. Then I saved and ran it again and it picked up all but 2 folders. Not sure why it required a second pass. The 2 folders it left behind were legit though, well at least according to the current rules.

What is the threshold for an album to be skipped because it has to many files? I really wish this was optional as I have a lot of multi disc compilations that are tagged this way. Unfortunately there are many different ways to handle multi disc and box sets and different users, media players, and taggers seem to handle them differently as well which is very annoying. Some put them all in one folder and label them on a per disc basis with the track numbers starting a new on each disc, and use the disc # field in the id3 tag to designate the difference. This works nicely, other than not all music players will read that tag, and instead will do all track 1s, track 2s, track 3s etc playing them out of order. Then it seems others use the old musicbrainz way of doing it, where they actually append the disc number to the album name. This works alright, other than most programs then treat them all as separate albums. Finally the way I have mine setup is like the old allmusic.com way. Listing all the tracks 1-100 in the order they come, as if they were all on a single disc, instead of breaking them into multiple discs. It would be nice that this extra check was optional as there are many cases when one might not want to have the program tell them they can’t tag in this way.

Just set logging to -l7 as described in help but it will generate a lot of debugging so you need to do the test on just one of these problem folders and then send me your support files immediately afterwards or the information will get lost.

It could certainly be made optional in a future version, but currently it isn’t and a folder is simply rejected if it has more than 50 files within it, alternatively we could try and make the check a bit cleverer.

I tried loading the next batch of files to see if any of them would have the same issue but ran into this issue where about half the albums would not load, http://www.jthink.net/jaikozforum/posts/list/1637.page

Once I can figure out how to fix this, I will delete all the album artwork, and try the local correct again to see if I can get it to happen once more with the debugging on.