Music_dump remains untouched. The remaining files in there are the same.
Only the destination changed.
As we are running in a docker let me clarify the paths
Music_dump (host) -> /music (container)
Music_processed (host) -> /music_processed/ (container)
So, the content of music (inside the container) is totally the same, nothing changed for the docker container.
Only difference is I’m telling it to move the matched files to /music_processed/ now, instead of /music/processed earlier
So I don’t understand, if there was a file that was in /music/processed and that had now been moved to /music_processed no it is no longer in /music how can running SongKong against /music move another copy of the file into /music/processed if no longer exists in /music, answer it cannot
Can you see what I mean, if not I need your support files again to see where the file came from
No they are not…
FYI here is what I found by cat’ing the logs
https://www.klgrth.io/paste/xs682
I have no clue what songkong did, but I an find the “unable to move” folder in my cloud storage, but not on my local disk anymore.
All my music files were initially downloaded here /music
Initially, once matched, the files were moved inside this same folder. In a subfolder called /processed. So /music/processed
Since I am processing /music, it will come a moment where the processed folder will process its own folder/files.
Therefore I moved all its content in another folder, which is at the same level as /music, and therefore outside it.
here is where I plan to move my processed and mathed files from now on
For some reason the webui is not showing this folders content, and I have to enter it manually. by the way…
Should I re-move all this folders content back to /music/processed ?
So I received your logs files but you cancelled report 45, 46, 47 before the task had finished creating the report was created so not making it very easy for me because the reports are incomplete…
But I can see from the logs that report 46 ran from 1:02 to 1:04 and you processed a folder called Szymon Godziemba-Trytek - Choral Works - Augustinas (2020), then report 47 was run against a folder:/music/test/Szymon Kaliski. So it looks to be like you made some copy of her music and then ran SongKong again, and ended up with duplicate files because you had duplicates files. And if I look at report 44 which was the proper one we were looking at earlier I can see there was no Szymon Godziemba in /music/processed anyway so all the Szymon Godziemba files have only come since you changed to /music_processed
So it seems that this is a non problem. But really I am trying to do my best to help you, but it would be so much easier if you changed one thing at a time and give me a chance to resolve the issue instead of changing lots of things at once and only giving me half the information each time.
OK, temps mort !
I agree all these exchanges are getting more than confusing so lets try to make sure the next thing I run is not moving my folders strangely, or only couple of tracks instead of the full album, and so on.
I am now getting the “lost” tracks back from the cloud. This t make sure I’m starting back from a clean situation.
once done, lets please agree on what I will run upfront I run it. I will share my fix tracks settings upfront clicking on start.
I now moved my processed folder back inside /music, as moving this one out of /music did generate extra issues.
So here is what it will look like :
I just want this to run, and move fully matched albums against MB / discogs to my music/processed folder. That’s it.
Remaining (unmatched) folder will stay in their original monthly folder inside /music.
No it didnt !
You ran an invalid test and misinterpreted the results as I just explained, you should keep as /processed and then let Fix Songs run to completion.
But you should first remove the files in wrong place not within artist or album folders to avoid the Travis issue, as it seems this is more of an issue than I first realized.
Yes, I understand I have to go into each monthly / daily folder, and make sure there is no flac file that is laying there without being in its own album folder.
OK done running some find and maxdepth magic.
So from now on, there are no more loose flacs. All flacs are located in their “album” folder.
Can I safely run a new fix task, with the settings I’ve pasted previously ?
Have you gone back to /music_processed
not yet, you want me to do so ?
So, /music_processed at SAME level as /music ? and not part of /music. agreed ?
Yes. because that didnt actually cause a problem and I think it will avoid a potential problem.
OK done, I now do have /music pointing to my actual music folder
and /music_processed pointing to the place my already matched and moved content is located (artist/album/).
GO ? 
Yes, okay go for it (and if you decide to cancel for any reason only press cancel once to stop the task then let it finish gracefully and fully create its report).
Okay so i think what happened it processed the 03-2021 folder as an album folder (because it contained an audio file directly under it) it then tried to move all the folders underneath it. If the folders contained audio files they were not moved, if they contained no audio files files then the folders were moved.
So all those folders listed on the screenshot there will no longer be within 03-2021, but they didn’t have audio files before this run anyway, (clearly looking at their names they had audio at some point)
Can you confirm this.
Well, I checked, and these folders are not in 03-2021 anymore (confirmed), and then I checked on my cloud storage, and I could find the same folders, containing audio files. It’s super strange as I have no idea where these folders content actually went. So I simply re-downloaded 03-2021 content.
okay thanks for checking.
Great ! let me know when the official docker container will be ready to pull 
Cool we identified this and that a fix is already on tracks! Well done !
