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.
9.1.1 Docker on Unraid
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!
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.sh
now passes system property-Ddocker=true
and 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.