SongKong Jaikoz

SongKong and Jaikoz Music Tagger Community Forum

Songkong not matching tracks, even with re-match enabled

#1

Hi @paultaylor,

I might have misunderstood something, but as you told me a second run could identify new albums, I ran a new task using the following settings :

Basic

  • Ignore songs previously checked that could not be matched: Yes
    For songs already fully matched : **Rematch
  • Rename files based on metadata: Yes if matched to a release
  • Update Artwork: Yes
  • Update Genres: Yes
  • Update Mood and other acoustic attributes such as BPM (Pro or Melco license only): Yes
  • Only allow match if all songs in grouping match to one album: Yes
  • Only allow match if all tracks in album were matched: Yes

Match

  • Force Acoustic fingerprints even if already matched: No
  • For Naim wav files read the accompanying metadata files (Melco license only): No
  • Search for a MusicBrainz match: Yes
  • Update from Discogs: Yes
  • Search for a Discogs match: Yes
  • Ignore existing metadata when matching individual songs: No
  • Ignore metadata derived from filename when matching individual songs: No
  • All existing folders represent a single album: No
  • Preferred media formats:
  • Preferred Release Date: Earliest Release Date
  • Preferred Release Countries:

But here is what it tells me

image
image1318Ă—428 116 KB

Any clue ?

#2

Its because you have Ignore songs previously checked that could not be matched enabled so its just skipping over all the songs it had previously processed.

So Ignore songs previously checked that could not be matched should be disabled and For songs already fully matched should be set to Update Metadata and Filename so that is doesn’t waste effort rematching but it does get the latest version of the matched release and update with any new metadata, and most importantly for you allow it to rename matched files because some failed to rename first time round.

#3

Well, I keep unchecking that checkbox, and it keeps re-enabling it. Are we sure there is no bug in latest songknong version ?

image
image1020Ă—134 66.9 KB

image
image948Ă—404 102 KB

it is impossible to start a task with this option disabled. I uncheck the box, click start, and when I check the report, I can see the option was checked anyway.

EDIT :

I confirm, impossible to get rid of this option :

image
image1170Ă—382 96.1 KB

#4

Okay there is a bug when using the web UI with this option, if you enable the option you cannot disable it- https://jthink.atlassian.net/browse/SONGKONG-2373

But you can work round this for the time being by cancelling any running SongKong task, looking for

isIgnorePreviouslyCheckedFiles=true

in the correct profile properties file and changing to

isIgnorePreviouslyCheckedFiles=false

If using an existing properties file, they are mapped as follows:

Default, songkong.properties
Fix Songs, add new metadata only without changing existing metadata - songkong1.properties
Fix Songs, add artwork only - songkong2.properties
Status Report, show all fields - songkong3.properties
Fix Songs, fix from naim wav metadata files only - songkong4.properties
Roon, Fix Songs - songkong5.properties

#5

I’m using default profile. I edited the file manually.

image
image1140Ă—858 190 KB

back to the WebUI:

image
image1614Ă—1294 191 KB

and as soon you click start:

image
image1140Ă—858 189 KB

#6

Okay, maybe you need to stop container, edit file and then start container.

#7

yes, that did the trick.

#8

Now a question regarding this re-run :

image
image1174Ă—220 57.9 KB

Newly “saved” songs are the ones which previously were not matched, and therefore got fresh and clean tags from MB/Discogs ?

Newly “moved” songs are the ones that were phicially moved to the processed folder ?

Is my assumption right here ?

#9

Newly saved songs are songs that have had metadata added or modified or deleted and therefore require saving. This maybe because they are being matched for first time, or it ,may be because the song they were matched to now has additional metadata in Musicbrainz/Discogs and therefore new metadata has been added to the song, or it maybe because you have changed a formatting option so you want the metadata for a field stored differently.

Newly renamed songs are songs that have been renamed, again it maybe because matched for first time, but could also be songs that were already matched but couldn’t not be renamed because of a clash with another file or other problem preventing the first rename attempt.

Anyway it doesnt look like it is going to take 15 days to do this since you are already a quarter of the way through.

#10

well, I wouldn’t be that optimistic. Look, it is still running (since 13th of dec.)

image
image1162Ă—272 55.6 KB

#11

@paultaylor

I can confirm this config issue also applies to the other sections of SK.

The Album with most tracks setting keeps going down in the list whatever change I make in the UI.

Can you please let me know where I can edit this manually in the conf files ?

#12

Okay this must be another web gui specific error, away from office at moment, but look at the preferredDeletionCriteria order in the correct profile.

#13

yes, and it screwed all my duplicates job run as I was at approx 30%, and it prioritized the “longest tracks”. :frowning:

Furthermore, editing the songkong.properties file is not fixing the issue :

image
image854Ă—410 114 KB

image
image940Ă—802 104 KB

#14

I’m sorry for this problem, the release was a little rushed to try and get you the features you wanted, it will be fixed in next release.

But the workaround should work, are you modifying the correct profile, did you remember to close the container whilst modifying the file ?

#15

yes, container stopped -> nano -> restart of the container.

Not sure about the config file, as there are so many of them. But sonkong.profile is the only one listing all these settings, so…

:wink:

#16

There are default values, they only get written to file if different to default.

The key thing is what is the name of the profile you have selected on the main page because profiles are named as follows:

Default, songkong.properties
Fix Songs, add new metadata only without changing existing metadata - songkong1.properties
Fix Songs, add artwork only - songkong2.properties
Status Report, show all fields - songkong3.properties
Fix Songs, fix from naim wav metadata files only - songkong4.properties
Roon, Fix Songs - songkong5.properties

Note, profiles are a little weird because a profile can be used for any task, i.e the Fix Songs, add artwork only could be used for Delete Duplicates or Status Report, because it is simply a set of user preferences. I think I would like to change this so that a profile is tied to particular task, but quite alot of change to UI required for this and not sure if worth it?

#17

hey there, I only, ever, use the default profile :

image
image1492Ă—550 121 KB

I did stop the container, then edited songkong.properties, and changed the order.

and here is what happens at container restart :

image
image1062Ă—882 108 KB

Could you eventually fix these ui settings issue ? I’m afraid to re-start a run and get all my files deleted as 20+% of my tracks were badly processed already :frowning:

thanks !

#18

Yes, as soon as I get Jaikoz release done I will look at this.

#19

Thank you @paultaylor :slight_smile:

#20

aw dude this is insane, I’ve made a backup of my Prefs folder, just to be sure to stay on the safe side, then I edit EVERY SINGLE .properties file

I removed all the existing “preferredDeletionCriteria” from each file, and added this at the end of each properties files:

preferredDeletionCriteria0=AUDIOFORMAT
preferredDeletionCriteria1=BITRATE
preferredDeletionCriteria10=PARENT_FILE_MODIFIED_DATE
preferredDeletionCriteria11=PARENT_FILE_LATEST_MODIFIED_DATE
preferredDeletionCriteria2=MOST_SONGS_IN_SAME_FOLDER
preferredDeletionCriteria3=RELEASE_WITH_MOST_TRACKS
preferredDeletionCriteria4=FILENAME
preferredDeletionCriteria5=FILE_MODIFIED_DATE
preferredDeletionCriteria6=BIT_DEPTH
preferredDeletionCriteria7=COMPILATION_ALBUM
preferredDeletionCriteria8=TRACKLENGTH
preferredDeletionCriteria9=FILE_LATEST_MODIFIED_DATE

I then started the docker container and :

image
image882Ă—712 92.9 KB

I have no clue where this order is coming from, but as I did edit and force this in every single properties file, I guess the order should reflect the above list order. right ?