Hi, received your latest report, showing Fix Songs running for 10 days and eventually failing after 10 days after successfully processing 680, 971 music files
I think you would agree that is a substantial number of files to process and you are pushing SongKong to the limits. Processing is done folder by folder and only the details of a few folders are held in memory at any one time, however there are some global variables that hold minimal information, but because you have processed so many files may be larger than usual. So you are probably right when you say SongKong gets slower and slower over time. With this is mind maybe it is better to process the top level date folders one at a time as you previously suggested.
There was some timeout errors, but there was no memory errors. However if memory was getting low it could be that SongKong was spending too much time recovering memory from heap . For the docker version of SongKong the image runs the songkong.sh file, and this contains
#!/bin/sh
umask 000
./jre/bin/java -XX:MaxRAMPercentage=60 -XX:MetaspaceSize=45 -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 --add-opens java.base/java.lang=ALL-UNNAMED -jar lib/songkong-8.5.jar "$@"
Note the option -XX:MaxRAMPercentage=60
, this means the max heap that can be used is 60% of the amount of memory you have allocated to the container - https://www.baeldung.com/java-jvm-parameters-rampercentage