Good idea, okay looks like that’s issue should have fix next week
9.1.1 Docker on Unraid
1 Like
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:
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 initOkay 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.ymlHmm, 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.
Only to be on the same page. The issue is all about recreation of the songkong container (eg. after an update). Not about restarting it.
So when I install a new version of SongKong on Docker I do the following:
-Stop Container
-Delete Container
-Delete Image
-Download New Image
-Create New Container
-Start Container
So is the problem that you are doing some sort of shortcut procedure ?
Hi @McO apologies - you were right after all.
Although the code to detect if Docker was updated to use the new method, there was some code that still referred to old method and because that old method doesn’t work on your system instead of using /songkong folder they were using $HOME/.songkong folder.
I have just built a new docker version of SongKong 9.3 that should fix this issue, please let me know how you get on. You can double check you have new version by checking About menu, the Build Date should now say 17/July/2023
It works as expected now. Thank you. Great job! 
1 Like
Okay actually there is a problem with that fix, the songkong.sh script passed a -k argument to indicate was running in docker. However code for initilizing logging is called as the main SongKong class is loaded before the -k option has been processed, and this causes the logging not to be intilized.
So we have redone fix:
-
songkong.shnow passes system property-Ddocker=trueand unlike the program argument solution this can be handled by logging before SongKong initalized. - We have also reinstated old method to fall back to look at
cproc, so for environments where this worked before this will continue to work, even if for some reason user has created a custom songkong.sh that won’t have the new -Docker=true option.
Can you get new image and retry, build date now says 18/July/2023
The logging problem can also affect standard (non docker) Linux installations
Build 18/July/2023 still works for me.
1 Like