SongKong Jaikoz

SongKong and Jaikoz Music Tagger Community Forum

Not matching some albums

#1

I just did a run of 25,000 files in the latest version of songkong. It seems to be working really well. 18,000 of those files were matched successfully and moved. I have now started manually going through the remainder 7,000 files that songkong said it could not match. I have just but I am starting to see a pattern. It looks like any of the larger multiple disc albums that have around 100 songs are not being matched even though jaikoz is able to pick them up and match them correctly.

Does songkong have a built in limitation where it would be skipping over releases that have 100 songs on them?

Also I noticed the reporting doesn’t work in sk when you load 25,000 files. It seems that the files are to large to be displayed correct, so they never load when you click on a link. Also it had some sections that did not make sense, like a Could not load that said there was about 10,000 files. Yet that seemed to be incorrect as it would of had to be able to load at least all but 7,000 or less as it was able to match 18,000 files.

#2

Ah yes, I had to temporarily introduce a limit of 100 songs in one grouping if songs were by different artists, and a limit of 200 if all songs by same artist to help with http://jthink.net:8081/browse/SONGKONG-267 and because I haven’t solved http://jthink.net:8081/browse/SONGKONG-548 yet.

Sorry about that, but assuming the the release is a multicd release containing multiple folders for each cd the workaround is to reprocess these songs ensuring Only allow match if all songs in release were matched is disabled and then it will work on each folder at a time and hopefully match each folder to the correct cd independently and you end up with the whole release matched.

Could you send your support files so I can try and make sense of this.

#3

To bad its not a number like 105 or something. So many of the larger compilation albums are something like, 100 of the Best…, type albums. :slight_smile:

Takes over a day of running to do 25,000 songs even with using a local mb server. I have deleted the files since that run, but I will see if it happens again on the other catalogs I have cleaning up. Not sure why it takes so long on larger runs. Seems like it fingerprints everything within the first couple of hours, then it just moves really slowly through the matching and saving.

#4

Good point, I’ll increase to 105 but have you tried my workaround.

Without the logs difficult to say, but unless you have disabled discogs lookup and search that won’t be done locally and maybe queue is building up over time, acoustic looks ups are not done locally either.

#5

I sent you the logs yesterday. Did you get those?

#6

Sorry yes I have, if I don’t get to it today I’ll have a look sometime over the weekend.

#7

The report worked fine for me tested in three browsers, firefox, internet explorer and Google chrome. Some javascript is used for navigation so I wonder if Javascript was disabled in your browser.

#8

Odd only some of the links worked for me. The matched ones did not. This was using firefox. I will have to try it again along with doing a minimal run on albums that sk did not move to create smaller logs.

Probably will be a few days yet as I am now trying SK on a large scale run of 250,000 songs. Been going for 4 days now straight. Figure at current speed it should be done in 3 more days. :slight_smile:

#9

Does the Matched to Musicbrainz section open up on the left handside but the links to the open on the righthandside not work , or does the left handside not expand in the first place.

Please just retry opening the report in a different browser and see if it works

[quote=greengeek]
Probably will be a few days yet as I am now trying SK on a large scale run of 250,000 songs. Been going for 4 days now straight. Figure at current speed it should be done in 3 more days. :slight_smile: [/quote]

Wow, if SongKong manages to do 250,000 songs without hitting a problem I will be mightily pleased, that is some test !

#10

Guessing neither. As I did not know that the left hand side was even suppose to expand when I clicked on the link.

So far so good, its probably around 80% completed. :slight_smile:

I did double the memory in the config file, but even then I probably didn’t need to. It rarely goes above 900mb.

#11

[quote=greengeek]Guessing neither. As I did not know that the left hand side was even suppose to expand when I clicked on the link.
[/quote]
But there is no need to guess because you should still have the reports (even if you just unzipped the file sent to me)

[quote=greengeek]
So far so good, its probably around 80% completed. :slight_smile:
I did double the memory in the config file, but even then I probably didn’t need to. It rarely goes above 900mb. [/quote]
Right good to know, yes it is not meant to use more memory as you fix more files because files simply are queued up once the (bounded) queue is full up. I do have a problem somewhere because some users have hit memory limit even when not matching many files. The only other problem is creation of the final report, this may possibly not completeley work for you, we will see.

#12

I opened up the reports in both firefox and ie11 and they are doing the same thing.

Summary, Errors, Not matched to release, Not matched to Musicbrainz release, and Not matched to Discogs release, all work.

Matched to MusicBrainz release, Matched to MusicBrainz recording only, Matched to Discogs release, and Song changes do not.

One thing that I also noticed, is the working urls have something after the # sign. The non working ones all have the exact same url they are trying to open with nothing after the # sign.

The non working ones look like: file:///C:/Users/xxxxx/xxxxx/SongKongSupport/FixSongsReport00001_index.html#

Shouldn’t these ones also have an anchor after the # like the working ones?

…

#13

When you click on Matched to MusicBrainz release on the left hanside that should expand the lefthandside grouping matches by first letter, then expanding these opens the right handside.

The expansion uses Javascript so it really sounds like you have a Javascript error to me ?

Do earlier reports (accessed via the SongKong Reports menu) also fail or work ?

#14

Don’t think its javascript as i dont have any plugins that would prevent it. Specially in IE where i rarely use it so have no mods what so ever for it. I use to be able to view reports, but that was a couple of months back, not sure which sk version that was.

#15

I can view the very same report that you cannot which made me think it was a browser issue but Ive just remembered something.

In the SongKong reports folder there is a style folder, this is not included in the zipped up SupportFiles.zip because it is always the same, I just copy it from somewhere else when viewing reports from a SupportFiles.zip but without it you cannot expand the left handside - so it sounds like your style folder is missing.

Can you check to see if it is there , and if not copy it over from your SongKong installation folder. Could you possibly have deleted this folder perhaps when manually clearing out folders from the reports folder ?

#16

I see a style folder that is at C:\Program Files\Jthink\SongKong\style but not one that is located in AppData\Roaming\SongKong. Should there be one there as well?

Copying the style folder into the SongKongSupport folder did not make any changes.

#17

There should be one in

AppData\Roaming\SongKong\Reports

#18

That may be the reason. I just have an empty images folder in there. I probably did delete it along with all the other folders under the user profile. I occasionally do this with jaikoz when it does not start up. Jaikoz always just rebuilds those folders. I nuke everything in there except for the key and properties files. Odd that songkong does not recreated these files when it starts back up or on a new install of sk when doing a sk upgrade.