Katapult slows down to a near crawl when amarok is open

I forgot to mention that I use amarok 1.4.0 Kubuntu packages, so I haven't tried it with 1.3.8.

I am unable to reproduce this problem/bug. I have tried with amaroK 1.3.8 through amaroK 1.4.1. I have tried it in KDE 3.5.2 and 3.5.3 and was unable to cause this issue.

I just tested it on my laptop with KDE 3.5.3 and amaroK 1.4.0 and I'm still getting the same problem. The key to reproducing the bug is to add music to your music database in amarok, not just opening the program itself. I'm guessing that it has to be a fair amount of music as well, greater than or equal to 1 gig sounds like a reasonable amount.

On Wednesday 21 June 2006 17:24, fatejudger wrote:
> I just tested it on my laptop with KDE 3.5.3 and amaroK 1.4.0 and I'm
> still getting the same problem. The key to reproducing the bug is to add
> music to your music database in amarok, not just opening the program
> itself. I'm guessing that it has to be a fair amount of music as well,
> greater than or equal to 1 gig sounds like a reasonable amount.
>

Well, I know if you amaroK is updating it's database and you have a
signifigant amount of music, everything slows down. I have almost 100gb in my
amarok directory. Now when you start katapult with the alt-space, is amaroK
updating the database, or is it just idle with all the music sitting there
waiting to be played?

> --
> Katapult slows down to a near crawl when amarok is open
> https://launchpad.net/bugs/49901

I will admit though, that when I add music to my database, everything slows
down big time. Does your issue only occur with katapult or is it with
anything else you do when amaroK is adding music? Thanks alot for your reply
and information. Take care.
--
Rich Johnson (nixternal)
"The best thing about democracy is that it gives every voter a chance to do
something stupid."

Well obviously things are going to slow down a bit when amarok is adding music, that's pretty CPU intensive. I'm talking about not only during that process, but after as well. I can't say I notice any other programs slowing down after the music has been added, just Katapult.

I get this problem as well with Amarok 1.4.3 (Brandon's build) (only less pronounced - 6/7 seconds to respond or so), I just never realised that Amarok was causing the problem but closing it does make Katapult respond really sharply. I don't think that it is anything to do with resources as:

without Amarok open I'm running at 10% and memory at 53% usage
with Amarok open, I'm at 15% and memory at 59% usage

and I can replicate the fault with the resources like that...

That's a little excessive for an idle Jukebox but I wouldn't think it would cause Katapult to become this laggy as everything else still runs AOK.

Now that you have pointed out the cause of the fault I have found out that it is also causes the menu to appear slowly when right clicking on links/linked images through Konqueror (only Konqueror not any other browser). Also selecting multiple files on your desktop with the rectangle is so much smoother and less error prone than with Amarok running. Damn shame, I quite like Amarok and all.

I'm glad someone else was able to replicate my problem, as it was
disregarded and closed some time ago. This problem obviously needs to
be addressed, as many people currently use Amarok. As to the slowness
in Konqueror, I'm not on my Kubuntu computer at the moment, so I can't
confirm or deny it. I will, however, make a point of checking it out
and posting my results on here.

And now right clicking links on webpages works fine with Amarok on, maybe my earlier statement was a little premature and just coincidental that it straightened itself out after shutting down Amarok but that I have noticed that problem for some time now but never could find the culprit.

Katapult 0.3.1.2, KDE 3.5.5, Amarok 1.4.3, SuSE 10.1 install

Confirmed.

Installed Katapult because it sounded like a nice feature to have. Very sluggish. When typing the first few characters of "Firefox" it takes 5 seconds before they appear. Then i found this entry, closed Amarok, and the Katapult response became very flashy. Restarted Amarok, and back was the sluggish behaviour.

I have ~ 100 GB of music in my Amarok DB, but it's not indexing anything new when this is observed, just the std backgrounding. Top reports no significant difference in CPU use when Amarok is open.

Tor Arne

I have a temporary solution that is working for me:

Go to /usr/lib/kde3 and remove read, write and execute permisions from the files katapult_amarokcatalog.la and katapult_amarokcatalog.so

I never used Katapult for Amarok operations anyway but I am surprised this is rejected seeing as it is simply replicated.

Affecting multiple users

Hi there!

This is a known issue with amnThis is a known issue with using katapult and amarok.

Unfortunately, there isn't a "fix" as of such, as amarok is always going to be slow for us to access it's databaase.

However, there is a way to temporarily fix this issue.

If you load the configure Katapult menu, and look at the section startingh "Amarok Catalog" then you should be able to set the number of characters before it searches the amarok collection. If you set this to a higher numnber than 1, then the amarok collection will not be searched till after you have typed that amount of characters. I have mine set to 3, which I find useful

In 0.4, however, we do have catalogs running in their own threads, so this will solve this issue then.

for now, I will create a patch to make katapult use 5 chars before searching the amarok catalog by default.

Regards,
Martin Meredith

David, you can disable catalogs through the configuration window

Not a 6.10 blocker, removing milestone.

Sorry for the trouble gents, I never realised that you could get the configuration dialogue open by pressing ctrl+c on the Katapult translucency (I honestly tried every thing else that I could conceive before suggesting disabling the plugin).

Does that seem the right solution for you fatejudger, I think removing the functionality would be preferable as there will always be instances where you would have to enter more than 5 characters although I respect that's my preference and Martin's call.

I'm going to have to agree with David on this one. I suggest we
disable the feature entirely until each of the catalogs can have their
own thread. The slowness discourages many people from using Katapult
in the first place. If we disable the feature until it is coded
properly, then people enjoy the rest of the features that Katapult
offers.

On 10/17/06, David Taylor <email address hidden> wrote:
> Sorry for the trouble gents, I never realised that you could get the
> configuration dialogue open by pressing ctrl+c on the Katapult
> translucency (I honestly tried every thing else that I could conceive
> before suggesting disabling the plugin).
>
> Does that seem the right solution for you fatejudger, I think removing
> the functionality would be preferable as there will always be instances
> where you would have to enter more than 5 characters although I respect
> that's my preference and Martin's call.
>
> --
> Katapult slows down to a near crawl when amarok is open
> https://launchpad.net/bugs/49901
>

I'm bumping this, and the suggestion I would make is simply to not have the amarok catalog active by default. I'd question the usefulness of the plugin at all, and it does make Katapult useless for those who have large libraries.

Agreed. I'd be willing to sacrifice this not-often-used feature to
gain search speed.

On 5/1/07, Daniel Miles <email address hidden> wrote:
> I'm bumping this, and the suggestion I would make is simply to not have
> the amarok catalog active by default. I'd question the usefulness of the
> plugin at all, and it does make Katapult useless for those who have
> large libraries.
>
> --
> Katapult slows down to a near crawl when amarok is open
> https://bugs.launchpad.net/bugs/49901
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I'd suggest that this feature could be useful and possibly speedy if it was searching for Albums rather than just singles.

The number of characters before search has been moved back to 1 character in Feisty, so whom ever makes this call isn't interested that by default Katapult is rendered useless by this catalogue which is a pity as otherwise it is such a good tool.

A nice way to make it semi-fixed (apart from turn off the catalogue) is to use Mysql (or Postgres - I get better responses from Mysql) and the speed is enhanced quite a lot even with a small collection like mine of 300 albums/5500 tracks.

I had the same problem, but managed to reduce it by fiddling with the SQL query that the amarok catalog was using. On my MySQL database with around 10k songs, it reduced the query time from 0.36 seconds to 0.05. I've attached a patch.