Creating new Scripter tasks - they appear as Filename Masks instead

[jsibre]

Hi Paul,
I’ve noticed when I save a new Scripter function (in preferences, in Song Kong), that it seems to be saving it to the Filename Masks section instead of the Scripter section. Also, because of this (I think), it’s not available to be chosen when I edit a Scripter profile, and it shows up as a selectable Filename Mask in the Rename Files action profiles - which probably wouldn’t be very helpful (but might actually do something, which could be confusing depending on the situation).

I found this post for Jaikoz which is similar, but I’m not sure if it’s really the same behavior or not: Scripter new function saving

[consider this ‘story’ as approx steps to reproduce]
I created a new Scripter task, and later (the next day) went to use it as I decided to create a new Scripter profile that would perform two tasks at once (1. append album subtitle to album title, 2. move co-artists to the track title), and it wasn’t there in the list I could pick from in the Scripts input on the Basic tab for the Scripter profile. I assumed I’d just messed up when I created it, and forgot to save it or something.
Later, I noticed an oddball in my Filename Masks while changing the Compilation mask for a soundtrack album. (yeah, yeah, I still haven’t gotten very mature in my use of profiles!) It was my Scripter Function!
I confirmed it showed up in the Preferences | Filename Masks | Filename Masks list, and not in the Preferences | Scripter | Scripts list.
I then went to create it in the ‘right’ place, and couldn’t - I used the same name as before, and got the error: “A mask with this name already exists”.

Issues:

1. The error message is wrong for that screen because I wasn’t creating a mask; I was creating a script. But… technically right in this case, because it did exist in the logical space it was being saved to (the wrong logical space).
2. I think it’s being tagged as the wrong kind of script (a ‘mask’ script, vs a ‘scripter’ script), or being stored in the wrong table, etc. Something like that. This is the “logical space” thing I’m referring to above. This is causing it not to appear in the right places (“prefs / scripter / scripts” and “Scripter / Basic / Scripts”), and to appear instead in the wrong places (“prefs / filename masks / filename masks” and “rename files / rename files / rename mask & compilation rename mask”)

Because it’s showing up in WRONG places vs both places, I think this is a bit different than the Jaikoz bug listed above (or maybe it wasn’t fully understood when written up).

Let me know if you need screenshots - I think I got enough info in there to make it pretty clear, but I know it’s kinda dense, too. Pictures may make it easier to understand.

BTW, I haven’t tried editing an existing script in preferences to see if it has a similar issue. I don’t want to, as I might bork up the configuration of the scripts you provided.

Somewhat related: Was any further thought ever given to the idea of being able to Chain Tasks?

Thanks

[paultaylor]

Hi, replicated issue. This a Remote UI only bug which is why I have not noticed it, will get fixed for next release - https://jthink.atlassian.net/browse/SONGKONG-2995

[paultaylor]

Fixed for next release.

[jsibre]

Thanks Paul!

I was wondering again about chaining actions, and something got me thinking about how I use songkong (remote, in docker) and why (I think because when I first started with songkong vs jaikoz that I thought having it run continuously would confer some advantage - not really, for my use case), and as I dug around I realized/remembered that it has a cli interface!

So… I might be able to chain actions with my own scripts! Probably easier to run it locally if I do that, vs doing it in docker (despite how fascinating this thread was to skim: Running songkong cmdline in script in Docker environment)

Is there a way to trigger scripter tasks from the cli? I see how to do fix songs and rename/move…

I assume that if I was running locally, the cli and gui would share the same properties/settings, so that I could define the scripter tasks in the gui, and then automate via bash or python using the cli?

Thanks

[paultaylor]

Yes, plan to add support for Steps when I can, in the meantime you can use Gui to configure profiles then use cli to run multiple tasks one after another. However, as you have identified we don’t currently support running Scripter from the cli ( think just over looked this), I have raised an issue to fix this for next release.

[paultaylor]

Sorry, the tutorial page was out of date, but actually Scripter from command line is already supported using the -j option

[jsibre]

Awesome - thanks, I’ll try that out today. Working on figuring out how to migrate a copy of my config from Docker to Mac now, based on How do I Move SongKong Configuration to a different computer?.

[jsibre]

Hi Paul,
Ok, I’ve had a fun morning - I’ve been able to do quite a bit, but I discovered a few things along the way. One is a genuine bug, I think, that could use some attention.

I’m gonna go in order of my notes - I’ll highlight the more important stuff for you to be aware of.

