SongKong Jaikoz

SongKong and Jaikoz Music Tagger Community Forum

moving unmatched files

#21

Sent

#22

Hi, thanks so from what I can see it is no worse then the previous report, i.e there are no additional problems caused by enabling the Discogs options.

#23

Okay, this should now be fixed in SongKong 1.24 please give it another go.

#24

Thanks, Ill give it a try with that same folder set and let you know how it worked.

#25

I tried the latest version of SK and it seems to work better. It still failed on moving a non matched album. Also I noticed that it does not update the tags that are 2.3 to 2.4 when the save 2.4 option is checked. Would be nice if SK did a save before moving on ALL files, even the ones that it did not change so that they are all the same id3 version if they are being moved. Jaikoz showed a bunch of files that needed to be saved and the only reason was they were 2.3 and not 2.4.

I have emailed my sk support files along with jaikoz reports.

Thanks!

#26

Thankyou, found the bug it is an issue that only affects folder with a single song in them http://www.jthink.net:8081/browse/SONGKONG-595

I don’t quite follow what you mean about the tag versions, could you go into a bit more detail please.

#27

Sure, the source music is a mixture of both id3v2.3 and id3v2.4. I did some media monkey updates previously that saved over some of the files converting them to id3v2.3. I have songkong and jaikoz both set to save files as id3v2.4 to keep everything consistent. I run songkong and it does it’s matching and moving. I am assuming when it is doing it’s updating that it is not saving every song that it checks. Maybe songs that did not have any new info found or did not get updated are not saved before being moved? So I then run jaikoz, on the sk completed songs, and I see that I have a bunch of songs that jaikoz wants to save again as they are still using id3v2.3 and have not been updated to the id3v2.4 version.

Could songkong work like jaikoz does in that it will verify that all songs are using and saved with the id3 version set in the user options?

#28

It should do that if you have the option set in the Saved tab, and for me it is doing that I haven’t been able to replicate the issue so far, in fact I am seeing the opposite problem of SongKong sometimes saving files when there is no need http://jthink.net:8081/browse/SONGKONG-600

#29

Hmm, guess I will have to try it again. I know it was set to v24, but I am not positive that I may have overlooked it and had it set to Same as or v24.

Unfortunately I have uninstalled both programs from that PC as I am in the process of upgrading my home PC. Once I get windows setup on the new box, Jaikoz and SongKong will be some of the first programs to be loaded on. :slight_smile: Then their user prefs transferred over.

I am excited for the next update on SK. Can’t wait to test it on a catalog set, and then run it against my full collection!

#30

Moving a non matched album issue should now be fixed in SongKong 1.25

#31

Thanks for the update. Going to try a run of about 4000 songs and see how it does :slight_smile:

#32

Just tried it on about 300 albums and it is looking really good! Thanks!!! :slight_smile:

#33

Paul,

So I bumped it up to a run of 25,000 mp3s using a local musicbrainz server. It moved multiple albums that jaikoz came back as missing. There was also an album that couldnt be matched that was not moved to the unmatched folder as well as a song it left behind after moving the rest of the album. This took about 24 hours to run.

I will send you the support files for sk and the reports for jaikoz.

#34

So I think you are using your (out of date) local musicbrainz server for SongKong and the real server for Jaikoz.
SongKong has actually matched the whole album ( as can be seen from looking at the releaseid), however the recordings that Jaikoz lists as missing are ones that have been merged

ie. ‘Call the Shots’ by Girls Aloud was originally

https://musicbrainz.org/recording/4cda4bd0-21f6-46ba-ae45-80ab072bb062

but this was merged into:

https://musicbrainz.org/recording/fb064be9-565c-4f3e-985f-e2a19b33c248

in December 2013

https://musicbrainz.org/recording/fb064be9-565c-4f3e-985f-e2a19b33c248/edits

Both ids now refer to same recording, but the current id that is returned for the track in the release is fb064be9-565c-4f3e-985f-e2a19b33c248

So if Im right about the Musicbrainz servers SongKong has worked correctly in this respect, but Jaikoz missing Track report could be improved to recognise old ids

There is the bug in SongKong that you have noticed with artist field having a trailing ‘, and space’

I also tried Update Metadata from Jaikoz and this failed to update all the recording with the old ids, so this is another bug in Jaikoz

#35

Interesting. I keep mine updated, or I think i do, as I run the replication now command before I use it. Hard to say as the page auto clears before it finishes, so I can’t tell if it throws any errors or not. I noticed that the statistics page on musicbrainz says it was Last updated: 2014-05-15 with ARtists: 846,105, yet the same page on the vm shows Last updated: 2013-11-23 with 799,525 artists. So if that page is suppose to update in real time, I would assume there is something wrong with the VM or at least with mine.

#36

Hi, you can run

bin/replicate now

from the command line to bring the database up to date, you should be able to see if that has worked. There was an issue with a replication packets though - that might be what you are hitting. There should be a new VM available within the next few days now that they have just done their new schema release, that will then bring everything up to date.

(Also you need to rebuild search indexes as well so they correlate with the database using bin/reindex)

#37

So I ended up installing a UI on my vm. I was then able to run the terminal inside the ui which allowed me to scroll through all the output. The vm without the ui wouldnt let me scroll more than 2 lines up even using the | less or | more commands. I was then able to see that replication was running into some issues. A little research showed that it was related to a known bug and I needed to follow this, http://blog.musicbrainz.org/2013/12/05/important-update-on-replication/ , to fix it.

I did that update and now am running another replicate which is pulling far more info. Will try another run of SK soon as this replication finishes. :slight_smile:

#38

So I finished running a batch of 250,000 files. It took little under 7 days to run and songkong did not crash at all. :slight_smile: It moved all the files extra for 2 albums, about 25 files. 78% files were moved as matched. 22% were moved to non matched.

I did notice a few interesting things. Sk reported it was using on avg 700 of 2200 mb. However windows task manager was showing it was around 3000 mb being used. So the numbers in the program ui and windows task manager did not match up.

I am also currently verifying the matched files first. I am still fairly early on in the process, but i am noticing about 2% of the albums were moved as complete even though they did not contain any musicbrainz IDs. i left Search for Discogs match checked when I ran sk. Do files that were not matched in musicbrainz but maybe matched in discogs get moved to the matched folder?

#39

[quote=greengeek]So I finished running a batch of 250,000 files. It took little under 7 days to run and songkong did not crash at all. :slight_smile: It moved all the files extra for 2 albums, about 25 files. 78% files were moved as matched. 22% were moved to non matched.
[/quote]
Great, have you got the report working now. Of the remaining 22% how many did SongKong manage to match the recording only for ?

So you allocated a maximum of 2200mb heap memory to SongKong, the 700mb is the amount of that that SongKong is using at any time. Whereas WIndows task manager shows the amount allocated (2200mb) plus non-heap memory used such as storing the the running program itself, running java runtime and permanent memory usage.

Correct, the majority of users are just interested in matched folders, whether it is matched to Musicbrainz or Discogs if of little interest so either match will move to matched folder. If your primary concern is matching to Musicbrainz and just using Discogs to update matches with any extra info then I would disable Search Discogs and then Matched folder would only contain matches to MusicBrainz.

#40

Was fairly low, around 7% or so. The initial report that comes up in songkong’s UI showed the numbers. The web based report was still giving me problems viewing it. I hadn’t made any changes though to fix the issue when sk was running the large batch of files as I didn’t want to take any chances of interrupting the batch. I will try another run on a smaller batch of files with the style folder copied over to see if it has been fixed.