Not sure about anyone else - on my box (Vista Home Premiumx64 SP2, Intel E8500, 4Gb RAM, ATI Radeon 5600), Songking sucks up a bunch of CPU, going anywhere between 30 - 90% as it works. This is with Songking as the only active program, working on around 300-400 songs in about 18 artist folders.
Also, I note that it does NOT play well with Calibre; the ebook program grinds to a virtual halt when running simultaneous.
Well generally users want SongKong to fix their songs as quickly as possible, so SongKong makes use of the cpu and multiple processers if your computer has them. Of course if it uses less cpu or only a single processor then it is going to run slower.
That said the start of Fix Songs is generally more cpu intensive because it is generating fingerprints for your songs, as the songs move to later stages cpu usage is less because the speed of matching is normally limited by the allowed query rate to MusicBrainz and Discogs.
In contrast to Jaikoz to SongKong does not need more and more memory for fixing more songs, but it will make use of cpu when it needs it. May be worth checking that you have free memory when using multiple applications, SongsKongs max memory is set to 500 mb, but this could probably be reduced if there was an issue.
Would you like an option to limit SongsKongs cpu usage ?
Hi Paul,
OT, but is it possible to increase the memory allocation for SongKong? I didn’t see any lines in the info.plist that looked like it could change it.
Regards,
James
HI Jamie, there should be no need to do that really, why do you want to do that ?
I thought more memory may do the trick:
Seems to be slowing down immensely. I’ve got a rather large folder I want to tag (c.20k songs.)
It was taking forever to load the files on my iMac (which has 16Gb memory and i7 processor) compared to my Macbook (which has 8Gb and i7 processor.)
Thought maybe it was memory management.
Purged memory on the iMac, and on the third time I attempted to clean up using SongKong (this morning before going to work) it loaded 2500 tracks within 15 minutes. [It only managed to load about 6000 when I left it alone over night.] So this morning after seeing how quickly they were loading, I thought there would be no problem and just left it and headed to work. (Thought I would wait until I get home to catch up with your post.)
But I get back tonight and only about 1000 tracks have been saved, after leaving it alone for about 14 hours. This seems to be much much slower than ever before despite having loaded rather quickly.
And Songkong has been allocated 1.23 G as I look at it right now, so memory is probably not, after all the issue.
I’ll send you the support files.
Cheers,
James
Hi
First please note that SongKong does not have to load all files before it starts fixing them, as soon as a folder is loaded it can start fixing them., so it trys to balance loading with fixing.
However having looked at your logs I can see you are encountering two issues:
Failing to save files with special chars on OSX :
http://jthink.net:8081/browse/SONGKONG-68
Failed to load ID3v22 files:
http://jthink.net:8081/browse/SONGKONG-165
Unfortunately I don’t currently have a fix for SONGKONG-68 I was hoping it would have been fixed by Oracle by this time, but I do have a fix for the SONGKONG-165 and a workaround
Workaround;
ID3v22 is rather an old format most people use ID3v23 or ID3v24 these days, and in fact if SongKong was able to load these files it would resave them as either V23 or V24 depending on your save options. You could use another application to change the tag version from v22 then you should be able to load the songs in SongKong.
Do you have a Jaikoz license, if so this is very easy as follows:
Setting Preferences:Save:ID3 v2 Tag:Always write Tag to V23 (or V24)
Load files into Jaikoz
Save files
Fix:
Ive emailed you a new jaudiotagger-2.0.4.jar file, put it into /Applications/SongKong.app/Contents/Java replacing the existing one this should allow those songs with ID3v22 tags to be loaded into SongKong.
There should be a new release of SongKong within a couple of weeks with more fixes and improvements
thanks Paul
There is maybe another possibility for high cpu & slow read/write performance I recently ran across in dealing with these issues in the forums of JRiver Media Center, my player, editor, tagger, database manager.
It seems that some a/v suites are designed to scan every tune that crosses some r/w threshhold. Norton and Zonealarm are at the top of the suspect list, but AFAIK nobody has published any definitive analysis of this questionable and/or uncontrollable scanning. If I had some way of measuring this scanning activity I would continue to review a/v suites; I have already eliminated 6 of the top suites last year for other reasons. Another annoyance and possible cause of slowdown is the fact that even after an uninstall, many suites (again some of the top contenders) leave active remnants requiring manual registry deletion or more…
I think the problem may be that the internal database used by SongKong was missing some reuired indexes meaning it was doing alot of daatbase table scans that it should not be. This is not really an issue when only working with a small set of files, but is a problem as the number of files increases.
Please try the beta of SongKong 1.2 at http://jthink.net/songkong/beta.jsp
Paul;
Can you clarify the issue of emptying the database? In my limited usage of SK I don’t need to maintain a database, and it appears that the size of the database (that I don’t need to maintain) is extremely large since it takes so long to delete it… “emptying” takes a helluva lot longer than Win Explorer, seems to me…
Now that SK is working fairly well, what reasons do I have to maintain my Jailoz install? If any?
I think I need only MBrainz access…for tag repair.
[quote=nickeaston]Paul;
Can you clarify the issue of emptying the database? In my limited usage of SK I don’t need to maintain a database, and it appears that the size of the database (that I don’t need to maintain) is extremely large since it takes so long to delete it… “emptying” takes a helluva lot longer than Win Explorer, seems to me…[/quote]
The database serves three main purposes:
Empty Database
Select Root Music Folder
Select Delete Duplicates and check preview only so it doesnt make any changes
Start.
When finished, close SongKong and restart
Select Delete Duplicates again (and check preview only so it doesnt make any changes)
Start.
This time see that it loads songs much faster.
It caches albums and artists downloaded from Musicbrainz and Discogs, so subsequent matches which require Jaikoz to check albums youve downloaded before are much faster because not subject to the Musicbrainz/Discogs one second per lookup limit.
It store changes made to your files, so you can revert the changes if SongKong has made a mistake.
The theory is that diskspace is very cheap, so it doesnt really matter how large the database is. However it is getting too large you can use Empty Database to clear it, or if SongKong is not running you can delete it using WIndows Explorer then SongKong will just recreate it on next startup.
[quote=nickeaston]Now that SK is working fairly well, what reasons do I have to maintain my Jailoz install? If any?
I think I need only MBrainz access…for tag repair.[/quote]
SongKong offers full automated matching.
Jaikoz offers full automated matching, with more options than SongKong.
It also offers semi-automatic matching, seperate Discogs matching, match to release by catno, barcode ectera.
Jaikoz makes it easy to do manual editing
Jaikoz allows you to submit new data to Musicbrainz
So if SongKong is working well for you, you’ll have to use Jaikoz alot less , but I wouldn’t remove it.
[quote=paultaylor]I think the problem may be that the internal database used by SongKong was missing some reuired indexes meaning it was doing alot of daatbase table scans that it should not be. This is not really an issue when only working with a small set of files, but is a problem as the number of files increases.
Please try the beta of SongKong 1.2 at http://jthink.net/songkong/beta.jsp[/quote]
You’re right,i agree with you.This is not an issue when working with a small set of files but is a problem as the number of files increases.
But this was an old issue that has been fixed, Im not aware of any database problems now. If you have the latest version of SongKong and our experiencing such problems please email me with details and support files (Help:Create Support Files)