1. Documentation update: I noted that there’s a correction for this this page:

   Path for preferences on Mac is wrong.
   Tutorial says: “MacOS, Library:Preferences:SongKong”
   It should probably read: “MacOS, $HOME/Library/Preferences/SongKong”

   At least that’s how it is on my computer. Maybe there’s an option I long forgot that tells SongKong that it’s installed for everyone, or something like that, which moves the preferences.

2. Documentation update: Path mentioned for songkong CLI is wrong for Mac on this page:
   It says that commands look like:

   songkong -m -p songkong_fixsongs.properties /music

   Whereas on my MacOS installation, I think that should be:

   songkong.sh -m -p songkong_fixsongs.properties /music

   (note the “.sh” on the command)

   That songkong.sh file can be found in /Applications/SongKong.app/Contents/bin/songkong.sh

   However, that command only works if you’re actually inside that folder “/Applications/SongKong.app/Contents/bin/”. This isn’t because of the CLI search path (though, that does have to be updated, or you have to specify the whole path to the .sh file) - it’s because the .sh file assumes it will be run from that location by making the assumption that the songkong jar file can be found in the relative folder “…/Java/”.

   Updating songkong.sh to something like this fixed that issue for me:

    #!/bin/sh
   
    # Get directory of this script (POSIX sh style)
    SCRIPT_DIR=$(cd "$(dirname "$0")" && pwd) || exit 1
    cd "$SCRIPT_DIR" || exit 1
   
    java  -Xms150m -Xmx1800m -XX:MetaspaceSize=45 --add-opens java.base/java.lang=ALL-UNNAMED -Dcom.mchange.v2.log.MLog=com.mchange.v2.log.jdk14logging.Jdk14MLog -Dorg.jboss.logging.provider=jdk -Djava.util.logging.config.class=com.jthink.songkong.logging.StandardLogging -Dhttps.protocols=TLSv1.1,TLSv1.2 -Dapple.laf.useScreenMenuBar=true -Dapple.awt.brushMetalLook=true -Dsun.java2d.metal=true -XX:+HeapDumpOnOutOfMemoryError -jar ../Java/songkong-12.6.jar "$@"
   

   This way, the path in the java command can still be relative, but the command works no matter what folder the user was in when running it. This is convenient because I’d usually rather be in or near the folder of files I’m working on than the folder that contains the command I’m using.

3. Kudos: Scripting (as a workaround to the not yet present Steps) works great, and is fast:

   songkong.sh -m -p songkong_fixsongs5.properties "/Volumes/Audio/Music/Artists to Fix"
   songkong.sh -j -p songkong_scripter3.properties "/Volumes/Audio/Music/Artists to Fix"
   songkong.sh -f -p songkong_renamefiles.properties "/Volumes/Audio/Music/Artists to Fix"
   

   3b. Feature - maybe: However… I do have to wait for the JVM startup three times. Support for something like this might be interesting:

   songkong.sh \
       -m -p songkong_fixsongs5.properties \
       -j -p songkong_scripter3.properties \
       -f -p songkong_renamefiles.properties \
       "/Volumes/Audio/Music/Artists to Fix"
   

   If this worked, I imagine it would not take much longer than step 1 above - the FIX step is the most expensive. Scripting and File move/rename ops are quite fast, but waiting for the JVM is a noticable delay.

   That said, this isn’t something that I feel has to be blazingly fast. The ability to script all three is already a massive improvement to what I used to do via the Remote (web) interface. And frankly, the GUI interface is so snappy (compared to the Web UI I’m used to) that I don’t mind doing the three steps manually as much as I did when doing it through the web UI. As a result, I may not even bother with scripting, long term. I guess what I’m saying is “This is an idea - but I’m not begging you for it.”

4. Feature: When using the CLI, I do wish the reports were easier to open. Maybe there’s a way to make the output of the report location in Terminal a hyperlink, but I doubt there’s an easy way to do that portably (Linux, Max, Windows), so… probably a dead end. However, having a command line option that means “open the report in my native browser” would also be valid ("–view-report" or similar). I did create a shell script wrapper for myself that takes care of that and the above path/pwd problem in one fell swoop. (I’ll attach the file for you or others to look at and consider.)

