SongKong Jaikoz

SongKong and Jaikoz Music Tagger Community Forum

Remove folders after deleting duplicates

Hi no need to do that, I know why creationTime is wrong linux doesn’t actually store creationTime, when I call the creationTime() it’s just giving me lastModifiedTime().

No, my question was did all your songs have same value for Track Total, can you just send me your support files.

Did you get last support files ? I’m not sure they proceeded to be sent.

Yes, i have them thanks

1 Like

Perfect, so I’ll wait for you to figure out this creation date issue and will re-test after that. it’s good we have these 4 radius 2 generating the same issue again and again I guess ! :slight_smile:

We are almost there ! I want to thank you for being so proactive on fixing things, it is a great piece of software you are providing us.

thanks, linux not actually having creationTime was a shock to me, and means that the Earliest File Creation Date criteria has never worked on linux, but because the bulk of my testing is done on Windows I had never picked it up.

Thankyou for being very diligent and responding to my requests for additional information, makes it so much easier to get to the bottom of problems.

Okay so this is hopefully resolved in SongKong 8.7 Pod released 22nd November 2022 I await your test of the Arovane folder

Of most interest to you I think will be use of the new Most Songs in Same Folder criteria

So I’ve did the following :

  • installed 8.7 on my macbook
  • copied my unraid songkong settings to be sure I am using the same settings here and there

thing is, songkong did not delete most of the stuff, just a few examples


The above example shows that I keep having two separate versions of this same album.


The above example shows that all these “I.O” EP folders were skipped (most likely because songkong did not process files in them previously), and therefore all the remaining files were not deleted.

And the Raduis 2 targeted issue (some files remaining in folder 1 others in folder B)

it kept only deleting a few files here and there as I can see in the logs :

Support files are sent. fyi. :slight_smile:

First question is why swap to another machine in the middle of a test, and btw one of the fixes was to remove earliest Folder Creation Date as a criteria for linux because creation date does not exist for linux so not exact the same.

Atol Scap is not listed in the report as having any duplicates, I expect it is because it has not been matched by Fix Songs and therefore doesn’t have a MusicBrainz Id, and so no duplicates can be found using the Same MusicBrainz song and same album (specific version e.g. same country/date) option

I.O (2) files may have been kept in other folders because the list of files to delete is stored in delete_files.txt and I expect you didn’t copy this file over.

Radius 2, so the Most Songs in Folder criteria hit an issue that the Radius 2 had the biggest value because it counted the flac and mp3 versions so this one was preferred but it doesnt actually have Lenc-Crade or Dwaard flac versions, so its mp3 versions get deleted in preference to the Radius 2 (3) versions. So I dont think an easy way round this niche siuation.

I need to verify this, but as I only do move the tracks that were matched, I don’t understand why it would have been initially moved to the processed folder.

Because I have a running fix job on my main unraid server. I want to keep it running till eventual next crash (other topic on this forum).

Not sure I follow you here, I instaled a fresh songkong on my mac, and created the config again from scratch, see :


I’d rather think these folder were not deleted due to the fact they were not containing any music files previously processed by sk?

Hmmm I get this, but it will happen again for sure. This is an example, but I’ve encountered other folders that got a few tracks here and there. Maybe best practice would be to merge these folders somehow ?

ah, okay I looked at that status report, they were both matched, but only one was matched to MusicBrainz the other only matched to Discogs

Okay

Okay I thought you had just copied the config file over, but some files were deleted from some of these folders in that run

I think if you ran Fix Songs again it would merge them, certainly when I add a separate Rename task that would do the job, it would not be a good idea to have Delete Duplicates trying to move files and folders around.

Looking at it again I wonder if the issue is something to do with the dot at the end of the album name I.O., causing the …m3u filename

I just ran another job and added *…m3u

the same exact issue happens with Ve Palor, but here we can actually see sk did its job keeping the mp3 version of the album that has 3 extra tracks.

Occer Siliccad, same issue.

I also did run a new fix task, as you told me you think Radius 2 would have been re-merged, here is what I can see

  1. atol scrap is still there twice, but the album browser shows two specific versions, one being HD. This is due to the setting of sk (add HD to MQA releases). Could it be therefore it did not delete the lower quality occurence of this album ? Maybe something to look at ?

In plex, I have two instances of the same atol scrap album, and both do have the same amount of tracks, so that might be an issue.

as you can see, Album name is clearly identified differently, adding HD to the album title. In comparison with Ve Palor (see below), tis album is considered as ANOTHER album.

  1. Radius2 is displayed as a single album by songkong, but clicking on it keeps displaying the files located in two separate folders. This is a NON PROBLEM as I created a test plex server instance, and I can see Raduis 2 listed as a single album. So this is no big deal !!!
    See

  2. Ve Palor is shown as a single album, but there are clearly 2 separated versions of the same album here. see the detail :

In Plex, it is listed as two separate albums, one with the extra tracks (the mp3 version) was kept, which is good I believe :

No it hasn’t happened, I looked at the results of Delete Duplicates 2 report, files were deleted from Ve Palor and Ve Palor(1) and I can see from your screenshot these folders have been deleted, also shows they have been deleted in report

It didn’t delete the other folders because it didn’t find any audio files in these folders , as you know SongKong doesnt delete folders if they didn’t contain any audio files at start of job (unless subfolder of a folder that did contain audio files)

Same with Occer, it did delete folders (4), (5), (6) and (7), the (*), (9) and (10) folders were empty to start with

Okay now I look again I see there is no issue here, I.O did delete I.O and I.O (1) even first time round , it just didnt delete the other folders because they didnt contain any audio files at the start of running Delete Duplicates

I need Fix Songs support files to be able to comment on this properly.

Please do read my previous post carefully, and see how it looks once imported in Plex.

In short, everything is allright once imported (while the folder structure is…chaotic sometimes), but ends up to be OK in Plex.

Only “problem” is that HD thing. (bullet 1). The HD version should be kept and named as the album, instead of Album + Album HD

Well I was going to comment on the chaotic folder thing but I cant find without support files, I’m not clear what the question is on the HD, it has HD in the name because you have the option add HD to album title enabled and therefore disabling the option and rerunning would remove from name if that is what you want, but is that SongKongs folder view or album view ?

What I can see is the Atol scrap [HD] also says 11 Updated, the other one does not. So I expect before this run of Fix Songs it was only matched to Discogs as I said earlier, and this is the reason Delete Duplicates did not find it. If you ran Delete Duplicates again it may now find duplicates as yo now have two version of the album both matched to MusicBrainz.

Note, running Fix Songs again you will get a few more matches because if limited data was added in first run that may be enough info to allow better match second time round for parts of the algorithm that had already been run first time round before the data was added and therefore could not benefit form the added data.

Thanks for support files, okay confirmed HD only matched to MusicBrainz in this run that is why not found as duplicate previously.

Regarding Radius 2, in your settings For songs already fully matched is set to Ignore, if this is set to Update Metadata and Filename Only may fix it.

Regarding Ve Palor because you are looking for duplicates using album (specific version), and the two albums are different versions no duplicates were found

Hey @paultaylor, in a few days, I should FINALLY be done with first round of my lib fixing (hurray).

Question, do you think I could already run the script that would empty folders that were not processed by songkong (the one that checks if no music files do exist in subfolders).

Even out of songkong, can you eventually share that script so I can run it using a batch script?

Thanks !