SongKong Jaikoz

SongKong and Jaikoz Music Tagger Community Forum

What is this program for instead of crashing ?

Sorry to say this, but this program is not usable anymore.
It crashes all the time, even on a newly installed computer (Windows 10 x64)

  • I wanted to tag about 15000 files.
    It counts up files, but never starts to progress with anything, even after one hour.

  • I wanted to delete identical files out of 15000 files.
    It started 18 hours ago, and now is constantly at 90 % CPU-Power and 3000 MB rem. It stopped working. 18 hours of expensive energy wasted for nothing …

  • Database is often not deletable.

I dont know where to begin, but this java-stuff runs such as instable, never seen such a mess before. You cant do anything with it, never get any progress.

So it used to work for you and has now suddenly stopped working ?

If you could upload your support files (Help:Create Support Files) that would be the the best first step.

So, yeah …

To say before: I am an on-going software-developer.
I like your program (basicaly) but taking money for this “thing” is NOT ok, Ive never had such an unstable and buggy program before, and I have some experience, belive me.

I am very pissed off right now, SongKong is a big mess. I dont know where you learned to program, but you are breaking the basic rules every programmer learns in the first hour of school.

I hope you take this critic “as a man” and recognize my feeling that I as customer have right now.
I bought basically an other program to do this job, but that failed, because of wrong description, thats why i bought SongKong, but this fails too, so I bought another program to get at least rid of my duplicates (and this works very fine and without any problems).
So why should I buy programs in future and pay for them ? They dont work, or it was told something that is not the truth, the program is not capable of doing …

A friend of mine asked me to sort out his business, meanwhile its an unsorted collection of about 900 000 songs (yes, its that big).

So I am very frustrated to buy several programs, no ones work, or works that slow that it would take months to do the job. SongKong needs about 4 seconds to tag a single file.

Back to topic:
I now tried to tag only !! 1000 !! songs. Songkong failed COMPLETELY.
It took me ! 5 ! passes to get these 1000 songs tagged, it took at all about 2,5 hours, thats absolutely UNACCEPTABLE !!!

I attached 3 logs of these passes. In first pass I got about 500 errors, but the files are NOT damaged, they passed my other software which decodes audio-part completely to analyse it, there have been NO problems, so they cant be damaged. I also removed all tags and covers before I started tagging with SongKong. Better conditions are not possible.

Correction: Songkong does not name those support-files individual, so my first two logs have been overridden … first big failure.

Not possible to attach support-file here … server error, I have to use email hmm ? :


message

description The server encountered an internal error that prevented it from fulfilling this request.

exception

java.lang.NullPointerException
\tnet.jforum.JForumExecutionContext.enableRollback(JForumExecutionContext.java:272)
\tnet.jforum.JForum.service(JForum.java:209)
\tjavax.servlet.http.HttpServlet.service(HttpServlet.java:722)
\tnet.jforum.util.legacy.clickstream.ClickstreamFilter.doFilter(ClickstreamFilter.java:59)

note The full stack trace of the root cause is available in the Apache Tomcat/7.0.30 logs.

Also here have been some bugs:
Some songs also been moved into a folder, but have been not renamed,
that might be, because they dont have tags inside … and there was only the fingerprint in tags, nothing more. But that cant be, how are they moved, based on what data? :

895 songs loaded into SongKong
895 songs checked
781 (87%) songs matched to MusicBrainz release
4 (0%) songs matched to MusicBrainz song only
13 (1%) songs matched to Acoustid song only
729 (81%) songs matched to Discogs
801 (89%) songs matched with Artwork
937 (104%) songs updated with Acoustic metadata
895 songs have had information modified and have been saved

895 songs is correct, 937 have been updated ? How is that possible ? 895 modified and saved, but those files have still ONLY the Fingerprint-ID.

Another wasted hour of my life and expensive energy, without making ANY progress with my 900 000 files …

I dont know where to start, this program is full of problems, but one of the main problem is the wrong workflow you did.

It cant be that it fingerprints and downloads 18 hours long, loading ALL Data only into memory and after a crash or Windows-10-Forced-Unwanted-Update-Reboot) ALL is lost … come on.