5. Bug: On that note, something weird is going on with report generation in the CLI. It often seems to reuse the same report number over and over. This happens for the same task, or for different tasks. I don’t know if this may be related to running both GUI and CLI at the same time. I don’t think so; it seems that if you run the CLI while the GUI is already running, it just sits there until you realize what you’ve done and close the GUI - then it proceeds normally. I’m having a hard time pinning down exactly what’s happening, but it OFTEN generates the same report number in the CLI (and, what’s more, it seems like it’s appending to rather than overwriting the reports- at least to the summary). But sometimes it doesn’t. It seems like the GUI doesn’t suffer the problem, and can maybe help reset it so that the next run from the CLI might generate a new number. Again, I can’t get 100% consistency, so I must be overlooking some variable. Sorry I can’t nail this down better. If you can’t easily duplicate it, let me know I’ll try to build up a repeatable test case for you. I have confirmed that I get this behavior even when I’m not using my helper script, or a modified version of your songkong.sh script.

6. Comment: Manual editing seems to limited to the first album found in the folder structure. I’m not sure that’s what is happening, but that’s what it looks like. I don’t know if that’s intended or just a reasonable assumed limitation, or a bug. This is true for Remote (Docker) and GUI (Mac). I haven’t tried CLI - I assume that’s not supported (for obvious reasons). I ran across this while trying to figure out what to do with the EPIC Musical (Jorge Rivera-Herrans), which is apparently packaged / meta-data-ed as both 9 short ‘albums’ of 3-5 tracks each, and also as one large compilation of all 40 tracks. (I think this is probably a quirk of Discogs info, but may also be influenced by my own config. I’m viewing it as a one-off that requires attention because it’s really not obvious which way is “right.”)

That’s it. I would appreciate some digging into #5 - the ‘bug’(?) regarding reports from the CLI. I think something is a bit wrong there, and using the CLI is less valuable to me if I can’t easily review what’s happening (since reports get a bit borked). Everything else I’ve mentioned here either isn’t really a problem, or I’ve already found an easy way to fix it for me without needing to change anything in the SongKong package.

Ok, seems I can’t upload a shell script, so here it is inline for those who may want to try it out.

I’ve named this songkong.sh, and placed in in ~/bin, ($HOME/bin), which is already in my search path. It handles making the command available on my path, processing the ‘–view-report’ option I wanted, and CDing to the correct folder so that the real songkong.sh will work correctly.

#!/usr/bin/env bash

SK_DIR="/Applications/SongKong.app/Contents/bin"
SK_SCRIPT="$SK_DIR/songkong.sh"

show_report=0
args=()

# Parse args, strip --view-report
for arg in "$@"; do
  if [[ "$arg" == "--view-report" ]]; then
    show_report=1
  else
    args+=("$arg")
  fi
done

cd "$SK_DIR" || exit 1

