SongKong Jaikoz

SongKong and Jaikoz Music Tagger Community Forum

Database Issues...

#1

As my database approaches 1gb in size, SK begins to shut down processing prematurely. I ‘fix’ in batches of 1000 to 3000 and I have to delete the database after only a few fixes.

I recently doubled my RAM but see no difference. Is there any code adjustment to be made to allow the database to grow to several gb or more, and what advantage would that be? Is there any downside to deleting the database every day?

I am beginning a second round of re-fixing to try to see if MusicBrainz has noticeably more results than 6 months ago…nobody seems to know how static or dynamic the MB database is.

#2

I don’t see how if you are having to delete the database after only fixing 3000 files that the database could reach such a size ?

I don’t know if there such an issue with database size but emailing me your support files might help.

#3

The first two times I tried to use it, SongKong cancelled on me.

The third time, it “loaded” 47,000 songs and froze.

The marketing materials claim “any number of songs”, but is there a practical limit? Should I be batching in groups of around 3000 like Nick?

Thanks,
Jeff

#4

SongKong cancels on you if it encounters an unexpected exception, if that happens it is a bug. I have already fixed all known occurrences of this and a new version of SongKong should be available by next week, but it would help me if could send me your support files (Help:Create Support Files) so I can checked I have solved the particular issues you have had.

SongKong starts work on fixing songs a folder at a time without waiting for all files to be loaded so there should be no upper limit. Having said that the longer SongKong runs for the more resources are used over time, I think there still a few difficult to track down performance issues to resolve but if you have free memory performance can be improved by increasing the memory available to SongKong, for Windows this is set in the SongKong.ini file, for OSX you need to modify Info.plist, and for Linux songkong.sh

#5

Just sent you a log dump.

Unfortunately, my wife’s collection seemed to be so messed up, that I actually took all files OUT of their folders and into one big folder. The thinking was that I would have the ALL cleaned up. Hopefully the lack of folders does not have a negative consequence.

Thanks,
Jeff

#6

Hmm, actually SongKong works folder by folder in the first instance, as these normally represent an album, then if unable to match complete folder to one album it does matching song by song which is slower. So yes it will have a negative consequence but SongKong should be able to cope with it.

So when matching make sure you have SongKong set to Rename filenames based on Metadata when matched. Then after matching with SongKong I would run it again over all the songs because it can probably make some additional improvements working with songs sorted into an album per folder.

Checked your logs, and you are hitting a problem that has already been fixed, I hoping to have a new release out within a couple of days.

#7

Note that SK crashes when encountering corrupt files; certainly not the fault of SK. I have a number of tunes that fell off the back of a truck a decade ago, probably in the Napster days. I hafta use a process of elimination to filter garbage files out of my batches. Never found any software that finds corrupted and/or incomplete music files…

#8

[quote]it can probably make some additional improvements working with songs sorted into an album per folder.

Paul, are you suggesting that one can increase the number of fixes (MB matches) by using folders?

#9

This shoudn’t cause SongKong to crash, it should just ignore them.

#10

[quote=nickeaston][quote]it can probably make some additional improvements working with songs sorted into an album per folder.

Paul, are you suggesting that one can increase the number of fixes (MB matches) by using folders?[/quote][/quote]
Yes, definitently, are you saying your songs all exist in just one folder, surely that means browsing through them with your file browser is painfully slow.

#11

With corrupted files in the batch, here’s what I get:

“Found 3,010 songs, 4 have been checked before cancellation”

#12

Regarding using folders, I have used JRiver Media Center for a decade for all library functions; it is based on the old Jet database code and is lightning fast. Since I disregard Albums because my library is sortable on any tag, I have always avoided creating folders.

I write my files Name-Artist-Album and many files, especially classical, have quite long filenames–adding a foldername would put many over the Windows filename length limit.

#13

[quote=nickeaston]With corrupted files in the batch, here’s what I get:

“Found 3,010 songs, 4 have been checked before cancellation”

[/quote]
This shouldn’t happen, and I believe to be fixed in the forthcoming SongKong 1.6

#14

[quote=nickeaston]Regarding using folders, I have used JRiver Media Center for a decade for all library functions; it is based on the old Jet database code and is lightning fast. Since I disregard Albums because my library is sortable on any tag, I have always avoided creating albums.
[/quote]
Yes, when viewing within a library by metadata folders have no relevance, but most of us also find ourselves accessing the songs as files through the filesystem from time to time.

True, although it is only actually a limit in Windows Explorer not Windows itself, however SongKong enforces this limit. You could use songkong to output the foldername upto a max number of chars (i.e album.substring(0,20) to avoid this problem.

#15

@nickeaston

I have a second copy of my collection done in this way which i use for testing jukebox software. I sort mine by alpha\artist\songName.mp3 Sometimes if there are duplicate songs and I can tell they are different renditions, I may add the date to the end, or if a song is live and it was only ever performed live, i may add a live tag to the end.

For example,

c:\q\queen\another one bites the dust.mp3

I find it least makes the libraries load far quicker when browsing via file explorer.