Bug 359382 - Clicking Merged View causes apparent hang (100% CPU use)
Summary: Clicking Merged View causes apparent hang (100% CPU use)
Status: RESOLVED NOT A BUG
Alias: None
Product: amarok
Classification: Applications
Component: Collection Browser (show other bugs)
Version: 2.8.0
Platform: Mint (Ubuntu based) Linux
: NOR crash
Target Milestone: 2.9
Assignee: Amarok Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-14 10:19 UTC by Bernd Wechner
Modified: 2016-06-12 12:53 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bernd Wechner 2016-02-14 10:19:33 UTC
Merged View is poorly documented. I don't know what it does, or is intended to do.

The KDE Help Center simply says: Displays the podcasts in a merged or unmerged view.

Which tells me little.

So I clicked it to see what happens. And it kills the Amarok UI. Linux still responds, even the menu on the Amarok system tray icon still displays, but Amarok responds to nothing.

It sits there with 100% CPU usage (I am on a twin core i5 machine) and seems to do so beyond my patience limits so I kill it (with -9) and it doesn't respond to polite request. I restart it and all is good, but if I click the Merged View button again - go to beginning of this report.

I have repeated this a third time juts for fun ;-).

Now for context I have Local Collection selected when do this and it is hosted on a QNAP NAS and does have over 200,000 tracks in it. 

Still,  the behaviour is puzzling given a lack of clarity as to what this button is actually doing.

I'd call this a bug. You may disagree, in which case triage appropriately of course. But at very least I would expect:

1) Better documentation as to what Merged View actually is
2) If the operation is going to take so long a clear progress indicator with cancel option.

Lacking either doesn't meet with my expectations as a user I admit.

Reproducible: Always

Steps to Reproduce:
1. Start Amarok, with a local collection hosted on a network accessed NAS mounted on the local Linux file system, that contains a large number of tracks (> 200,000)
2. On the Media Sources pane navigate to Local Collection
3. Click the Merged View button

Actual Results:  
Amarok UI hangs.
Amarok is using 100% of CPU (presumably 1 core of the 2 cores on my box as Linux responds still)


Expected Results:  
Amarok continues to respond
If it's an extremely expensive operation: a progress indicator with a cancel option
Documentation that describes what to expect (what the heck is Merged View?)
Comment 1 Myriam Schweingruber 2016-02-14 13:03:43 UTC
AFAIK this is already fixed since quite some time, could you please check out amarok 2.9 beta? might be also called 2.8.90 in your distro
Comment 2 Bernd Wechner 2016-02-14 22:48:45 UTC
Hmmmm, am remote now, but had a quick look.

Running the build on a dev machine:

1) It identifies itself as:

Amarok
Version 2.8-git
Using KDE 4.14.2

and was build a few weeks ago from latest pull from github. Can update later today, rebuild and try again.

2) For context I am using an external database on another machine (a media server), and the actual media is stored on a third machine (a NAS).

3) I can navigate my media library just fine in the Media Source panes, all good. Can't play anything, Amarok just falls over (yet to diagnose but I think it's because it fails to find the media file to play trying to access the wrong place because the devices table in the media server isn't consistent with the mounts on the dev server ... I'll fix that later and see).

4) That said, navigating the Local Library works fine. If I click the Merged View button the pane clears eventually refreshes and Amarok seems to hangs still. 

Take this with a grain of salt until I try on-site as I'm remote now and don't trust the remote connection much (clouds performance experiences with its own lags and issues - using teamviewer). 

The crucial thing still missing is a clear indication of what Merged View is actually hoping to do though.

(As an aside, as I posted on the dev group, I'm still trying to work out how to build on the dev machine and run the binary on the media server - another issue).
Comment 3 Myriam Schweingruber 2016-02-14 23:34:16 UTC
JFYI: you shouldn't pull from github, that is only a mirror, our sources are on git.kde.org. Also be aware that we have two different branches currently, Amarok 2.8-git which is master and amarok kf5 which is the ongoing Qt5 port, still in pre-alpha stage.

Merged View does merge the various media sources into one, so if those are a mix of local and remote, it takes quite some time to retrieve, especially if you have a very large collection and if you set the Collection Browser view to show the covers, and the "automatic Cover Art" retrieval is active. So please try not to use the automatic cover retrieval and cover view in Merged View, that should solve the problem. BTW, a collection on a NAS is not local, that is only if all the tracks are on the same machine you are running Amarok on.  Using the Merged View with remote collections has always be rather problematic, as it depends on a lot of factors that can make this last forever.

As for the other problems you mention: please let's keep bug reports to one item at a time, else this is impossible to handle.

FWIW: we have a support channel #amarok on irc.freenode.net (ask your question and stay around, we are not online 24/7), and a forum on http://forum.kde.org/amarok. The bug reports should be reserved for bugs only, not for support request or build problems.

Finally: please run amarok in debug mode so you have a konsole output when this is happening, so at least we have an idea what is going on (and it's also much easier to attach a backtrace when it freezes).
Comment 4 Myriam Schweingruber 2016-06-12 12:53:32 UTC
Closing for lack of feedback. Please feel free to reopen this report if you can provide the requested feedback.