I hope you give some feedback and explanation about your background steps:

  1. You load all files -> dont know what is done in this step, but “ok”.

  2. You fingerprint all files -> Ok, but fingerprints are not saved directly or anywhere, after a crash ALL progress is lost and fingerprinting 100 000 files can take a lot of time and uses lots of memory in that case.

  3. After all files are fingerprinted you connect to the server to find entries whith an identical fingerprint and download data -> this data is also not stored anywhere. So it downloads data for lots of songs without saving them.

  4. After all is downloaded you start to rename and tag the files -> at this point my computer worked for 18 hours and no data has been prevented in case of crash or unwanted “Windows-Update-Reboot” … come on … meanwhile my memory is full (3GB, that a lot) I have luck that my server has 16 GB, so this isnt a matter to me.

So I basicaly ask you: Why the hell are you doing it that way ? Why cant you complete one file after another:
You tag them only, you dont compare them for duplication, so it is basicaly not needed to work hours only in memory and then beginning first time to save the data if not something crashed or restarted meanwhile.

Okay, if that is the case then you should realize that making loads of unfounded critisms and incorrectly explaining to me how my own program works is not the best way to get help and support.

I asked for the support files, true there is a problem with the forum software that prevents upload but you can indeed email me or if they are large use a service such as dropbox. The report and log files do not overwrite each other.

Without the support files it is impossible for me to investigate your issues, but I can comment on some of your points.

SongKong process works on a folder by folder basis, this means it would only fingerprint one folder folder before trying to match them not all your songs. So unless you have thousands of songs in a single folder there should be little delay before matching. It doesnt work on a single song basis because SongKong is trying to match songs to releases not just single songs to any version of that song on the release. It does not store all this processing data in memory it is stored in a database so there should not be any memory problems. Then once a folder has been fully processed the changes to the song are saved to file, so if a crash occurs folders that have been processed will have had their changes saved so the work done would not be lost.

If you actually have 100,000 files in one single folder then we have a problem. If this is the case the way forward would be use a file renaming application to reorganize your files more sensibly before then running SongKong Fix Songs.

By default no songs are renamed you have to change the option on the first tab, I dont know what you have it set to. If yo havent chnaged thsi option and they are being renamed I assume they are under iTunes control and you have ITunes configured to keep ITunes media folder organized. Maybe you also have iTunes configured to Copy files to iTunes Media folder when adding to library, if so this would slow things down.

Delete Duplicates works best when songs have been previously identified by SongKong, so should be run after a successful Fix Songs but this is not the case with how you have done it.

The log snippet you have sent me shows that 87% have been matched to song and release, and the remaining 13% have been matched to song so that is a very good result.

The 937 songs updated with Acoustic metadata is a bug that has been fixed for next release https://jthink.atlassian.net/browse/SONGKONG-1242

First of all: Thanks for your answer, I appeciate it.

“unfounded critism” would be if there is no fault and I am lying, but that isnt the truth, I have no reason to tell here something that is NOT correct. But I see here things other than you see them.

“incorrectly explaining” I can only tell you what I see, if your program works not correctly I can only tell you what I see on my side, not what you wanted to see me, this is also called “bug”.

This is interesting, so they are all collected in one single zip-file, this is very fine, but I am very sure that I deleted logs and reports on 04/6, but inside the support-zip are dates from 31/5, they shouldnt be still there … or should they ?

Not to be personal, but now I have to ask you if you know how your own program works. This is NOT what I am seeing here. I did a test and got (as ever) an other impression. >ou can watch the video on youtube: https://youtu.be/07HZw86eTb8. I did this video very quick, dont have time for cosmetic :slight_smile:

I must fairly say: That test-run did very well, it renamed all 980 files within about 30 minutes, that was really GOOD !!!

