and, as I am currious, why is the reported amount different ?
Loaded Songs Count dont match when run FixSongs from Cmdline
Hi, okay unfortunately I have found a more serious bug in the cmdline, because of a silly bug instead of using the last profile you had used in gui it ignores that and just uses a random from the list using a consistent but incorrect ordering - https://jthink.atlassian.net/browse/SONGKONG-2496
So this means (for me when using English and default installation) it uses the Default profile except for Fix Songs task where it uses the Add new metadata only profile.
I noticed your log output it says
Songs saved (if not preview):94281 (915.62%)
Implying running in preview mode, and I didn’t think you were running in preview so unfortunately got me wondering if using the wrong profile, you can check by looking at the Options tab of FixSongsReport00179.html
Although not many customers using cmdline I may have to release a bug fix release early to resolve this.
Are you saying that songkong messed with my files again ? what is this Add new metadata only profile ? it will only add missing metadata and ignore the rest ?
It will identify the files okay, but it means it will only add metadata for fields that dont have any metadata, it will not replace existing metadata.
Has it been using that ?
I was able to open the report :
Options
Current Profile: Add new metadata only
DAMN.
Why am I always falling on such bugs?
Now, it is not catastrophic, but it puts on the ground the whole idea of having the album titles changed with specific information like is it an EP, a single, …
I simply ran my script for nothing since two days
OK I stop it and will start it again once :
- right profile(s) are selected based on last one used for each type of task ran in songkong
- the rename task will be usable from the CLI
Shortly, it is simportant that songkong applies the user selected options when the user runs a task.
another option for bullet 1. would be to add a way to call a specific profile from the command line.
Because you are a trailblazer, few people using the cmdline, and this bug was recently introduced, it used to work when we only had one profile type that was shared between different tasks
Well, yes and it my fault the bug is there, but that is why it is good to check the reports then you may have noticed this earlier.
I can see that, but until now not had much demand for cmdline, I have added a line that now outputs what profile is being used.
Well, I’m afraid a line telling me a random profile is used instead of the ones I defined won’t do the trick. Could I at least get songkong to start the last profile I used for each type of task ? running songkong using the command line is useless if it doesn’t update all the metadata.
since the “split” I have 142 folders to process. You understand it is not an option for me to process them one after the other, going back to my UI every hour to see how it goes and if the previous task is done
I really need to get these few bugs fixed in order to be able to fix the files, get rid of duplicates, and rename (move) the fully matched albums specific versions in a 3 steps process, per monthly folder.
Well yes obviously that is the bug im fixing.
Of course, but it would be worth doing for the first folder processed.
Yes, that is why I have said I may do a bug fix release before the major release I was working on.
Thanks Paul !
I’m quite sure the script I worked on might become handy for some power users around here. I might want to share it once fully tested, the features so far are:
- Configuration Settings :
- Customizable paths for processing folders.
- Option to use a specific Docker image for SongKong.
- Ability to send notifications using Pushover service.
- Options to control detailed reporting, intermediate notifications, and running a Bash script.
- Bash Script Execution :
- Ability to run an external Bash script before processing. (Eg: a script to organize the music folder upfront songkong processing)
- Music Folder Management :
- Identifies target folders with a specific date pattern (
MM-YYYY
). - Deletes empty folders in the target list (as I noticed fully empty folders were making songkong hang!)
- Checks and keeps track of previously processed folders to avoid redundancy. songkong can resume where it left.
- SongKong Music Processing :
- Processes music folders using SongKong with retry functionality for certain errors.
- Calculates and reports processing progress and efficiency metrics.
- Sends detailed and periodic Pushover notifications on processing progress. (Can be enabled or disabled in the configuration)
- Backs up processing logs with a timestamp and folder identifier.
- Duplicate Song Management :
- Executes SongKong’s delete duplicates task and notifies about the summary.
- Music Renaming Task (Disabled as currently broken in songkong):
- Has a capability (though commented out as the rename feature fails to start using songkong cli) to rename songs using SongKong
- Logging :
- Logs various actions in
action_log.txt
. - Keeps a log of processed folders in
songkong_log.txt
.
- Final Notification :
- Sends a completion notification once all folders are processed.
I’m looking forward to testing this script with an optimized version of songkong
I just ran a fix, remove duplicates and rename task on folder 01-1800 throught the webui. everything went fine. So there is nothgin bad on the webui side. I can confirm !
thanks again for your help Paul ! I’ll have a look here waiting for the bug fixes
Okay, SongKong 9.5.1 Jazz is now available for Docker and Melco versions, will be available for other platforms later today.
This fixes the Rename Files not starting from cmdline, counts not correct form cmdline, and tasks not using the last profile run from gui issues.
ok I confirm it works !
I checked the logs and the fix task did use my “other runs” profile as it should.
the reported loaded tracks is now correct, which means the notification my script pushes at the end of a task is correct.
For this value as an example : Songs loaded 12863:Fingerprinted 12618: MusicBrainz 146: Discogs 6736: Saved 82
As you can see the ETA estimation for next folder still needs some work, but rest of the information is now right.
It’s also right for the delete duplicates task:
(this folder was already processed, therefore no more duplicates found, I’ll get back to you begging for bandcamp integration, don’t worry about that, as I can definitely say the remaining unmatched releases comes from this source…)
and here is the confirmation that rename is not crashing anymore :
Executing the rename command: docker run --rm --name songkong_rename_01_1804 -v /mnt/cache/appdata/songkong:/songkong -v /mnt/user/MURRAY/Music:/music songkong/songkong -f /music/Music_dump/01-1804
Now I need to add the reporting for rename tasks, but this is not a great deal
and here we go for the Rename report. All done. Of course, some improvements will become, I guess. But it does the job now!
Would be interested in seeing FixSongsReport00202 just because so few songs matched to musicbrainz.
Indeed, I did notice this too.
The script makes the access to reports a little complicated (they are not appearing in the reports list for some reason)
so let me do the following. for these two tasks :
that was followed by this task :
I am sending you a download link by email.
Okay there are a few possibilities here for Report213
- You have enabled the quite restrictive Only allow match if all tracks in album were matched option. So for example maybe you have an EP with 4 tracks, and MusicBrainz only has the 5 track EP version then it will not be matched to because can only match 4 or the 5 tracks
- Mostly E.Ps and singles, MusicBrainz coverage of albums is better then singles, Discogs certainly better for singles because more collectibles
- Alot from 2023, albunack database not been updated since may 2023 because recent update had to be rolledback because a problem with Disocgs data downloads, should be resolved soon
Now, I think the most significant issue is the Only allow match if all tracks in album were matched option for two reasons:
- Prevents matches to good but not perfect matches
- Encountering an unknown issue that is preventing some complete valid matches because option enabled.
What would be really good is if you could rerun against this folder with the Only allow match if all tracks in album were matched option and preview enabled so that we can compare the results.
The reports are not displayed in the reports list because you are deleting the database and the database contains details of the tasks run and hence reports created. But you can still create the report independently by opening the starting report html file e.g FixSongsReport00001.html
Do we agree that even with this setting " Only allow match if all tracks in album were matched" disabled, The rename feature will keep moving full albums / EPs, …, if 4 out of the 5 tracks of an EP were fully matched ? I’m a little concerned about that.
I know I’m taking th erestrictive path, but I’d rather not face another situation where I’ll end up with a ton of incomplete albums / folders.
so this is what you recommend ?
Anyway, I run it now in preview mode, lets see how it behaves.
We have had this discussion before and I’m not sure if we understood each other, but I try again. If you uncheck the Only allow match if all tracks in album were matched option but keep the Only allow match if all songs in grouping match to one album option enabled which is the default this is what happens
-
If you have a folder A with 4 songs in it and Fix Songs cannot find 4 track release but finds a potential release with 5 tracks and can match the 4 tracks to 4 of the tracks on the release then it will.
-
But if you another folder B with 4 songs in it and Fix Songs cannot find 4 track release but finds a potential release with only 3 tracks on it then even if it can match 3 of its tracks to the 3 tracks on the album it will not.
-
When you run Rename Files and have Move Folder enabled it will move files that have a MusicBrainzReleaseId or DiscogsReleaseId. Therefore it will move the folder A but not folder B so move will not split a folder but isn’t necessarily only move complete albums
If you check the Only allow match if all tracks in album were matched option then Fix Songs is unable to match Folder A (because the 4 song album not in database) so no songs matched to album, and hence when run Rename Files no songs are moved.