Bug 349731

Created attachment 93425 [details]
output from link

This is the output of the mentioned link.

Please always attach outputs directly to the bugs database rather than link to external sources.

Hi ghost,
we would need a stack trace of all threads from the point in time where UI was frozen. Please follow this how-to: https://community.kde.org/Amarok/Development/DebuggingHowTo#Debugging_Hangs

Thanks.

Created attachment 93573 [details]
Terminal1 trace.

As described in the gdb trace, this is the trace of terminal 1 executing amarok.

Created attachment 93574 [details]
Terminal2 trace

Trace from Terminal2 using gdb at the point where the UI freezes up. I would like to note that when amarok outputs no space left on device, that there is actually about 400Gb of free space that it can write to. Importing a new track to the library works and does not give this error.

(In reply to ghost53947 from comment #4)
> Created attachment 93574 [details]
> Terminal2 trace
> 
> Trace from Terminal2 using gdb at the point where the UI freezes up. I would
> like to note that when amarok outputs no space left on device, that there is
> actually about 400Gb of free space that it can write to. Importing a new
> track to the library works and does not give this error.

Hi ghost, the backtrace is unfortunately only paritally usable as it lacks symbols for some critical libraries (threadweaver of kdelibs, Qt, libc). It also shows that the main thread was inside /usr/lib/libnvidia-glcore.so.352.21 library, which I think is a proprietary nvidia driver.

To proceed, we would need:
 a) better backtrace, https://community.kde.org/Amarok/Development/DebuggingHowTo mentions how
 b) is this reproducible also with open-source nvidia drivers?

The libnvidia-glcore might be due to running in opengl3 mode. I ran amarok in cinnamon same issue, but no mention of the nvidia. I will have to rebuild the kdelibs, Qt, and libc to include debugging symbols. Are there any other components that need to be rebuilt?

I believe I found one of the biggest culprits, Some of the folders had non utf-8 characters in them. I think this was causing problems when the scanning was happening.

Characters that display as "��r" in a linux terminal and file manager.

After finding that there were non UTF-8 characters in my folder names I remove all of those characters and then copied the music to an external drive and deleted the collection folder. After that I used Clementine ( because amarok took too long to discover the music ) to import the backup to a new collection folder again. I am getting the same error that there is no space left on the device. However when it happened the UI did not freeze as it did last time. Amarok keeps doing this process [AbstractDirectoryWatcher] addDirToList for "/mnt/MUSIC/Music/zzzzz/Music" . 

The UI  seems to freeze for a while when I see this output in the terminal: amarok: BEGIN: virtual void SqlScanResultProcessor::scanSucceeded() 
amarok:   BEGIN: virtual void AbstractScanResultProcessor::scanSucceeded() 
Media controls do not work either at this stage. 

Collection folder rights. drwxr-xr-x 1 frosted users  3108864 Aug 29 18:32 Music

Created attachment 94388 [details]
lines before and after the freeze happens

amarokcollectionscanner takes on the longest 1s to execute.

 In the console output I see the process "amarok: [AbstractDirectoryWatcher] addDirToList for" being run 2 or 3 times before the freeze occurs. As well as :
"QInotifyFileSystemWatcherEngine::addPaths: inotify_add_watch failed: No space left on device
QFileSystemWatcher: failed to add paths: /mnt/MUSIC/Music/{some folder}" being printed out.

Still waiting for a useful backtrace (see comment #5)

Amarok is a lot more stable since the last time I built. No problem while running it. 
Doing a "tools" update collection, causes the UI to hang still. 
Last times I saw before the hang and I had to force a SIGINT on amarok was 
"amarok: BEGIN: virtual void SqlScanResultProcessor::scanSucceeded() 
amarok:   BEGIN: virtual void AbstractScanResultProcessor::scanSucceeded() 
[Thread 0x7ffebbfff700 (LWP 6905) exited]
"
I have added the gdb.txt output

Created attachment 97318 [details]
Ui freezing on update library

(In reply to ghost53947 from comment #13)
> Amarok is a lot more stable since the last time I built. No problem while
> running it. 
> Doing a "tools" update collection, causes the UI to hang still. 
> Last times I saw before the hang and I had to force a SIGINT on amarok was 
> "amarok: BEGIN: virtual void SqlScanResultProcessor::scanSucceeded() 
> amarok:   BEGIN: virtual void AbstractScanResultProcessor::scanSucceeded() 
> [Thread 0x7ffebbfff700 (LWP 6905) exited]
> "
> I have added the gdb.txt output

I have installed Qt5 with debugging, used pyqt5-common-debug python-pyqt5-debug qt5-base-debug qt5-webkit-debug , from https://github.com/The-Compiler/qutebrowser/blob/master/doc/stacktrace.asciidoc#archlinux

(In reply to ghost53947 from comment #15)
> (In reply to ghost53947 from comment #13)
> > Amarok is a lot more stable since the last time I built. No problem while
> > running it. 
> > Doing a "tools" update collection, causes the UI to hang still. 
> > Last times I saw before the hang and I had to force a SIGINT on amarok was 
> > "amarok: BEGIN: virtual void SqlScanResultProcessor::scanSucceeded() 
> > amarok:   BEGIN: virtual void AbstractScanResultProcessor::scanSucceeded() 
> > [Thread 0x7ffebbfff700 (LWP 6905) exited]
> > "
> > I have added the gdb.txt output
> 
> I have installed Qt5 with debugging, used pyqt5-common-debug
> python-pyqt5-debug qt5-base-debug qt5-webkit-debug , from
> https://github.com/The-Compiler/qutebrowser/blob/master/doc/stacktrace.
> asciidoc#archlinux

You do realize that Amarok 2.8-master still depends on Qt4, don't you?

(In reply to ghost53947 from comment #14)
> Created attachment 97318 [details]
> Ui freezing on update library

the excerpt of the backtrace you posted shows a problem with libmysqld, and still lacks lign numbers

Closing for lack of feedback. Please feel free to reopen this bug if you can still reproduce this problem, taking into account the comments #16 and 17,though.