 |
|
You are not logged in.
Hi,
I have musikCube (cvs02192005) set to synchronize automatically when it runs. My library has about 7500 songs. Even though no new songs are added, if I close then re-open musikCube it takes a long time (several minutes) to add files. There is no disc activity during this time, but really high CPU usage (99%).
This did not occur for me with the previously released 0.92 build. Thanks again for a great programme,
willT
Offline
Okay, heres the problem. I added this into the last version for checking if a file already exists in the database.
SELECT COUNT(*)
FROM (
SELECT songid
FROM SONG_TABLE_NAME
WHERE LOWER(filename) = LOWER('%s')
);
Notice the LOWER(filename) = LOWER('%s')... this does a case insensitive check to see if the filename exists in the database. I did this because some people were getting duplicate files... as an example:
c:Test.mp3
c:test.mp3
c:TeSt.MP3
Would all show up as separate entires, even though they are the same file (in windows). The reason its lagging down is because all the strings have to be converted to lowercase before checking. A solution is to make sure, in windows, that all filenames in the database are strictly lowercase. Does anyone have a problem with this?
Casey
Offline
I have no problem with this. I just thought that the core is meant to be platform neutral. And with this move you would be giving that up, because lowercase filenames don't work on linux.
try this: don't simply store filenames that are added by the user, maybe typed in manually. use something like CFileFind::GetFilePath when importing a file to determine the real name with correct cases.
maybe this fixes the dublicates. if it doesn't I'll gladly help to find the bug. I'd rather spend time debugging this than adding a workaround with sideeffects.
...but that's just my answer to your question. In the end I don't care as I don't use media players on my linux machine 
Offline
Well, write now I just have a simple #ifdef...
#if defined(WIN32) || defined(__MINGW32__)
filename.ToLower();
#endif
Not a big deal. If we don't do this, the bug still remains. Consider this case: The user imports a file, lets call it:
c:artistAlbumTitle.mp3
He later notices that "artist" should be "Artist", with an upper case A. He renames the directory in windows explorer, so the real path is now:
c:ArtistAlbumTitle.mp3
Next time he synchronizes the database does this:
if ( !IsFileInLibrary( filename ) )
AddFile();
Because c:artistAlbumTitle.mp3 is a different string than c:ArtistAlbumTitle.mp3, the file gets added to the database again, under this updated name.
On the other hand, the old file is no longer removed from the database, because the synchronization routine also does this:
for ( i = 0; i < songcount; i++ )
if ( !filexists( songs[songcount].filename ) )
RemoveFile()
But as far as windows is concerned, the two files are the same, so the old instance never gets removed.
Any ideas?
Casey
Offline
I thought about this for a while, and you're right, it seems this is the best solution. The only real side-effect would be that you can't share a database between operating systems, which (aside from being quite a hypothetic situation at this point) is probably not something a lot of people will miss.
one could also cache the result of LOWER('%s') by pre-generating a lowercase'd vector of all filenames in the db and thus only querying the db once before synchronizing; but as IsSongInLibrary isn't only called while synchronizing one would effectively have to introduce a caching scheme that keeps track of library changes, and that would make it quite a large effort.
so yeah, do it.
by the way I spent the last couple of hours browsing the sourcecode and I'm continually impressed by not only the clean design but also the very readable code.
Offline
I would rather not have my filenames all be lower case. One reason: it seems like a drastic measure. A better reason: sometimes a capital is necessary... my band's name (no laughing) is:
Craig Jokela's Armada featuring willTthrill and the Dude
the "willtthrill" part needs the capital T. This is only one (stupid) example, but I'm sure there are other cases where a capital is needed to make sense. Even though the ID3 info will have the capital, I think it should be in the filename too.
Please forgive me if this is overly simplistic:
I have not looked at the source code, but after reviewing the above posts I think I understand the problem more or less. Is there an ignoreCase() comparison like java in c++? Would it be faster than toLower()? I'm surprised to see that the process of converting to lowercase takes so much resources.
willT
ps, the band's name is an obscure "Kids in the Hall" reference.
Offline
Hmm, well the way to do a case insenstive query is this...
SELECT *
FROM SONGS
WHERE LOWER(filename) = LOWER('C:MyFilename.Mp3');
When doing this query, the database first queries all references tuples (rows/instances) in the filename column, then must convert them to lower case. Then it converts the input string to lowercase and compares the input with EACH of the newly converted lower case strings. This query must be done once for each input song entered. This means that the larger the database gets, the slower it starts to perform when doing this
WHERE LOWER(filename) = LOWER('...')
Casey
Offline
If I understand correctly, the proposal is to store the filenames in the database in all lowercase. The filenames on disk are not affected and can have any wierd case you want. That seems fine to me.
Offline
bclemmen, you are absolutely correct. it will NOT physically rename the file on your system (that would be bad)
Offline
i updated to the new cv version, how can i have sync to be like it used to?
it will NOT physically rename the file on your system (that would be bad)
yes that would be bad! i'm glad i had it wrong. i suppose in that case it doesn't really make much difference for windows only use. that's probably most people.
i updated to the new cv version, how can i have sync to be like it used to?
this must be a common feeling. will the next cvs build implement the lowercase database file? auto-sync is currently unusable given the incredible cpu drain. even going back to the duplicate file bug while the lowercase thing gets sussed would be most helpful.
Offline
I will try to post an update tonight, possibly tomorrow morning. I'll post it in the general forum. Sorry guys, I've been very busy lately.
Casey
Offline
What is going to be different? The method for sorting?
Offline