_From virtualshuric on July 19, 2012 10:49:28_
What steps will reproduce the problem? 1. Start Clementine post-1.0.1-nightly on Windows (clean install without profile or upgrade from 1.0.1)
Integrity check and database backup pass successfully (parallel to updating library). Setting ratings on existing songs works fine (ratings are persistent between app restarts)
"clementine-tagreader.exe" sits in process list (with constant 0% CPU and memory usage) - I don't know if it's intended behavior. Also Clementine crashes on exit. What version of the product are you using? On what operating system? 1. Clementine nightly-builds (w/podcasts and moodbars)
_Original issue: http://code.google.com/p/clementine-player/issues/detail?id=3064_
_From virtualshuric on September 23, 2012 23:30:11_
Hello, are there any activity on the issue? Or is there any additional information I should supply?
_From virtualshuric on September 27, 2012 20:58:06_
The problem is still there with 1.1RC
_From [email protected] on December 11, 2012 09:27:31_
This happens to me with the linux version 1.1.1 on Arch Linux. I'm going to have to use another media player for now since clementine won't add any of my new music.
I'm seeing this on an x86 Ubuntu 14.04 LTS system.
Still seeing this on an x86 Ubuntu 14.10 system. It appears to be a zombie process/thread that just randomly gets stuck. Even after closing Clementine, I then have to kill it via the CLI
i haven't experiencied this problem a couple of builds ago. mine now is Version 1.2.3-726-g38c5150 and is working fine.
It's still happening for me, but a lot less. There was a recent build where it would happen within a minute of closing the app and then closing the process* and rebooting.
i still get the 2 most annoying clementine bugs. clementine not closing and tagreader gets freezed, so i cant change my tags, nor see them when i try to edit them.
Not sure if this helps but got this from the terminal when it stuck
15:31:48.069 DEBUG TagReader:793 Setting FMPSFrame: "FMPS_Rating" , "1"
15:31:48.080 DEBUG LibraryWatcher:345 "/media/sabret00the/My Passport/__music/My Music/Army Of The Pharaohs/aotp - dont cry.mp3" changed
15:31:48.081 DEBUG TagReader:119 Reading tags from "/media/sabret00the/My Passport/__music/My Music/Army Of The Pharaohs/aotp - dont cry.mp3"
15:31:48.081 DEBUG TagReader:420 Parsing FMPSFrame "FMPS_Rating" , "1"
15:31:48.082 DEBUG _MessageReplyBase:24 Waiting on ID 2
15:31:48.166 DEBUG MessageReply<MessageType>:90 Releasing ID 1 (finished)
15:31:49.608 DEBUG MainWindow:1324 position 10 scrobble point 108 status 0
15:31:59.608 DEBUG MainWindow:1324 position 20 scrobble point 108 status 0
15:32:09.608 DEBUG MainWindow:1324 position 30 scrobble point 108 status 0
15:32:19.608 DEBUG MainWindow:1324 position 40 scrobble point 108 status 0
15:32:28.600 DEBUG Playlist:1656 Setting metadata for QUrl( "file:///media/sabret00the/My Passport/__music/My Music/Army Of The Pharaohs/AOTP - Bust 'em In featuring Reef The Lost Cauze, Apathy, Celph Titled.mp3" ) to "Army Of The Pharaohs" "Bust 'em In (Feat. Reef The Lost Cauze, Apathy, Celph Titled)"
15:32:28.707 DEBUG Playlist:1656 Setting metadata for QUrl( "file:///media/sabret00the/My Passport/__music/My Music/Army Of The Pharaohs/AOTP - Bust 'em In featuring Reef The Lost Cauze, Apathy, Celph Titled.mp3" ) to "Army Of The Pharaohs" "Bust 'em In (Feat. Reef The Lost Cauze, Apathy, Celph Titled)"
15:32:29.608 DEBUG MainWindow:1324 position 50 scrobble point 108 status 0
15:32:39.608 DEBUG MainWindow:1324 position 60 scrobble point 108 status 0
15:32:49.610 DEBUG MainWindow:1324 position 70 scrobble point 108 status 0
15:32:59.608 DEBUG MainWindow:1324 position 80 scrobble point 108 status 0
15:33:03.869 DEBUG Database:584 Starting database integrity check
15:33:04.387 DEBUG Database:645
hmm , i tried compiling the app myself, and it _seems_ to work fine. but only compiling from source.
i tried using valgrind and i think there where a memory corruption somewhere but im not sure. Maybe it works well because i'm compiling with qt 5.4 sdk. or maybe it's something related to 64b.
Though i've also compiled it with the system's environ (gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) and Qt 4.8.6, Ubuntu 14.04)
the process pool seems weird to me, some pointers might get deleted right after they get initialized, not sure. (i dont remember well because i did it some time ago)
i think each process pool's pid (or id) gets stored in the struct to later see which one replied. When i debugged, all the proccesses got the SAME id, and the db got stuck. as soon as i forcekill one of those processes, clem spawned some more tagreaders and worked fine...
i dont get why you dont use qt's pools features http://qt-project.org/doc/qt-4.8/qtconcurrent.html
(yes i know multiprocess!=multithread but at least it could leverage the pool part (which smells fishy to me (imvho)))
here's my bin version https://www.dropbox.com/s/40lccn1htw77n9f/nande-clementine-dev-997a38fab813803f78d44a02b0cf8b3468b7e9bd.zip?dl=0
based on commit 997a38fab813803f78d44a02b0cf8b3468b7e9bd
On the current nightly, it will freeze on Updating Library reliably when switching hard disks. Currently my music is stored on two separate disks (local partition and external hard drive).
It seems to link to https://github.com/clementine-player/Clementine/issues/4851
OS: Linux Mint 17.1 x64 (Cross-platform, so I figure though this is a Windows issue too, it's probably a generic issue.)
Current Build: Version 1.2.3-1158-ge7e3ab1 (e7e3ab1)
I also seem to find an issue with it going into an "Updating Library" loop, I don't get any related debug information when running from console, a reliable way for me to run into this issue is if I change the rating of a song that's currently playing.
This is running off a network mounted volume and off a FLAC file type, though it seems to go into this loop after a few minutes of playing without any intervention.
The update loop also prevents Clementine from exiting which is expected.
This is still happening. I'm on Version 1.2.3-1280-g10860b7
Any idea how can i help with this? Is getting really annoying.
I can't edit songs, and i can't either exit.
i tried to run valgrind on it, but is SO slow... i got it loading and playing. but still haven't got stuck...
each time it loads it shows some errors.
I had some modules not compiled because the dependencies are a little too much for me... i tried to compile one or two more to see if that triggers something.
Output is http://pastebin.com/34tgsAct
Valgrind said http://pastebin.com/sija9qJu
CMakeCache http://pastebin.com/4NqEYPXf
I tired again, compiled with everything, and ran a valgrind until it got stuck.
this are the results. Though valgrind didn't notify me when the lib got stuck... so maybe (and most probably) this is a side-effect of another thing.
Valgrind said http://pastebin.com/2mEnX1df
Output was http://pastebin.com/xRx8faeF
CMakecache is http://pastebin.com/vk5dqC0L
And just in case it helps reproduce it this is how my setup looks like http://screencloud.net/v/wAX4
I recall once i tried debugging this, and the client-id for the tagreader on the communication library that used that weird google thing seems to have gotten overriden with an older id, every tagreader seemed to have the same id, an invalid one. though im not sure.
So I got a new laptop and hoped the issue would be one of the past. I've now moved my library to my NAS but despite that, I'm still seeing issues with it getting stuck. I think since I'm now on Ubuntu 64 bit it's no longer preventing Clementine from closing. But it remains frustrating. I wonder if @davidsansome has any insight on this long-standing bug?
after this #5129 i haven't seen the bug again.
i even have the "monitor library for changes" option on.
I'm still seeing this.
thats bad. maybe this can help, but have you tried disabling to monitor folders? that helped me once

Stopping it from monitoring changes only hides the problem. You can tell because album art stops changing.
I got this bug now after updating to Clementine 1.3 on Ubuntu 14.04. I tried re-reading the library but after it's done it will go into "Updating 0%" forever, not changing covers, and four (!) instances of "clementine tag reader" are shown in the system processes each using 1,1 MB of RAM.
Same issue here (Clementine 1.3.1 on Ubuntu 14.04). Definitely related to modifying mp3 files (ID3 tags/rating), most likely when one of tracks being modified is currently playing. Probably deadlock?
There are errors in log file like this one:
22:41:02.441 ERROR logging:54 Source ID 638 was not found when attempting to remove it
Deleting rating of a song currently playing:
23:13:41.898 DEBUG TagReader:795 Saving song rating tags to "/xxx/yyy/zzz/06 Descarga Zamot.mp3"
23:13:41.901 DEBUG TagReader:863 Setting FMPSFrame: "FMPS_Rating" , "0"
23:13:41.922 DEBUG MessageReply<MessageType>:90 Releasing ID 637 (finished)
23:13:41.923 WARN unknown QWaitCondition::wakeAll(): mutex lock failure: Invalid argument
23:13:41.923 DEBUG LibraryWatcher:606 Subdir "/xxx/yyy/zzz" changed under directory "/xxx" id 1
23:13:44.630 DEBUG LibraryWatcher:343 "/xxx/yyy/zzz/06 Descarga Zamot.mp3" changed
23:13:44.630 DEBUG _MessageReplyBase:24 Waiting on ID 638
After this, the library gets stuck in "Updating library" forever. I can play songs, but I cannot modify tracks any longer.
It seems easy to reproduce, happens almost all the time! It seems like there is some deadlock related to the fact the file is modified, played and monitored at the same time?
Please fix, this is really annoying.
I can confirm that if I disable the Monitor the library for changes option problem disappears. I will use this as a workaround for now.
i get really annoyed by this issue.
i tried to debug it once, i'm not a genius and the protobuff bloat makes it harder to see.
BUT as far as i could see, the thing is this:
it creates workers and stores some sort of pointer to its info. but, at some point the worker crashes*1 and as it makes use of some sort of pointer auto-delete functionality, at that point, all the references are changed to the same worker, or to an invalid worker.
so when it tries to command the workers it always fails. That's why under specific conditions, if you kill the only worker that is being referenced, more workers are created though the other workers are still alive.
usually those workers end up being orphaned.
*1 this has something to do with the monitor library, and the fact that the tagreader-worker is a separated process, it think modifying and reading the file at the same time from different proccess might make some problem, but at the end i put all the blame on that protobuff stuff.
seems unnecessary for me between two process, a simple qlist of subproccess transfering some json is more than enough.
I can confirm that if I disable the Monitor the library for changes option problem disappears. I will use this as a workaround for now.
This.
Hmm, unfortunately there are problems even with Monitor the library for changes disabled. I have modified comment of a song (not currently playing one) and now I cannot edit any other track information. The window "Edit track information" is stuck with "Loading tracks..." message indefinitely.
Most definitely directly related to #4950, which suggests a fix.
I found a fix for this after googling for a while and not finding this suggestion. My suspicion was that Clementine was choking on some file it couldn't access or do something important with. I tried disabling "update library" etc. This is on Ubuntu 14.04 x64 with Clementine 1.3.1. Here's the fix that worked for me:
This got it working for me, hopefully it works for you!
The workaround didn't work for me. Still the same problem (ratings get lost + 0% on updating library)
Just to explain @naraesk, once the background services get stuck, Clementine is unable to update ratings and generally everything just gets broken. The work around above isn't a one size fits all as it's a genuine bug that @davidsansome or @hatstand hopefully will get around to looking at sooner or later. Anyway, when things get stuck, all of the ratings are only stored to file and not to the mp3s themself and thus any time Clementine has a heart attack and poops the bed, those ratings are lost.
Well, then I'm not sure if my bug (#5429) is really the same. It's not only that ratings/metadata will not be updated correctly, but 2 years old ratings just get lost by accident, even if the files were not played/opened/edited.
Remove and re-add your library folders if you're sure that all ratings are already sync'd to your files.
I'm getting a very similar issue. For seemingly no reason, Clementine now displays on start up "Updatinglibrary", followed by a percentage that varies (usually 33-34%). Also, Unicode characters don't display. This is how they're displayed.
This is present even after deleting my config files and reinstalling Clementine.
I tried doing what @calltheninja said but it didn't work.
64-bit version on Arch Linux
I am having the same problem using Version 1.3.1-228-gd9b3a93 (from me-davidsansome) on Mint 18 64-bit.
After starting Clementine I am able to edit some ID3 tags for a while, but then inevitably it will get stuck with "Loading tracks" message. I have tried the various suggestions given above, but none of them have had stopped the problem from occurring.
When the problem last occurred, the following debug message was output:
10:28:59.144 DEBUG _MessageReplyBase:24 Waiting on ID 362
This is very frustrating as Clementine has all the functionality that I was looking for, but this bug makes it very difficult to work with as I have to keep killing and restarting it before I can edit any more tags.
same issue here Clementine Version 1.3.1 on Mint 16.04. please fix
777 and detox did not work for me.
Actually, my issue was fixed by generating proper locales, in my case I needed to att ja_JP.UTF8.
鈥嶪nteresting,聽I have lots of songs with Asian names (Chinese Japanese and Korean) as well as some Russian.聽But I don't know if I have the locals聽 From: Ketchup901Sent: Saturday, April 8, 2017 05:48To: clementine-player/ClementineReply To: clementine-player/ClementineCc: Nande!; CommentSubject: Re: [clementine-player/Clementine] Clementine (Nightly Windows build) stuck with "Updating library 0%" (#3064)Actually, my issue was fixed by generating proper locales, in my case I needed to att ja_JP.UTF8.
鈥擸ou are receiving this because you commented.Reply to this email directly, view it on GitHub, or mute the thread.
{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/clementine-player/Clementine","title":"clementine-player/Clementine","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/clementine-player/Clementine"}},"updates":{"snippets":[{"icon":"PERSON","message":"@Ketchup901 in #3064: Actually, my issue was fixed by generating proper locales, in my case I needed to att ja_JP.UTF8."}],"action":{"name":"View Issue","url":"https://github.com/clementine-player/Clementine/issues/3064#issuecomment-292704614"}}}
This seems like it could be multiple bugs rolled into one github issue. If people who've done some debugging see that that's the case, maybe file separate issues and reference this one? This is an annoying problem and it might be more likely fixed if when a dev comes along they don't have to wade through an entire confusing ticket.
This issue still persists on me. Running Ubuntu 16.04 LTS with Clementine 1.3.1-353-gfcceab3.
I already generated the necessary locales for songs with Japanese characters. Before generating the locales, Clementine indeed kept on failing to load some albums with Japanese characters in their filenames, but after I generated the locales, it could properly load everything.
But if I have "monitor library for changes" enabled in the Preferences, before long the "Loading library 0%" would show up again and the area at the bottom left where it would usually show basic information of the currently playing song would also freeze.
I could play other songs just fine, but that area would remain frozen with information of the last song it played before it froze.
Afterwards I'd also be unable to edit track information because the UI would stuck on "Loading tracks" or something.
UPDATE: Turns out I also had some UTF-8 issue. After I fixed that, I also ended up enabling all supported locales, even so Clementine still have this issue.
UPDATE 2: Seems like it will only happen randomly when it's playing a song. If I just leave Clementine be for hours without playing anything, it won't trigger the fail.
UPDATE 3: I don't know anymore.
Been having the same issue for some time too. Linux Mint 17.x and Clementine 1.3.1-333-gf854bc5 . Have not used Clementine for a few months, and decide to use it again as it was easy to control via remote. Stuck at "updating library 0%" and the remote is not getting current info as to track info. shows only the initial song played back, along with no album art. Frustrating as I feel Clementine is one of the best players out there.
Alright, continuation to my previous post, here's my latest settings in Preferences > Music library:
[x] Update the library when Clementine starts
[x] Monitor library for changes
[ ] Save ratings in file tags when possible
[ ] Save statistics in file tags when possible
and in the past 7 days or more, it has been working just fine.
At first I thought it had something to do with Last.fm scrobbling but fortunately it wasn't that. I've been scrobbling with that settings as well and it didn't bug out.
Some other details:
I also had this issue with Clementine 1.3.1-397-gd71651db7 on Ubuntu 17.04. I fixed it by following the advice given by @calltheninja and @BobbyWibowo:
Quick note: Do NOT use dotex if you have any non-english filename or at least check first by using -n (dry-run).
For anyone encountering this, a potential cause is Malwarebytes. It affects v1.3.1, 1.4.0rc1 and the Strawberry fork.