SongKong Jaikoz

SongKong and Jaikoz Music Tagger Community Forum

9.1.1 Docker on Unraid

I’m having several frustrating problems, not sure what to think, been using the software for years with little to no issues.

I keep licensing the software over and over, and it keep resetting from PRO to Lite. This happens ALL the time, seems like everytime I stop and start the docker. Do I need new license keys or is this an known issue? I even tried wiping out the docker and related settings, and starting over. Same issue.

When I edit my preferences or profiles, it doesn’t seem to save, even though I click save over and over again.

I typically download my music into a specific folder, in the past Song Kong would monitor this folder then analyze, tag, rename and move the music into my Matched or Unmatched folders. Now it would seem I can’t do this anymore? As the monitor feature can no longer rename the files? It appears as if I have to do another step to rename the files?

I apologize if these isseus have been discussed, and appreciate any feedback. Maybe I’m not investing enough time with the software - reading user guides etc. It has historically worked well for me in the manner described above.

Thanks.

Are you mapping SongKong Config folder /songkong to a real folder so it is persisted when restart container as described in the Unraid Docker install guide ?

Monitor Watch Folder can analyse, tag and move to new folder, but not rename. I may bring back full rename for monitor watch folder, need to give it more consideration.

I have the same problem.
From my point of view the issue is, the SongKong (since version 9?) does no longer store its property files within /sonkong (link descriped in the manual) but in /opt/songkong mixed with its binarys.
Can you please correct this …
By the way, it is not only about the licenes.properties but also settings!

Files/Folder within the SongKong-Container:
/opt/songkong # ls
classical_composers.txt renamemask.properties
classical_conductors.txt songkong.sh
classical_people.txt songkong_deleteduplicates.properties
delete_files.txt songkong_fixsongs.properties
fonts songkong_fixsongs1.properties
fpcalc_arm32 songkong_fixsongs2.properties
fpcalc_linux songkong_fixsongs3.properties
fpcalc_linux64 songkong_metagrater.properties
general.properties songkong_metagrater1.properties
genrelist.txt songkong_naimimport.properties
help.pdf songkong_renamefiles.properties
index.html songkong_statusreport.properties
jre songkong_statusreport1.properties
lang songkong_undochanges.properties
lib songkong_watchsongs.properties
license.properties style
license.txt webhelp
not_classical_release.txt

files/folder in /songkong
/songkong # ls
Logs Reports

relevant docker-compose.yml lines
services:
songkong:
image: songkong/songkong:latest
container_name: songkong
volumes:
- /mnt/cache/docker/songkong/config:/songkong:rw

Best regards
Marcus

Hi Marcus
So when you install SongKong the files are stored in /opt/songkong. But when you start SongKong the first time it should then check the /songkong folder and if it does not contain any preferences should then copy them over.

Now I notice you have a /songkong folder and it has Logs and Reports folder, and these would get created when you first start so I assume you have actually started SongKong, and not sure why these would be created in right place if Preferences is not as they use same logic.

But one thought, I don’t currently have Unraid to test myself but we determine if running on a docker instance by looking at

/proc/1/cgroup

for a line containing

docker

Can you check this on your system and give me the results because wondering if hitting this issue

Hi,

this might be the issue. This is what I get on my system:

root@NAS:~# cat /proc/1/cgroup
0::/

A quick solution might be to define an environment variable inside the docker-compose.yaml

  • VERSION=docker

    And check for the environment variable in the startup script.

Plex does this likewise.

Good idea, okay looks like that’s issue should have fix next week

1 Like

Raised https://jthink.atlassian.net/browse/SONGKONG-2453

Should now be fixed by SongKong 9.3 Aerial released 12th of July 2023

Thank you for the quick fix.

Another thing I had to do (after the update) is to configure the following volume inside the
docker-compose.yml --> /mnt/cache/docker/songkong/config:/root/.songkong:rw
Becuase the properties, logs and reports are now stored in /root/.songkong and not in /songkong.

Best regards
Marcus

Confused, I don’t even have a docker-compose.yml file, is this an unraid specific thing or something you created from scratch?

Could you run Create Support Files, I think that would help

A docker-compose.yml file is not specific to Unraid. It is quite similar to what you do in teh Synology container setup, and more: https://github.com/docker/compose

In your installation guide http://www.jthink.net/songkong/install_docker_synology.jsp (step 8)
You can find following sentance:
"Here we have created a new top level Shared folder called config , and then created a songkong folder within it, the mount path needs to be set /songkong"