[quote]So unless you have thousands of songs in a single folder there should be little delay before matching.```

In this test-run it was a very little gap, in my last days there was a up to 15 minutes gap for about 5000 songs.

[/quote]It doesnt work on a single song basis because SongKong is trying to match songs to releases not just single songs to any version of that song on the release.[quote]

But exactly this is what I always see (and you can see in the video. Its confusing, it starts and then pauses for a very long time …

[/quote]It does not store all this processing data in memory it is stored in a database so there should not be any memory problems.[quote]
You can see in this case it was “very less” usage of RAM, but I - often - have more than 2 - 3 GB of RAM usage, last days also running an overclocked I7 at 90% CPU-Power.
This program sucks very much memory, this is one of the things I mentioned from the beginning I used it. I dont know if this is wanted that way, or a bug in SongKong or either in Java … I can only tell you what I see HERE !

[/quote]Then once a folder has been fully processed the changes to the song are saved to file[quote]
No, definitifly not, please watch the video. For me it looks not that way.

[/quote]If you actually have 100,000 files in one single folder then we have a problem.[quote]
Yes, we have one, I am only a stupid user. If this is a problem, SongKong had to solve it by itself -> If there are no subfolder, only take a amount of files “at once” and finish them …
Also it is not a solution that the user has to split the files into hundreds of folders and then starting to process every folder by hand … this takes days … no good.

BTW: If I have all songs fine sorted in folders, what should I need SongKong for? Sin of that program is to identify and sort files out of a mess … or did I missunderstood something :wink:

[/quote]If this is the case the way forward would be use a file renaming application to reorganize your files more sensibly before then running SongKong Fix Songs. [quote]
That is the funny stuff and why I am so upset: I HAD them sorted in folders before, but SongKong didnt worked with those foilders, so I was forced to copy all of them into ONE single folder … dont ask me why ! :roll:

You can see my setting in the video, maybee I did wrong settings, but results are fine for me.

[/quote]Delete Duplicates works best when songs have been previously identified by SongKong, so should be run after a successful Fix Songs but this is not the case with how you have done it. [quote]
Yes, I know, but as long as SongKong doesnt tag my files I cant go further.

My third program I was forced to buy does a very good job with it, It cant tag, but identifies duplicates even without tags. So basicaly it seems not to be the only way to use tags. And even that I tried, but there was no difference with finding duplicates or tagging with SongKong, you can do a lower number of songs at once, but not a hugher one.

My other program had no problems to filter out duplicates out of 190000 songs at once. It took 24 hours, but ran total smooth …

As to say again: My recorded test-run did very well, also tagging-speed was VERY good, but that isnt the normal case. Also in my logs there have been many error because of “wrong audio”, but all files are OK, they are not damaged, it “must” be a fault in SongKong.
In my first run it reported over 500 damaged files, after restart, clearing database and logs it processed those damaged files, but it took up to 5 runs to get all files tagged, that is also not a normal case.

First of all: Thanks for your answer, I appeciate it.

“unfounded critism” would be if there is no fault and I am lying, but that isnt the truth, I have no reason to tell here something that is NOT correct. But I see here things other than you see them.
“incorrectly explaining” I can only tell you what I see, if your program works not correctly I can only tell you what I see on my side, not what you wanted to see me, this is also called “bug”. I dont know how your program work internaly, thats why I ask, it is sometimes not logical and I only can guess from what I see.

This is interesting, so they are all collected in one single zip-file, this is very fine, but I am very sure that I deleted logs and reports on 04/6, but inside the support-zip are dates from 31/5, they shouldnt be still there … or should they ?

Not to be personal, but now I have to ask you if you know how your own program works :wink: This is NOT what I am seeing here. I did a test and got (as ever) an other impression. >ou can watch the video on youtube: https://youtu.be/07HZw86eTb8. I did this video very quick, dont have time for cosmetic :slight_smile:

I must fairly say: That test-run did very well, it renamed all 980 files within about 30 minutes, that was really GOOD !!!

In this test-run it was a very little gap, in my last days there was a up to 15 minutes gap for about 5000 songs.

But exactly this is what I always see (and you can see in the video). Its confusing me, it starts and then pauses for a very long time …

You can see in this case it was “very less” usage of RAM, but I - often - have more than 2 - 3 GB of RAM usage, last days also running an overclocked I7 at 90% CPU-Power.
But to be fair: 1700 MB RAM-usage is very much, “only” for tagging files.

This program sucks very much memory, this is one of the things I mentioned from the beginning I used it. I dont know if this is wanted that way, or a bug in SongKong or either in Java … I can only tell you what I see HERE !

No, definitifly not, please watch the video. For me it looks not that way, I hope you can explain that.

Yes, we have one, I am only a stupid user. If this is a problem, SongKong had to solve it by itself -> If there are no subfolder, only take a amount of files “at once” and finish them …
Also it is not a solution that the user has to split the files into hundreds of folders and then starting to process every folder by hand … this takes days … no good.

BTW: If I have all songs fine sorted in folders, what should I need SongKong for? Sin of that program is to identify and sort files out of a mess … or did I missunderstood something :wink:

That is the funny stuff and why I am so upset: I HAD them sorted in folders before, but SongKong didnt worked with those folders, so I was forced to copy all of them into ONE single folder … dont ask me why ! :roll:

You can see my settings in the video, maybe I did some wrong settings, but results are fine for me. I am not interested in albums or complitations, My “boss” just needs artist and title, he doesnt need more.

Yes, I know, but as long as SongKong doesnt tag my files I cant go further.

My third program I was forced to buy does a very good job with it, It cant tag, but identifies duplicates even without tags. So basicaly it seems not to be the only way to use tags. And even that I tried, but there was no difference with finding duplicates or tagging with SongKong, you can do a lower number of songs at once, but not a hugher one.

My other program had no problems to filter out duplicates out of 190000 songs at once. It took 24 hours, but ran total smooth …

As to say again: My recorded test-run did very well, also tagging-speed was VERY good, but that isnt the normal case. Also in my logs there have been many error because of “wrong audio”, but all files are OK, they are not damaged, it “must” be a fault in SongKong.
In my first run it reported over 500 damaged files, after restart, clearing database and logs it processed those damaged files, but it took up to 5 runs to get all files tagged, that is also not a normal case.[/quote]

I don’t want to argue with you but when you say things such as [quote]this data is also not stored anywhere. So it downloads data for lots of songs without saving them. [/quote] you sound like you are stating a fact but you are just totally incorrect. Shall we just try to solve the issue ?

So I watched your video and this test is against a single folder, as I explained if you had multiple folders then it would start the other tasks immediately. This the root of your problem having all the files in one folder. There is some logic in the code to try and deal with large folders containing many songs which is why it started trying to do some things before all songs in the folder were fingerprinted but essentially it works folder by folder.

So you say your originally had the files in multiple folders, if you still have this you should run SongKong against this. If not and you have want to use a separate file renaming program which I think would be the best choice you could try running SongKong with Match:Create Acoustic Fingerprints disabled. As long as your songs have some metadata this should put them into some semblence of order, then once you now have smaller folders rerun SongKong with Acoustic fingerprinting enabled to improve the results better. But also I notice you have set your rename mask to just an Artist folder, would make much more sense to group as Artist/Album folder.

As a software developer you must be aware of the 85% rule, and understand that having 900,00 file sin a single folder is pushing the limits.

So having added fingerprints SongKong trys to groups songs logically and then find potential releases, then it scores each release to find the release that matches all songs in the logical grouping most accurately. Now when you have loads of songs in a single folder it is harder to work out the logical grouping and sometimes you have songs potentially matched to a large release such as Mozarts 250 CD box set, sometimes comparing against such large releases can take a while. Now in normal circumstances SongKong would be processing multiple folders at the same time so a pause in matching one folder would be noticeable because other folders would still be getting matched. But if you are only matching one logical group/folder then there can be a bottleneck. I think this is the case here but really please send your support files it would make it much easier for me to diagnose your problems.

You are overthinking things, we do song only checks if artist, title fields are missing but this is just a precursor to try and do album matching.

Java works like this, when you start a Java application you define at the start the min and max heap memory to use. SongKong is configured to use a percentage of memory, since yo have 16GB it is configured to use about 2.6GB of memory. If you had less its max usage would be less. But the heap memory SongKong is actually using is shown in the bottom right hand corner of SongKong window and if you look at your video at time 4:24 you see it says 334MB and that is all SongKong is actually using at that point. Task Manager my show more being used and some of this will be the non-heap memory but essentially Java has already been allocated upto 2.6GB to use so it does not rush to release memory that it no longer needs when nowhere near that 2.6GB limit. So SongKong itself is not using excessive memory, and this is just the way Java works.

I do not understand why you think your video doesn’t show that. You don’t show the results on the filesystem at the end of the video but I can see nothing that SongKong does not do this.

I think I have had only ever had one other user to have so many files in one folder, I have looked at this issue before and will endeavour to improve for these isolated cases but as I say its the 85% rule. And it makes sense to concentrate on improvements for the many not the few.

Primarily users have bad and missing metadata within the files, duplicates and some random folders containing a complete mess. Bu they don’t actively organize their files in the way you have.

You should have contacted me at that point, you were not forced to copy them to one single folder you just decided to do that.

Most users care about albums, i.e if you have same song on an original album and a compilation they would want to keep both. In your case that doesn’t concern you so I expect this other program adds a fingerprints and deletes songs with same fingerprint. You can do this is SongKong as well just need to configure it right as it would be a very bad default.

[quote]
As to say again: My recorded test-run did very well, also tagging-speed was VERY good, but that isnt the normal case. Also in my logs there have been many error because of “wrong audio”, but all files are OK, they are not damaged, it “must” be a fault in SongKong.
In my first run it reported over 500 damaged files, after restart, clearing database and logs it processed those damaged files, but it took up to 5 runs to get all files tagged, that is also not a normal case.[/quote]
Again, I need the support files to address this.