SongKong Jaikoz

SongKong and Jaikoz Music Tagger Community Forum

scanning songs to match complete Album - Move - but do not overwrite active artists

#6

Looking at your last few reports I think I know what the issue is.

The files seemed to have been renamed to the COMPLETE folder, but no metadata has actually been added or updated. So this indicates the files were already matched to a MusicBrainz album and therefore when you ran this time when it gets to the move file stage the file is moved because it has already been matched to an album

image
image1193×998 52.3 KB

So I assume at some point you did not have Only allow match if all tracks in album were matched set to Yes and that allowed these incomplete albums to be matched to the correct album.

Its worth noting that SongKong only adds/updates data it doesnt just delete data so if you wanted to prevent SongKong thinking these songs were matched to an album you would need to delete the existing MusicBrainz metadata (specifically MusicBrainz Track Id and MusicBrainz Release Id).

An easy way to delete all the metadata is download Jaikoz and select Edit:Delete All Metadata

#7

Thanks.
That doesn’t seem to work if there are any subfolders.
For instance, I have a tree:

INCOMPLETES folder
-Rattlesnakes folder
–1 Song-Rattlesnakes 1
–2 Song-Rattlesnakes 2
–5 Song-Rattlesnakes 5
–9 Song-Rattlesnakes 9
-misc song1
-misc song 2
-misc song 3

The misc songs get left in place, unaltered.
The Songs in the Sub-folder, Rattlesnakes, get moved to Complete, even though there are songs missing from the album.
If I move the Rattlesnakes files out of the sub-folder, into INCOMPLETES, they are not moved when I run SongKong.

I’m deleting all metadata after each test, and I have SongKong’s “For songs already fully matched” set to “Rematch”, just in case.

The SongKong preference “All existing folders represent a single album” is OFF.

#8

If you have just run this test as you described please run Create Support Files again and tell me the name of the report so I can check it.

#9

Report 298 in the support files I just sent.

#10

Okay I have looked at your report, this should not happen, could you try running File:Empty Database and then rerunning the test to see if that resolves it.

#11

Same results.
Downloaded and installed new version, emptied DB, quit, restarted, ran it on files containing no metadata.

#12

Ok, sorry but there is not info in logs for me to work out why this is happening.
Can you go into Preferences, set Debug Log Level and Debug Io Log Level to Config, rerun the test and then send the support files again immediately after.

image
image807×277 7.13 KB

#13

Done. Report #303. Database emptied and SK restarted before running tests.

#14

Hi, I think I have found the error.

The Only allow match if all tracks in album were matched options behaves slightly differently if the album is a multi-disc album. Customers may have their multi disc albums stored as different folders not below a common parent folder in such cases it is difficult for SongKong to realize these folders are all part of same album so instead what would happen would be the folders would be matched to one disc of the album independently. So in the case of a group of songs matching to one disc of an album it is okay if the group of songs doesnt match the whole album as long as they all match the same disc of the album, however there is no check to ensure that all tracks on that disc are matched, this seems to be an error.

So this allowed your tracks to match the multi-disc version of Rattlesnakes (good album), the regular discs were rejected because album track count did not match song track count.

I am going to try to do a fix for you to try (for MacOS ?).

#15

Yes, Mac OS. Thank you very much.

#16

Okay I have fixed and test this, but I have a couple of other problems that came up today that need fixing so I am going to roll them all up into a 6.9.2 fix which should be ready in a couple of days.

#17

Hi @pixeljammer now fixed, please give it a go

#18

Thanks, that solved my problem.

Thanks for making a great product, and double thanks for the excellent customer service.

#19

It doesn’t seem to work with all files. I’m getting the same results with other files, but not with Rattlesnakes… I updated the Dropbox folder with some files that cause a failure. I’ll reiterate the address in my Support Files.

#20

Hi

It because they are single files. Of the five files that were moved, the Blade Runner match is a complete match I don’t think there is any issue with that ? The other two are single files, the logic is that seeing as you only have a single file its better to add the album info rather than the just the song info so at least you have a chance of getting the right album artwork ectera.Then because they have been matched to an album that allows them to be moved, as that process is just concerned about if they have been matched to an album (rather than if it is a complete album).

image
image782×804 38.9 KB

Of the ones that didn’t move, the Bille Holiday tracks could not fully match an album so they correctly were not moved. The other single track was not moved because it could not be indentified.

image
image782×804 34.9 KB

So, what is the solution ?

We could prevent single songs being allowed matching to match to an album (unless 1 track album) but I do not see that as an improvement. Better I think would be to amend Move Folder option so you could choose whether it applied to all albums or just fully matched albums ?

#21

I think that the latter option is best. That would allow people to consolidate libraries containing only whole albums, and leave behind recognized yet incomplete albums.

#22

I have create issue https://jthink.atlassian.net/browse/SONGKONG-2032 to amend Move Folder option so you could choose whether it applied to all albums or just fully matched albums. In the meantime you will only see the issue of incomplete albums being moved occur for when you just have a single track.

1 Like
#23

How is this coming along?

#24

It hasn’t been looked at yet, sorry it is not really a high priority issue.

#25

Fair enough. I just wondered.