Okay, maybe you need to stop container, edit file and then start container.
Songkong not matching tracks, even with re-match enabled
yes, that did the trick.
Now a question regarding this re-run :
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 ?
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.
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 ?
Okay this must be another web gui specific error, away from office at moment, but look at the preferredDeletionCriteria order in the correct profile.
yes, and it screwed all my duplicates job run as I was at approx 30%, and it prioritized the “longest tracks”. 
Furthermore, editing the songkong.properties file is not fixing the issue :
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 ?
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…
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?
hey there, I only, ever, use the default profile :
I did stop the container, then edited songkong.properties, and changed the order.
and here is what happens at container restart :
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
thanks !
Yes, as soon as I get Jaikoz release done I will look at this.
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 :
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 ?
Yeah, it seems there is some bug here, maybe related to restricting the list on linux installs, I will get to it very soon, please be patient.
Okay Im trying it on Docker myself and the problem I am seeing is slightly different to yours. For me Im seeing that when i set the Preferred Deletion Criteria (Im putting Most Songs in Same Folder as third) order that is what is used and shown in the report created.
e.g
The problem is when I start Delete Duplicates again it has then resets to the original list.
So clearly a problem but would be helpful if you could configure Delete Duplicates as you want it then run in preview mode (so doesnt do anything) on a few folders and see if it does work with the preferred deletion criteria list you provided after all, and shown correctly in Options page of the report or not.
Then I know if I have replicated your issue, or if there is another issue that I have not yet replicated.
Okay I think I have fixed the issue, for now I have just rebuilt the 8.7 Pod Docker image and re-released it (Build Date in About now says 24th November 2022 instead of 23rd November 2022) I tried it out myself and it works for me, let me know how you get on.
1 Like
Cool ! I was gonna make the check you asked before but I’ll simply update the container then. 
Added to SongKong 8.8 release