right now I don't have the ability to move 115GB of files in a ext4 filesystem to make a final verification, but if you think I should mark the post as solved.

My collection lives on a vfat formatted USB disk.
Anyway. The scanner assumes same album name and no album artist set as a compilation. This is definitely too lightweight or "blauäugig" in german to get a decision. Especially when the album artist is not set to artist on single artist albums.
I've never ever tagged any albums with iTunes btw.. I always use the same tagger (easytag) so I can be sure all tags are consistent. I won't use amarok, because it deletes my CD number tags.
Mass tagging in Amarok doesn't really work. It hangs atm, because the scanner got hickups caused by me constantly changing the tags.
But we are moving further and further from the original topic. Maybe it should filled under a new topics.

joethefox, that would have been a real bug. Too sad it turned out to be NTFS.
I use jfs here. it's really nice.

quick question - before 2.4beta the tag "album artist" was not used by the collection scanner - correct?

quick comment - I just manually ran "update collection" and it seemed must faster and much smoother then I remember (including running it in earlier gits), is this true?

rengels wrote:Too sad it turned out to be NTFS.

you're right man, but if you have to share a filesystem with windows that supports file larger than 4GB, what is the right choose?
@Dieter Schroeder, maybe a vfat formatted USB disk is a worst case like mine, one might conclude that the new collection scanner update collection process is a filesystem stress? with iotop I can see a huge amount of data transfered during this process.

EDIT: I was thinking to move my collection in a NAS, but I can imagin that is not a big idea because I think that at the moment collection scanner will eat my network bandwidth(?) every minute. I will inform you about my tests.

VFAT is suboptimal, I know. Fact is, that there were no issues with the old scanner. And I still haven't got an answer why the scanner must run in intervals.

m0nk

Just to say this again:
Amarok assumes that a compilation has no album artist set. It should have several.
It also assumes that the pair album-name/album-artist is a unique identifier for an album/compilation.

So Amarok can't distinguish between several compilations with the same name.
It also can't handle two albums with the same name and artist.

The scanner will try to figure out how to put songs into albums or compilations. That is very easy if an album artist or the compilation tag is set.
If not, then we have to start guessing.

If you have proposals how to make this guessing better, then just drop me a mail. One of the benefits of the new scanner is that we should be able to implements such proposals quite easy.


If you have problems with classical music, you might want to set the composer as album artist.


And one point that Dieter mentioned. Track numbers.
The taglib is not able to handle track nr./total track nr. correctly. At least not without some additional work.
Also Amarok does not store or display the total track nr. or disc nr.
So once you set the track number (via Amarok) the total track nr. will be deleted.

As long as you don't set the number this information should be safe from modification.

Copied collection in a nfs NAS, rebuild Amarok collection to point only NAS and now during the "collection scanner update process" system cpu load remains near 0%. It's confirmed so what I thought: my issue was a ntfs-3g problem.
Now the numbers, an update collection is always about 60/70 seconds (last debug says [DELAY Took (quite long) 67s]) and remote nfsd daemon goes about from 10% to 20% during the update process for almost all time (sometimes 0%) and network load is (almost all the time) UP: 70.0 kB, DOWN: 100.0 kB (low network usage). Definitely a better situation. Only drawback: every minute for just over a minute there are processes that never stop to walk into filesystem; not a ideal situation for a music player, I think.

Perhaps you should use the guessing from the old scanner as a fallback. 4 albums with different artists, different genres, different years and in different folders can be assumed to be seperate albums and not a collection. We don't live in a perfect world, so there should be some kind of fuzziness in the scanner.
Oh, and you still haven't explained the sense of running the scanner in intervals.

m0nk

Watched amarok via top: amarokscanner took up to 90% CPU and playback stops. Scanner finshes and CPU increases to over 100% for amarok. It falls back to around 6% and playback resumes.
Core2Duo with 4GB RAM, so it should handle that.
And the scanning interval: I assume nobody has an answer to my question. How sad.

m0nk

Dieter: I too also have a c2d w/4gb running openSuse 11.3 (64bit) and though I see the watch collection (when enabled) spike it's not affecting playback even if playing from a vfat formatted thumb drive. What backend? I'm running phonon-vlc. Also, have niceness equaling 19 showing for Amarok.

Of course normally I've got the watch functionality disabled

Using xine backend and the hickups are intermittent. Perhaps it's an issue with phonon. My soundchip is greyed out, so I'm using jackd atm. I'm on KDE 4.6RC1.

m0nk

using xine backend my sound card was also grayed out that's why I switched to vlc (that and I read vlc was the best of the 3 options and the one being actively developed) - don't know if graying out was because of a kde upgrade or my removing HAL just that one day no sound

Greyed out options are caused by KDE 4.6 not using HAL anymore. I've now compiled VLC and backend. Let's see, whether it works better. I've used QMMP and had no issues with the playback there.
VLC crashes, when opening a file through the GUI. It will be removed, because I only need the libraries and the header files.

m0nk

vlc and phonon backend available in Packman repo, works fine for me

there does an exist an issue with opening files thru vlc, takes 20->30 seconds for the file selector to appear (iirc it's a dbus issue, but whatever it is it is known bug)