This is my current yaml:

services:
  songkong:
    image: songkong/songkong:latest
    container_name: songkong
    cpus: '6'
    mem_limit: '3G'
    restart: 'no'
    volumes:
      - /mnt/cache/docker/songkong/config:/root/.songkong:rw
      - /mnt/user/music:/music:rw
    env_file:
      - /mnt/cache/docker/common.env
    network_mode: bridge
    ports:
      - 4567:4567/tcp

this the the yaml that worked before (see volume section):

services:
  songkong:
    image: songkong/songkong:latest
    container_name: songkong
    cpus: '6'
    mem_limit: '3G'
    restart: 'no'
    volumes:
      - /mnt/cache/docker/songkong/config:/songkong:rw
      - /mnt/user/music:/music:rw
    env_file:
      - /mnt/cache/docker/common.env
    network_mode: bridge
    ports:
      - 4567:4567/tcp

With this command I can work interactivly inside the sonkkong container:

docker exec -it songkong sh

I see that in both folders:

  • /songkong
  • /root/.songkong

If I now change the volume setting from

  • /mnt/cache/docker/songkong/config:/root/.songkong:rw
    to
  • /mnt/cache/docker/songkong/config:/songkong:rw

and recreate the container I have to re-enter the license information.

checking the file-access with lsof you can see following:

7       /opt/songkong/jre/bin/java      /root/.songkong/Prefs/Database/EhCache/file/DiscogsReleaseCache_2af3616874da026eb0477571f38bcc984d3256ab/offheap-disk-store/ehcache-disk-store.data
7       /opt/songkong/jre/bin/java      /root/.songkong/Prefs/Database/EhCache/file/DiscogsReleaseCache_2af3616874da026eb0477571f38bcc984d3256ab/offheap-disk-store/ehcache-disk-store.data
7       /opt/songkong/jre/bin/java      /root/.songkong/Prefs/Database/EhCache/file/DiscogsReleaseCache_2af3616874da026eb0477571f38bcc984d3256ab/offheap-disk-store/ehcache-disk-store.data
7       /opt/songkong/jre/bin/java      /root/.songkong/Prefs/Database/EhCache/file/DiscogsReleaseCache_2af3616874da026eb0477571f38bcc984d3256ab/offheap-disk-store/ehcache-disk-store.data
7       /opt/songkong/jre/bin/java      /root/.songkong/Prefs/Database/EhCache/file/DiscogsReleaseCache_2af3616874da026eb0477571f38bcc984d3256ab/offheap-disk-store/ehcache-disk-store.data
7       /opt/songkong/jre/bin/java      /root/.songkong/Prefs/Database/EhCache/file/DiscogsReleaseCache_2af3616874da026eb0477571f38bcc984d3256ab/offheap-disk-store/ehcache-disk-store.data
7       /opt/songkong/jre/bin/java      /root/.songkong/Prefs/Database/EhCache/file/DiscogsReleaseCache_2af3616874da026eb0477571f38bcc984d3256ab/offheap-disk-store/ehcache-disk-store.data
7       /opt/songkong/jre/bin/java      /root/.songkong/Prefs/Database/EhCache/file/DiscogsReleaseCache_2af3616874da026eb0477571f38bcc984d3256ab/offheap-disk-store/ehcache-disk-store.data
7       /opt/songkong/jre/bin/java      /root/.songkong/Prefs/Database/EhCache/file/DiscogsReleaseCache_2af3616874da026eb0477571f38bcc984d3256ab/offheap-disk-store/ehcache-disk-store.data

you can see that songkong is using the files at /root/.songkong

When you go to SongKong start page in your Web-browser, at the bottom it should say you are using Docker version, does it say that?

Before releasing new versio I quickly tested this new version on Synology and it seemed to work fine as it did before without me doing anything different. But I didn’t test indepth.

So are you telling me that this is now broken, or just that it is not working correctly for your custom config?

I just can see this:
image

In my terminal docker -v tells me Docker version 20.10.24, build 297e128

With the described workarround it is working for me.
But I think it is not the way it is intented.

Here an extract of the debug.log:

12/07/2023 19.58.10:CEST:SongKong:init:SEVERE: Checking for Existing Preferences:/root/.songkong/Prefs/songkong_fixsongs.properties:false
12/07/2023 19.58.10:CEST:FolderCopying:copyProfileFilesFromInstallation:SEVERE: Replacing profiles with updated defaults
12/07/2023 19.58.10:CEST:SongKong:firstTimeUpdate:SEVERE: New Install 1151
12/07/2023 19.58.10:CEST:SongKong:setLocale:SEVERE: Locale is:en
12/07/2023 19.58.10:CEST:SongKong:setExeFolder:WARNING: User Dir:/opt/songkong
12/07/2023 19.58.10:CEST:SongKong:setExeFolder:WARNING: Java Dir:/opt/songkong/jre
12/07/2023 19.58.10:CEST:SongKong:init:WARNING: end
12/07/2023 19.58.10:CEST:SongKong:finish:WARNING: finish
12/07/2023 19.58.10:CEST:SongKong:cmdlineOrRemoteModeStart:WARNING: start
12/07/2023 19.58.10:CEST:SongKong:cmdCheckDatabase:WARNING: start
12/07/2023 19.58.10:CEST:SongKong:cmdCheckDatabase:WARNING: createDb:Start
12/07/2023 19.58.11:CEST:INFO: Initializing c3p0-0.9.2.1 [built 20-March-2013 10:47:27 +0000; debug? true; trace: 10]
12/07/2023 19.58.11:CEST:INFO: Initializing c3p0 pool... com.mchange.v2.c3p0.PoolBackedDataSource@a864c027 [ connectionPoolDataSource -> com.mchange.v2.c3p0.Wrapp
12/07/2023 19.58.11:CEST:INFO: Initializing c3p0 pool... com.mchange.v2.c3p0.PoolBackedDataSource@cce2173c [ connectionPoolDataSource -> com.mchange.v2.c3p0.Wrapp
12/07/2023 19.58.12:CEST:SongKong:cmdCheckDatabase:WARNING: createDb:End
12/07/2023 19.58.12:CEST:SongKong:cmdCheckDatabase:WARNING: end
12/07/2023 19.58.12:CEST:SongKong:cmdlineOrRemoteModeStart:WARNING: Lite license required
12/07/2023 19.58.16:CEST:SongKongDatabase:checkDatabaseCmdLine:WARNING: Setting Db Folder:/root/.songkong/Prefs/Database
12/07/2023 19.58.16:CEST:SongKongDatabase:checkDatabaseCmdLine:WARNING: Lock File remaining from previous, deleting lock
12/07/2023 19.58.16:CEST:SongKongDatabase:checkDatabaseCmdLine:SEVERE: Accessed Database okay
12/07/2023 19.58.16:CEST:SongKong:checkCache:WARNING: Checking Cache:/root/.songkong/Prefs/Database/EhCache
12/07/2023 19.58.17:CEST:SongKong:checkCache:WARNING: Checked Cache:/root/.songkong/Prefs/Database/EhCache
12/07/2023 19.58.17:CEST:SongKong:setUserAgent:WARNING: start
12/07/2023 19.58.21:CEST:AbstractAcoustidQuery:performBasicSubmissionQuery:SEVERE: Posting to url:http://api.acoustid.org/v2//user/create_anonymous?format=xml&cli
12/07/2023 19.58.21:CEST:SongKong:setUserAgent:WARNING: end
12/07/2023 19.58.21:CEST:SongKong:writeSystemInfo:WARNING: SongKong 9.3 Aerial 1151 12/07/2023 using Java 14.0.2 14.0.2+12 64bit on Linux 6.1.36-Unraid amd64 init

Okay so is running in Docker mode

I wonder is the problem that in your yaml file you have /docker/songkong on left hand side, i.e looks like you are referencing within the songkong Docker itself in your physical mapping. Whereas for music you are mapping /music to outside Docker location to physical folder /mnt/user/music.

So if you changed config to something like /mnt/user/songkong:/songkong does that then work as expected?

both volumes are physical volumes.

working: /mnt/cache/docker/songkong/config:/root/.songkong:rw
not working (but defined in manual): /mnt/cache/docker/songkong/config:/songkong:rw

But isn’t the /mnt/cache/docker/songkong folder where songkong is actually running, I.e it’s within the Docker environment, its not a standard folder like the music one?

no, it is indeed a classical filesystem:

root@NAS:/mnt/user/docker/songkong# tree

.
├── config
│   ├── Logs
│   │   ├── songkong_debug0-0.log
│   │   ├── songkong_debug0-0.log.lck
│   │   ├── songkong_user0-0.log
│   │   └── songkong_user0-0.log.lck
│   ├── Prefs
│   │   ├── Database
│   │   │   ├── Database.lock.db
│   │   │   ├── Database.mv.db
│   │   │   ├── Database.trace.db
│   │   │   └── EhCache
│   │   │       └── file
│   │   │           ├── AcoustBrainzCache_9e30ee590291b67bb81e4cf00862e5c372e69660
│   │   │           │   ├── offheap-disk-store
│   │   │           │   │   ├── ehcache-disk-store.data
│   │   │           │   │   └── ehcache-disk-store.meta
│   │   │           │   └── value-serializer
│   │   │           ├── AcoustidResultCache_b93046e72915045e34a61510087b18d03def333e
│   │   │           │   ├── offheap-disk-store
│   │   │           │   │   ├── ehcache-disk-store.data
│   │   │           │   │   └── ehcache-disk-store.meta
│   │   │           │   └── value-serializer
│   │   │           ├── AcoustidUserSubmittedCache_db2e6350bcdb2d5cd635fcb504664fe26ff6529f
│   │   │           │   ├── offheap-disk-store
│   │   │           │   │   ├── ehcache-disk-store.data
│   │   │           │   │   └── ehcache-disk-store.meta
│   │   │           │   └── value-serializer
│   │   │           ├── ArtistArtworkCache_64e9f1ef1e593fb741fdc9e97d5aa2a7cffe44cf
│   │   │           │   ├── offheap-disk-store
│   │   │           │   │   ├── ehcache-disk-store.data
│   │   │           │   │   └── ehcache-disk-store.meta
│   │   │           │   └── value-serializer
│   │   │           ├── DiscogsReleaseCache_2af3616874da026eb0477571f38bcc984d3256ab
│   │   │           │   └── offheap-disk-store
│   │   │           │       ├── ehcache-disk-store.data
│   │   │           │       └── ehcache-disk-store.meta
│   │   │           ├── MusicBrainzArtistCache_71340f70962e87c909b60e9fd88a5cf613e49d24
│   │   │           │   └── offheap-disk-store
│   │   │           │       ├── ehcache-disk-store.data
│   │   │           │       └── ehcache-disk-store.meta
│   │   │           └── MusicBrainzReleaseCache_3e5db1cf856716baec4c23ce8991210ac62c5322
│   │   │               └── offheap-disk-store
│   │   │                   ├── ehcache-disk-store.data
│   │   │                   └── ehcache-disk-store.meta
│   │   ├── classical_composers.txt
│   │   ├── classical_conductors.txt
│   │   ├── classical_people.txt
│   │   ├── delete_files.txt
│   │   ├── general.properties
│   │   ├── genrelist.txt
│   │   ├── license.properties
│   │   ├── not_classical_release.txt
│   │   ├── renamemask.properties
│   │   ├── songkong_deleteduplicates.properties
│   │   ├── songkong_fixsongs.properties
│   │   ├── songkong_fixsongs1.properties
│   │   ├── songkong_fixsongs2.properties
│   │   ├── songkong_fixsongs3.properties
│   │   ├── songkong_metagrater.properties
│   │   ├── songkong_metagrater1.properties
│   │   ├── songkong_naimimport.properties
│   │   ├── songkong_renamefiles.properties
│   │   ├── songkong_statusreport.properties
│   │   ├── songkong_statusreport1.properties
│   │   ├── songkong_undochanges.properties
│   │   └── songkong_watchsongs.properties
│   └── Reports
│   │   ├── classical_composers.txt
│   │   ├── classical_conductors.txt
│   │   ├── classical_people.txt
│   │   ├── general.properties
│   │   ├── genrelist.txt
│   │   ├── license.properties
│   │   ├── not_classical_release.txt
│   │   ├── renamemask.properties
│   │   ├── songkong.properties
│   │   ├── songkong1.properties
│   │   ├── songkong2.properties
│   │   ├── songkong3.properties
│   │   ├── songkong4.properties
│   │   ├── songkong5.properties
│   │   └── songkong6.properties
│   └── Reports
└── docker-compose.yml

Hmm, why don’t you have same problem with your /music config?

HI, okay I retested this on my synology and it works correctly as expected

Assuming you are on Unraid , if you just use the default configuration

does it then preserve the license between restarts ?

I appreciate this may not ultimately be where you want to store the data but can you please just try it to see if this works as expected or not.