if (( show_report )); then
  report_file=""

  # Run SongKong, mirror output, and capture report path
  # process substitution keeps loop in the current shell (no subshell var-loss)
  while IFS= read -r line; do
    printf '%s\n' "$line"

    case "$line" in
      Report\ Created:*)
        report_file=${line#Report Created:}
        ;;
    esac
  done < <("$SK_SCRIPT" "${args[@]}" 2>&1)

  status=$?

  if [[ -n "$report_file" && -f "$report_file" ]]; then
    open "$report_file"
  fi

  exit "$status"
else
  exec "$SK_SCRIPT" "${args[@]}"
fi

[paultaylor]

Hi, thanks for the useful testing and detailed response, very helpful.

1. The path specified is the path as it is seen from Finder, rather than the unix equivalent I think this is how Mac users usually see things.

2. Yeah, the examples are for linux since these are the most likely cli users, but I have now added a new section above the examples showing the path for different platforms. It would be better if the script did not require you to be in script folder, I will look into your script thanks, raised issue

3. You are right about JVM start up, but this issue will be resolved once we have Steps because then you will able to call a step profile that includes multiple tasks to run in one go. Desktop UI is snappier than WebUI because:

• Browser code is slower than Desktop app,
• When using WebUI from your mac you are connecting over the network to your Nas, whereas the Desktop UI is locally running on Mac.
• Mac cpu faster than Nas cpu

You can also use WebUI locally on your Mac by starting SongKong on Mac and selecting File:Start Remote Mode to compare speed of non remote Web mode to Desktop mode

4. This workflow never occurred to me , as I was thinking cmdline would usually be used on headless computer without browser, but I see usecase and have raised issue

5. Cli and Gui should not be used at same time. So it would be helpful if you could rule out this as being a problem by ensuring gui not running before using cmdline and then run various cmdline tasks and see if the problem still occurs. Cmdline should exit immediately if SongKong already running so I have raised issue

6. Correct, manual editing is limited to the selected folder or first folder within if no files directly in selected folder, because SongKong works on a folder by folder basis manual editing of whole collection is not feasible like a regular tagger. I probably need to give this more thought, although manual editing is not a key feature of SongKong there are better options for that generally, although manual editing using the Remote UI is useful for editing files on headless servers such as nas.

[jsibre]

Thanks for the quick response.

On item 1, to be clear I really meant the bit about it being the Library in the user’s home directory, vs the one in the root filesystem - not the bit about colons vs slashes as path separators. I’m not sure which part you were talking about when you said that you “think this is how Mac users usually see things.”

Regarding 3 - yeah, your observations make sense. I had thought about that a bit too (mostly the local CPU being much beefier than the NAS CPU). I think part of my original logic of wanting it running on the NAS had been that the ‘local’ access to the files (from SongKong’s perspective) might help it be faster, but it seems that any benefits from that are offset by the CPU speed. (Aside: I have an app I use to help manage playlists (for exporting to players, USB sticks, etc), and I did find that running it on the NAS made it faster. I don’t generally run it there though, because you then have to deal with attaching the player to the NAS for file sync operations, so, again, a trade off that makes the speed bump not worth it.)

Also regarding 3 - have you thought much about how reporting will work once Steps is supported? I pondered it a bit as I wrote my previous post (i.e., “how should reports work if Paul did decide to support multiple actions on the cmd line?”) and my thoughts were that it might be nice if it could generate one report for all ‘n’ actions performed, but I honestly didn’t give it much thought to see if that even really makes sense from the perspective of what the reports describe. (I use the reports, but they’re quite detailed, and I tend to focus on a small part of them, a bit myopically, just enough to figure out if I can trust what was done, or if I need to examine more closely.). Even aside from the feasibility of logically combining the reports, I had a sense that the technical work of trying to combine the output of multiple steps into one report might make the whole ‘step’ concept distastefully difficult to implement. (i.e., such a right PITA that one might never get around to it!)

Regarding 4. “This workflow never occurred to me…” Totally valid - I get that. Not really the case intended. Two thoughts: 1. Don’t worry about it unless you want to. The script I’ve written takes care of it for me - and you’re more then welcome to point people at it in the forum (or even share it in a tutorial/etc) if anyone else ever asks for the feature - that’s why I shared it. 2. I suppose even on a headless box, someone might have installed a text mode browser (Links or Lynx, if either of those are still supported?) but I guess that wouldn’t really be that practical if each step spat out a report, as each step would likely need to interrupt the batch.

Regarding #5… that’s below - the real meat of this post.

Regarding #6: Makes sense - I agree that other apps (Jaikoz in particular, which I also use) are better suited. Personally, I wouldn’t recommend chasing better manual editing in Songkong unless you get the hunch that it might be very easy to support without risk of nasty surprises. Not worth it. I forget why I even tried it (my first time ever using that feature was just in the last few days), but it’s probably related to me skimming the tutorials, and re-learning the feature existed, and just trying it out, and then deciding a day or so later to actually try it ‘for real’, and then seeing the limitations.

Ok, now to the real work… Regarding #5: I gave you the trimmed version of the notes for this last time . I’m sure it happens even when SongKong’s GUI is not running. What I’m not sure of is whether it may require a reboot after having tried it while the GUI was running to “flush things out”, but I’m guessing not. It a Java app - not something with hooks into the kernel.

I’ve got some runs below that show the report numbers being used repeatedly, even across different action types. First three using my wrapper script, and then some more using the barebones CLI support provided directly by songkong.sh, and then with a few GUI invocations mixed in, but from the command line.

(The [$HOME] / [My Name] business below is just me redacting my info, not the actual output)

➜  bin pwd                                                                                    
/Applications/SongKong.app/Contents/bin

➜  bin ~/bin/songkong-fix-artists-to-fix.sh                                                   
debuglogfile is:[$HOME]/Library/Application Support/SongKong/Logs/songkong_debug%u-%g.log
userlogfile is:[$HOME]/Library/Application Support/SongKong/Logs/songkong_user%u-%g.log
H2 Cache Size is 368640 kb
Using Supplied Profile:[MY NAME] Default:songkong_fixsongs5.properties
Start Fixing Songs
Songs loaded 52: Fingerprinted 0: MusicBrainz 39: Discogs 39: Saved 52
Report Creation 87%
Report Created:[$HOME]/Library/Application Support/SongKong/Reports/FixSongsReport00042/FixSongsReport00042.html
Summary:
Processing:0
Songs loaded:52
Songs fingerprinted:0
Songs ignored because already matched:0
Songs matched to MusicBrainz release:39
Songs matched to MusicBrainz song only:0
Songs matched to AcoustId release:0
Songs matched to Acoustid song only:0
Songs matched to Discogs release:39
Songs matched with artwork:39
Songs matched to AcousticBrainz:35
Songs saved:52
Completed:52
Activity Log:40
debuglogfile is:[$HOME]/Library/Application Support/SongKong/Logs/songkong_debug%u-%g.log
userlogfile is:[$HOME]/Library/Application Support/SongKong/Logs/songkong_user%u-%g.log
H2 Cache Size is 368640 kb
Using Supplied Profile:[MY NAME] Script Task:songkong_scripter1.properties
Start Scripter
Songs Loaded 52: Saved 0: Done 0
Report Creation 72%
Report Created:[$HOME]/Library/Application Support/SongKong/Reports/ScripterReport00042/ScripterReport00042.html
Summary:
Processing:0
Songs loaded:52
Songs saved:2
Completed:52
Activity Log:0
debuglogfile is:[$HOME]/Library/Application Support/SongKong/Logs/songkong_debug%u-%g.log
userlogfile is:[$HOME]/Library/Application Support/SongKong/Logs/songkong_user%u-%g.log
H2 Cache Size is 368640 kb
Using Supplied Profile:Default:songkong_renamefiles.properties
Start Renaming Files
Songs Loaded 52: Renamed 2: Done 0
Report Creation 98%
Report Created:[$HOME]/Library/Application Support/SongKong/Reports/RenameFilesReport00042/RenameFilesReport00042.html
Summary:
Processing:0
Songs loaded:52
Songs renamed:2
Completed:52
Activity Log:0

➜  bin # Now I'll run the 'stock' songkong.sh script directly, with no wrapper.
➜  bin ./songkong.sh -m -p songkong_fixsongs5.properties "/Volumes/Audio/Music/Artists to Fix"
debuglogfile is:[$HOME]/Library/Application Support/SongKong/Logs/songkong_debug%u-%g.log
userlogfile is:[$HOME]/Library/Application Support/SongKong/Logs/songkong_user%u-%g.log
H2 Cache Size is 368640 kb
Using Supplied Profile:[MY NAME] Default:songkong_fixsongs5.properties
Start Fixing Songs
Songs loaded 52: Fingerprinted 0: MusicBrainz 39: Discogs 39: Saved 52
Report Creation 87%
Report Created:[$HOME]/Library/Application Support/SongKong/Reports/FixSongsReport00042/FixSongsReport00042.html
Summary:
Processing:0
Songs loaded:52
Songs fingerprinted:0
Songs ignored because already matched:0
Songs matched to MusicBrainz release:39
Songs matched to MusicBrainz song only:0
Songs matched to AcoustId release:0
Songs matched to Acoustid song only:0
Songs matched to Discogs release:39
Songs matched with artwork:39
Songs matched to AcousticBrainz:35
Songs saved:52
Completed:52
Activity Log:40

➜  bin ./songkong.sh -j -p songkong_scripter3.properties "/Volumes/Audio/Music/Artists to Fix"
debuglogfile is:[$HOME]/Library/Application Support/SongKong/Logs/songkong_debug%u-%g.log
userlogfile is:[$HOME]/Library/Application Support/SongKong/Logs/songkong_user%u-%g.log
H2 Cache Size is 368640 kb
Using Supplied Profile:[MY NAME] Script Task:songkong_scripter1.properties
Start Scripter
Songs Loaded 52: Saved 0: Done 0
Report Creation 72%
Report Created:[$HOME]/Library/Application Support/SongKong/Reports/ScripterReport00042/ScripterReport00042.html
Summary:
Processing:0
Songs loaded:52
Songs saved:2
Completed:52
Activity Log:0

➜  bin ./songkong.sh -f -p songkong_renamefiles.properties "/Volumes/Audio/Music/Artists to Fix"
debuglogfile is:[$HOME]/Library/Application Support/SongKong/Logs/songkong_debug%u-%g.log
userlogfile is:[$HOME]/Library/Application Support/SongKong/Logs/songkong_user%u-%g.log
H2 Cache Size is 368640 kb
Using Supplied Profile:Default:songkong_renamefiles.properties
Start Renaming Files
Songs Loaded 52: Renamed 0: Done 0
Report Creation 98%
Report Created:[$HOME]/Library/Application Support/SongKong/Reports/RenameFilesReport00042/RenameFilesReport00042.html
Summary:
Processing:0
Songs loaded:52
Songs renamed:0
Completed:52
Activity Log:0

➜  bin # Now I'll fire up the GUI, and perform a task to attempt to reset the report numbers
➜  bin ./songkong.sh 
debuglogfile is:[$HOME]/Library/Application Support/SongKong/Logs/songkong_debug%u-%g.log
userlogfile is:[$HOME]/Library/Application Support/SongKong/Logs/songkong_user%u-%g.log
H2 Cache Size is 368640 kb

➜  bin # I ran the rename files task, same folder and profile as above, and it generated the report: http://localhost:4567/RenameFilesReport00042/RenameFilesReport00042.html\?init\=1
➜  bin # It used the same report number, but I'm gonna try it again.                                                                                                                  
➜  bin ./songkong.sh                                                                                                                                                                  
debuglogfile is:[$HOME]/Library/Application Support/SongKong/Logs/songkong_debug%u-%g.log
userlogfile is:[$HOME]/Library/Application Support/SongKong/Logs/songkong_user%u-%g.log
H2 Cache Size is 368640 kb

➜  bin # Same task/profile again, and this time it produced this report: http://localhost:4567/RenameFilesReport00043/RenameFilesReport00043.html\?init\=1                                                    
➜  bin # Note that it finally bumped up to 43. I think something in the GUI run ... marked report generation complete? Something like that. Allowing the next run to generate a *new* report instead.
➜  bin # Now I'll run a couple cmd line invocations again                                                                                                                                           

➜  bin ./songkong.sh -m -p songkong_fixsongs5.properties "/Volumes/Audio/Music/Artists to Fix"                                                                                                    
debuglogfile is:[$HOME]/Library/Application Support/SongKong/Logs/songkong_debug%u-%g.log
userlogfile is:[$HOME]/Library/Application Support/SongKong/Logs/songkong_user%u-%g.log
H2 Cache Size is 368640 kb
Using Supplied Profile:[MY NAME] Default:songkong_fixsongs5.properties
Start Fixing Songs
Songs loaded 52: Fingerprinted 0: MusicBrainz 39: Discogs 39: Saved 52
Report Creation 87%
Report Created:[$HOME]/Library/Application Support/SongKong/Reports/FixSongsReport00044/FixSongsReport00044.html
Summary:
Processing:0
Songs loaded:52
Songs fingerprinted:0
Songs ignored because already matched:0
Songs matched to MusicBrainz release:39
Songs matched to MusicBrainz song only:0
Songs matched to AcoustId release:0
Songs matched to Acoustid song only:0
Songs matched to Discogs release:39
Songs matched with artwork:39
Songs matched to AcousticBrainz:35
Songs saved:52
Completed:52
Activity Log:40

➜  bin # Note that it came out as 44 - supporting my theory that when the GUI invocation that generated 43 completed, it was able to somehow 'tidy up' report 43, so that the next run would fire off a new report.  It's beginning to make a bit more sense to me now.
➜  bin ./songkong.sh -j -p songkong_scripter3.properties "/Volumes/Audio/Music/Artists to Fix"                                                                                                                                                                       
debuglogfile is:[$HOME]/Library/Application Support/SongKong/Logs/songkong_debug%u-%g.log
userlogfile is:[$HOME]/Library/Application Support/SongKong/Logs/songkong_user%u-%g.log
H2 Cache Size is 368640 kb
Using Supplied Profile:[MY NAME] Script Task:songkong_scripter1.properties
Start Scripter
Songs Loaded 52: Saved 0: Done 0
Report Creation 72%
Report Created:[$HOME]/Library/Application Support/SongKong/Reports/ScripterReport00044/ScripterReport00044.html
Summary:
Processing:0
Songs loaded:52
Songs saved:2
Completed:52
Activity Log:0

➜  bin # And now we have report 44 again. Which makes sense if I assume that cmdline invocations never 'complete' the report generation process. 

So, That was a bit more ‘consistent’ than what I saw yesterday, but I think I trust the above - it really behaved ‘consistently’, once I had the theory in my head that it’s failing to do something needed at the end of a CLI run that ‘finalizes’ a report. So, my theory is that when you run via CLI, the next run will use the same report number that the CLI run used. If you run via GUI, the next run will use a fresh number.

Hope that helps