Okay, thankyou, please run Create Support Files and I will look into it tommorrow.
Songkong stops in an endless loop
You won’t believe what happened, it completed! but in preview!!!
What do you want me to do? The preview is of course of no value for me, do you want me to rerun it, do you want a report?
Regards,
Mike
That is what I was expecting when I asked you to run it Preview only, what I was not expecting was for it to give an OutOfMemory error when you first tried to run Preview Only. Unfortunately because you have only just run Create Support Files after this last substantial run the logs from the initial failed preview run have been overwritten so I cant see the details of that. I just wonder if maybe you didnt restart SognKong before run Preview Only the first time and there was already a shortage of memory causing it to fail prematurely.
Problem
I have a rough idea of what I think is happening, this is bit technical but I will just explain it anyway for the benefit of anyone reading and then i have an idea that may work.
Songs are bundled into groups (usually based on folders) and then processed through a Work Pipeline, this can include Audio Fingerprinting, Match to MusicBrain, Match to Discogs ectera. The work is put on a queue and the work is done by multiple workers based on how many cpus you have. The queue has a fixed size so if the queue gets full we pause adding any more to the queue until some work is done. The queue also has a timeout for any piece of work so that if the work takes an unreasonable amount of time it is cancelled.
At the end of the Work Pipeline they are sent to the SongSaver Service. If any changes have been made (and not in preview mode) the actual files are modified and Saved count updated, then the Completed count is updated. Because most of the work is File I/O rather than Cpu based there are just a couple of workers for this pipeline because too many workers will just thrash the disc. Also because we may be writing data to actual files we dont want to cancel a piece of work half way through so there is no timeout and the queue size is unbounded.
When running not in Preview I noticed from your progress screenshots that the Matched to MusicBrainz Release counter was much higher than the Saved and Completed counters. It seemed that it was matching songs alright but very slow saving changes and having trouble saving the changes, and If I have a look at your Activity Log there are errors with files
So I think what is happening is your computer is fast but your network is quite slow and unreliable, causing the SongSaver Service queue to build up. Then because the queue is held in memory that requires more memory and we run Out of Memory. Now the queue used to only store the Song Ids of the songs, the actually metadata is stored in database and only retrieved as required so it shouldn’t use that much memory, however in the last release we added success messages to the Activity Log and these are passed down to the the SongSaver so that will increase the memory used although it still doesnt seem to be that significant.
The point of running in Preview mode was that I expected it to work because now the SongSaver Service doesnt actually write back to the networked audio files so it should be much quicker, and hence the queue will not build up and we should not run out of memory, I’m unclear why it did fail first time.
Potential Solution
For you I have a potential solution, by default on a desktop computer the Work Pipeline queue is 500, but we can make it smaller, by making it smaller we slow down how quickly the work gets done and this means that less works gets queued up on the SongSaver queue, reducing the memory required.
- Ensure SongKong not running
- Open Finder
- Select Go menu
- Hold down Option button, Library will appear in the list
- Select Library
- Select Preferences
- Select SongKong
- Edit general.properties file with TextEdit, and add this line
queueSize=50
- Save Changes
- Start SongKong and retry.
And I will do some work on making this more robust so that the SongSaver queue cannot get too large.
Goodmorning Paul,
I did as you asked, let it run overnight but it ended again in a loop as far as I can see.No support file availed, the option is dimmed.
Did a memory error occur?
Was it looping and then you stopped it or had it already finished prematurely and looked as the screenshot above shows?
It does seem it got considerably further.
Could it just be that you are trying to run Create Support Files whilst the screen is like your screenshot shows, in which case I think it might just be that you need to select the Close button to dismiss the dialog first. If that is not issue simply restart SongKong, and then you should be able to immediately run Create Support Files
support files uploaded as you instructed
Thankyou, are you able to answer the first two questions?
Hi, I ve looked at the logs, actually it is not in an endless loop and didnt hit memory problem it was cancelled by yourself whilst it it was still processing. However, the matching to MusicBrainz had actually completed at about 10pm and from then on SongKong was only saving changes to the files, and it was saving files incredibly slowly at a rate of about 1 folder per minute so I can see it might have looked like it wasn’t doing anything.
30/04/2026 06.02.58:CEST:SEVERE: ++SaveStart:29051:/Volumes/storage/music/Music_Backup/Isabel I, Reina de Castilla [Savall]/20 Requiem_ Requiem aeternam (Graduale).flac
30/04/2026 06.03.13:CEST:SEVERE: ++SaveComplete:29051:/Volumes/storage/music/Music_Backup/Isabel I, Reina de Castilla [Savall]/20 Requiem_ Requiem aeternam (Graduale).flac
30/04/2026 06.03.14:CEST:INFO: Stop
So, although there is a bug I will fix for next week to prevent SongSave queue getting too large the underlying issue is that for whatever reason SongKong file saving is extremely slow on your network
And sometimes failing
30/04/2026 05.52.56:CEST:SongSaver:readAudioFile:SEVERE: Unable to read file from filesystem:/Volumes/storage/music/Music_Backup/Kenneth Woods Bloch Schelomo Hebraic Rhapsody Suite for Viola and Orchestra 2025 24-96/103 Suite for Viola and Orchestra, B 41 (Arr for Cello and Orchestra by Adolph Baller and Gábor Rejitö) II Allegro ironico.flac Bad file descriptor
java.io.IOException: Bad file descriptor
at java.base/java.io.FileDescriptor.close0(Native Method)
at java.base/java.io.FileDescriptor.close(FileDescriptor.java:304)
at java.base/java.io.FileDescriptor$1.close(FileDescriptor.java:89)
at java.base/sun.nio.ch.FileChannelImpl$Closer.run(FileChannelImpl.java:116)
at java.base/jdk.internal.ref.CleanerImpl$PhantomCleanableRef.performCleanup(CleanerImpl.java:178)
at java.base/jdk.internal.ref.PhantomCleanable.clean(PhantomCleanable.java:133)
at java.base/sun.nio.ch.FileChannelImpl.implCloseChannel(FileChannelImpl.java:210)
at java.base/java.nio.channels.spi.AbstractInterruptibleChannel.close(AbstractInterruptibleChannel.java:113)
at org.jaudiotagger.audio.flac.FlacInfoReader.read(FlacInfoReader.java:106)
at org.jaudiotagger.audio.flac.FlacFileReader.getEncodingInfo(FlacFileReader.java:40)
at org.jaudiotagger.audio.generic.AudioFileReader2.read(AudioFileReader2.java:60)
at org.jaudiotagger.audio.AudioFileIO.readFile(AudioFileIO.java:364)
at org.jaudiotagger.audio.AudioFileIO.read(AudioFileIO.java:196)
at com.jthink.songkong.analyse.analyser.task.songsaver.SongSaver.readAudioFile(SongSaver.java:1574)
at com.jthink.songkong.analyse.analyser.task.songsaver.SongSaver.createSongSaveWrappers(SongSaver.java:1043)
at com.jthink.songkong.analyse.analyser.task.songsaver.SongSaver.saveSongsToFile(SongSaver.java:978)
at com.jthink.songkong.analyse.analyser.task.songsaver.SongSaver.saveChanges(SongSaver.java:283)
at com.jthink.songkong.analyse.analyser.task.songsaver.SongSaver.call(SongSaver.java:246)
at com.jthink.songkong.analyse.analyser.task.songsaver.SongSaver.call(SongSaver.java:93)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
at java.base/java.lang.Thread.run(Thread.java:1583)
So if I fix the queue size that should prevent SongKong failing with Memory Error, but it will take a long time to complete because of the slowness of song saving and some songs will not get saved because of this file descriptor error. The file descriptor error is not due to a bug in the SongKong code it is a symptom of some issue with your local network.
So one solution is to fix the network, but it is difficult for me to give advise on what is wrong with your network.
A pragmatic workaround for this problem would be for you to copy the files to a local drive on your computer, or a pluggable external hard drive. Then when you run SongKong it is just modifying the local files and there should not be any issues.
Is that a viable solution for you?
My internetspeed is in my opinion no problem, until now I never had any issues with reliability.
I will see if i Have somewhere a 2TB external disk and try what you suggested, but I am confident my network is OK.
Hi, its not your external internet access that is a problem it’s your local network.
In fact the issue may not be the local network itself the issue might be with device connected to the network where the files are stored.
If you can find your external drive I am very confident this will work for you.
I am copying the files to an extern ssd, will take forever:notes:
I will let you know iif this works, Of course thismis not a real solution, but it is worth trying as an experiment
Yes, but of course if it takes a long time to copy the files even locally that does seem to indicate that maybe there is a problem with disc access on your server. Did you say it was an Antipodes Audio server, if so might be worth rebooting and making sure dont use it for playback of music or anything else whilst attempting this.
Audio servers are designed for quiet, reliable playback of music but they are low powered audio appliances not general high-performance NAS boxes, is the internet connection wired or wireless?
Hi Paul,
I transfered most of the files from the server to an extern SSD. Result : it stopped workin after a short time
It hadn’t stopped working, it was doing stuff and then you cancelled
01/05/2026 14.21.48:CEST:SEVERE: ++SaveStart:64417:/Volumes/Extreme SSD/MusicFiles/Alleluia/09 Recit_ Sub tantae Virginis tutela.flac
01/05/2026 14.22.39:CEST:WARNING: G1456:Foldername:Andreas Ottensamer Romanza 2025 24-96:isPartOfMultiDisc:false:Warning memory was low so cancelling processing for this group and trying to allocate more memory:Java heap space
01/05/2026 14.22.39:CEST:SEVERE: ++SaveStart:63346:/Volumes/Extreme SSD/MusicFiles/Akademie für Alte Musik, Berlin/A Vivaldi Grand Tour, Disc 1/02 Concerto for oboe, strings & continuo in C major (_L'Olimpiade_)_ II. .flac
01/05/2026 14.22.39:CEST:SEVERE: User Cancelled Task
01/05/2026 14.22.39:CEST:SEVERE: Adding Error:Unable to match song to MusicBrainz:/Volumes/Extreme SSD/MusicFiles/Andreas Ottensamer Romanza 2025 24-96/108 Clarinet Sonata in D Major - II Andante quasi adagio.flac:org.hibernate.exception.JDBCConnectionException: could not extract ResultSet
java.lang.RuntimeException: org.hibernate.exception.JDBCConnectionException: could not extract ResultSet
Can you please:
- Restart SongKong
- Run Admin:Empty Database
- Start Fix Songs on Volumes/Extreme SSD
and then just leave it to run or actually fail with error.
Support files uploaded, I am really sorry for both of us, it costs a lot of time for you. For me no problem because I am a retired MD an I have plenty of free time. But first tonight: F1 Miami 
Regards,
Mike
Thanks for your patience, its okay, worth getting to the bottom of these problems to make better product.
So interestingly in this case the memory problem is not caused by a large SongSaver queue here and there were no Save errors so far.
I think this particular failure is caused by parallel matching of multiple box sets. So the workaround would be to try increasing the max memory allocated again to 8gb - close SongKong, then you can use this plist file I previously uploaded and then restart SongKong and try again.
Info.plist (3.0 KB)
Hopefully the increased memory will be enough to avoid the memory issue that should be a temporary blip that will resolve once the folder has completed processing.
Unfortunately although the logging shows when the OutOfMemory ocurred that does not neccessarily show the process that is hogging the memory just the process that attempted to get the extra memory when there was none. In fact I should improve the logging to help identify likely cause of problem by taking a snapshot of all process running at the time, and grabbing a snapshot of the objects currently grabbing the most heap memory.
Hi, have you been able to retry with the increased memory?
Goodmorning Paul,
Finally it succeeded!. I uploaded the support files some minutes ago.
Thanx for your help, it would be handy if the app also works on my network attached SSD.
One other question: there are a lot of albums in my library that are split in two or more albums. This was repaired by Roon, but I do no longer use Roon, so I am searching for an app which can merge two or more albums into one, without merging the flac files. Dit you ever consider building an app which can do this automatically, all the apps I tried cannot do this without retagging the album by hand.
Best regards,
Mike
Great, looked at your report and things looking pretty good.
SongKong generally groups songs by folder and only allows a match if all songs in folder can be matched to one album. But if songs have already been split into multiple folders or are already matched to multiple albums within one folder it is a bit harder to fix with Fix Songs task. However the Match to One Album task can be applied to one folder at a time to find albums that match all songs in folder and then fix. Although if the album is not in MusicBrainz, Discogs or AcoustId there is little that can be done.
The Inconsistencies section of the report shows potential metadata issues, but it would help me if you could give me some specific examples of albums split into two or more albums so I can see exactly what you mean.
So the increased memory when matching locally allowed Fix Songs to work for you, this shouldnt be necessary but there are some edge cases where this can happen. I’ve replicated the OutOfMemory issue locally by limiting memory to 500mb on my 20,000 song library and am looking for ways to better handle this type of issue.
There was no errors at all during this last run but when running against your networked files the underlying issue is with either your server or your local network as demonstrated by the super slow saving of files and save errors. This manifested as an OutOfMemory error because my save queue didn’t set an upper limit to its size. Now I have fixed this for next release and this should prevent the OutOfMemory error however this is not going to solve the underlying issue of your network/server being slow/unreliable.
To solve the saving file over the network problem it might be worth you getting some advise from Antipodes about this.
I have now released new version of SongKong with significanlty better memory handling.