easytag is very very slow

I noticed Easytag is getting slower as the journal fills up. Emptying the journal regularly helps to keep decent performances.

This problem was fixed at least in the version 2.1.3

Frederic Jacquot wrote, the 19/02/2008 01:55 :
> I noticed Easytag is getting slower as the journal fills up. Emptying
> the journal regularly helps to keep decent performances.
>
>

This issue has not been fixed, as I experience it with easytag 2.1.4-1 in Ubuntu Hardy. It's taking 2-3s per file, just to change a tag. The CPU usage is 100% on one core at all times during this process. My system specs are not the issue (Core 2 Duo, etc). I'm using XFS.

Hey,
recently I tried easytag 2.1.6 with kubuntu gutsy and I noticed the same bug. It took over 2hours renaming about 2.000 songs with a Celeron 1,6GHz.
As described by Hew McLachlan it takes 2-3s per file. But is it really an issue of easytag? I don't think this problem appears on other linux distributions!?

Looks like it does some heavy processing in UI thread, as the whole UI is frozen when applying tags. Things like this should be done in background so that UI stays usable.

Looks to me like EasyTag does a reload or refresh of the entire list of files after saving a change to one file. This explains why the time-per-file grows with the number of files in the list.
I'm on 2.1.6 compiled 14 Nov 2009 and the problem is still there.

I just tried Ex Falso to test the claims I see here. I've always used Easy-Tag before.
Copied 500 random AAC tracks to a desktop folder.

Easy-Tag processed all 500 in 5 minutes.
Ex Falso processed all 500 in 5 seconds flat.

Yes I would agree something is wrong when it takes 60 times longer to complete the same task!

Just like Jaco Salvi wrote. I launched a mass fix (no idea what it wants to fix btw) 16 hours ago on 12500 tracks and easytag 2.1.6 is still busy on a 3.0Ghz quad-code system. It obviously refreshes the entire list after every fix.

There are too many updates in UI during batch editing.
Simple commenting out some of them (status bar, for ex.) leads to faster processing.
Freezing of the entire UI using the same method shows amazing speed value.

In addition to what other said the list of files keeps updating even when just going from file to file (pg-up/pg-down), it takes forever to just go from file to file. The width of various columns number of times everytime I press pg-up or pg-down. This might depend on width of various elements (i.e. not sure if it happens always).

@pcix how did you manage to freeze the UI while saving files?
easytag is really good but the UI "flood" is making it unusuable for alot of files.
do you still have the source or a patch file? :)

greetings

Hi. Using Easytag 2.1.7 in Arch. 13,700 files takes 7sec. per file to rename with a quad core i7. I think this is unacceptable to continue to update this program without addressing this bug. It was present 4 years ago when I used ubuntu, and has always been a bother. It is a shame because easy tag is, in my opinion, the best program out there for managing a music database. why is so hard to fix - freeze the window during saving, and don't update it until the save completes.

IThe bug was fixed upstream, this is the patch

The attachment "speed.patch" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

Fixed in upstream 2.1.8, pleas update the package

Can we please get a newer version of this. EasyTag released 2.1.8 on 2013-2-10.

I'm updating 1300 files, it's on 295 after 15 minutes. I can walk away for a while, but this redrawing of the entire list after almost any action just makes this a large chore.

2.1.8 fixes this issue. But beware that a severe regression affects 2.1.8: if passed a file name or directory name, easytag will jump to / and then read the whole tree (or try to and hang) if the read subdir automatically option is on.
See https://bugzilla.gnome.org/show_bug.cgi?id=693613
The speed-up is great but this bug is a real showstopper.

dobey ppa and debian's package from http://packages.debian.org/sid/amd64/easytag/download are affected.

Was fixed in 2.1.8-1 (trusty)

I think is not fixed: 2.1.10 is still very slow to load a specific directory (72 MP3 files), with NO SCAN SUBDIR set.
My system summary is here http://pastebin.com/7rqt9Caj

I think is not fixed... suite

since I've posted the previous commend, Easytag didn't finished scanning that directory yet ....

Hi ggallozz

This bug is about slowness during tagging, but it sounds you're getting slowness when searching directories. Can you see if it affects 2.2.4 (it's in vevet)? Does it affect another directory with roughly the same number of files? Is the directory strange in any way? If there is a bug, can you open a new bug and I'll look at it in a few days when I'm back at my main computer.

James

It's extremely slow in 2.2.2

Absurdly slow, unusable in 2.4.3. Uninstalling... Too bad it was my favorite.