Title.

Running amarok --debug doesn't provide any useful information such as a filename so I can't determine what's causing the problem. I am just assuming it's an issue with a weird file.

Code: Select all

TagLib: ID3v2.4 no longer supports the frame type TDAT.  It will be discarded from the tag.
TagLib: MPEG::Header::parse() -- Invalid sample rate.
TagLib: MPEG::Header::parse() -- Invalid sample rate.
amarok:   BEGIN: void ScanManager::slotFinished()
amarok:   END__: void ScanManager::slotFinished() - Took 0.00018s
amarok:   BEGIN: void Playlist::PrettyListView::fixInvisible()
amarok:   END__: void Playlist::PrettyListView::fixInvisible() - Took 0.00023s
amarok:   BEGIN: void ScanManager::startIncrementalScan()
amarok:      scanner already running
amarok:   END__: void ScanManager::startIncrementalScan() - Took 0.00029s

I get that TagLib line about 50 times and the ScanManager part at the end just keeps running indefinitely. Amarok itself doesn't lock up. I can play individual files and even play with the settings.

Apparently it's not indefinitely, I just let it run for about 10 minutes and it finally started moving again.

Still seems like something worth fixing.

Which Amarok version?


Also try this (backup first):

Code: Select all

rm -rf ~/.kde/share/apps/amarok/mysqle

2.2

No effect since I'm using MySQL database. The problem also existed before I used MySQL. The change was an effort to fix which was not successful.

There have been quite some scanning improvements done for the upcoming 2.2.1, might be worth to be patient for another 10 days or so

Run "amarokcollectionscanner" from the command line on the directories you have selected for scanning. (You can use -r for recursive behavior). Using this and watching the output you should be able to narrow down exactly which file(s) causes the hangup(s). Then send the file to mitchell [a][t] kde dot org and I'll take a look.

jefferai wrote:Run "amarokcollectionscanner" from the command line on the directories you have selected for scanning. (You can use -r for recursive behavior). Using this and watching the output you should be able to narrow down exactly which file(s) causes the hangup(s). Then send the file to mitchell [a][t] kde dot org and I'll take a look.

It just flew right through with no long stops.

I have one folder that is much larger than the rest of my collection. Could it be that Amarok thinks the gianormous folder is the same size as my other folders?

Still, the command line collection scanner is much faster than when scanning in Amarok itself.

Also of note: if I try to cancel the scan at 43%, Amarok freezes.

If you start Amarok from the console with --debug and watch the output, after you kick off a full scan, you should be able to eventually see a line like
END__: void ScanManager::startFullScan() - Took X

If that happens before your long pause (but it might be buffered, so the X part helps determining this), the delay is in processing the data returned from the scanner -- in which case you should get a significant bump with 2.2.1 or current git.

If it happens after your long pause (assuming it didn't get buffered) then there's something strange with the scanner that you didn't reproduce running manually.

I'm guessing the former.