Amarok hangs during tagging of FLAC files

I can not reproduce this in dapper (amarok 2:1.3.9-0ubuntu2).

should be fixed by:

    * Do not call TagLib::MPEG::File for non-mpeg files - some FLAC files
      would cause the CPU to start running in circles. (BR 107029)

It happens for me too, on the Gutsy with the latest updates. However, it seems that it is ntfs-3g who is eating CPU time, because the same operation works in about 10 seconds on the ext3 disk, while it took about 3 minutes on a NTFS one.

A screenshot with htop is attached.

I was not using NTFS at the time of my original report.

Please see the most common reasons for high NTFS-3G CPU usage at http://www.ntfs-3g.org/support.html#cpu100

I also do remember a problem in amarok what one of the above items also suggests and Waster's comment too who doesn't use NTFS. Maybe you don't have the fix Sarah mentioned?

Few tests: changing an Artist field in 13 files (340.4 MB total):

A. Files are not in the collection:
1. ext3 - 16 seconds
2. fat32 - 24 seconds
3. ntfs-3g - 1 minute 35 seconds

B. Files are in the collection

3. ntfs-3g - 9 minutes 33 seconds (look at update times on the screenshot - pretty interesting and unusual)

I would say the main problem is the database being rebuilded ultra slow. I have closed amarok, moved testing directory from ntfs to ext3 disk (both places are in the collection), and opened amarok again to perform test B1, but it is now rebuilding collection for the third time already, and the whole thing lasts about 20 minutes, so more results later.

Software versions:
amarok - 2:1.4.7-0ubuntu3 (to Szaba: that's the latest one, so it's unlikely that a patch that was committed more than a year ago didn't made it to this version)
ntfs-3g - 1:1.913-2ubuntu1

After I have finished that B3 test, everything went unstable. Amarok started to update database collection, it took a few minutes (normally - about 10 seconds), and after completion it starts to update collection again, and that lasts forever. Attemp of any action (play track, go to settings) leads to a hang. I had to kill amarok, but after restart I faced the same issue.
After all, I removed folder with flac files from the collection path on the NTFS partition and started amarok. Everything went fine. Then I moved into the collection folder on the ext3 partition and ran test B1 (flac files in the collection on the ext3) - 18 seconds.

Reproduced once again on NTFS. Now the file update process (according to file last modification time) took 2m 30s, and after that amarok hung. This time I didn't have a forever update database loop after restart, though.

So, do you suggest that there is a problem using FLAC files with Amarok and NTFS-3G? If yes, then please do the following as root at the command line:

     umount <ntfs_mountpoint>
     mount -t ntfs-3g <device> <ntfs_mountpoint> -o debug &> ntfs-3g.log
     reproduce the problem
     umount <ntfs_mountpoint>

and then send here or to <email address hidden> the ntfs-3g.log file. Thanks.

Who is using CPU when amarok hangs, and can you find anything in the /var/log/daemon.log file?

During tag update mount.ntfs-3g consumes CPU nearly 100% for some amount of time, though, this amount of time seems reasonable to me - like ntfs-3g does it's job like it should. Then for some period CPU load is low - amarok is doing something, and sometimes these periods are really large - like four minutes in my second screenshot. After the tag update process finishes, amarok starts to behave unstable - doesn't respond, hangs for some time, then unhangs, does database updates a few times in a row (last time all these processes ended 10 minutes after the last file was updated, and amarok still has the tendency to hang from time to time on few seconds) - but CPU usage stays low.

In my opinion, it's not ntfs-3g problem, but amarok (and/or maybe underlying libs - libflac, whatever) one. I had amarok/mp3/ntfs-3g triplet working ok for quite a long time now, but today as I tried flac for the first time, I encountered the whole bunch of problems.

I will test more on ext3, and if I would be able to reproduce this behaviour on ntfs-3g only, I'll go for ntfs-3g debug.

I remember an amarokcollectionscanner high memory usage problem. That could also cause all kinds of weird problems.

Memory usage is not high.
/var/log/daemon.log is ok

ntfs-3g.log attached

Thanks a lot Evgeny. Amarok (or the FLAC codec) indeed uses very unoptimal write buffer size which significantly worsen the performance: http://ntfs-3g.org/support.html#dd

I'm not sure that this is unique to amarok...
I have the same problem updating the tags with rhythmbox on an ntfs partition. Mount.ntfs hogging all of the CPU, at least 30 seconds to change a tag.

Since the FLAC library is doing the inefficient I/O thus any software is affected which uses it.

I'm sorry - I forgot to include something in my original post. I meant to
say that I have the problem for mp3s in rhythmbox as well as mp3s in amarok.

On Nov 7, 2007 2:50 PM, Szabolcs Szakacsits <email address hidden> wrote:

> Since the FLAC library is doing the inefficient I/O thus any software is
> affected which uses it.
>
> ** Changed in: flac (Ubuntu)
> Sourcepackagename: ntfs-3g => flac
>
> ** Changed in: flac (Ubuntu)
> Status: New => Confirmed
>
> --
> Amarok hangs during tagging of FLAC files
> https://bugs.launchpad.net/bugs/24063
> You received this bug notification because you are a direct subscriber
> of the bug.
>

@apecar:
If you have 90+% NTFS-3G CPU usage then please send the
debug log following the instructions at
https://bugs.launchpad.net/ubuntu/+source/amarok/+bug/24063/comments/9

and after that the full output of
egrep -i 'dma|sd|ntfs' /var/log/daemon.log*

Oliver, is this still an issue with Amarok? There's been a whole lot of updates to Amarok between breezy and present.

This issue has been fixed ages ago upstream, current Amarok is 1.4.10.1
Please close this bug.

People have still 2 weeks to give feedback to Andrew's question.

Assuming fixed then.