Version: 2.3.2 OS: Linux Reproducible: Always Steps to Reproduce: 1. Add a track to playlist. 2. Generate a moodbar file for that track. The moodbar does not appear, even after removing and adding the same track again. 3. Restart Amarok. Now you can see the moodbar in track progress slider.
This is an automated message from the triager: Amarok 2.4.1 has been released on May 8 already. Could you please upgrade and test if you can still reproduce this bug? Without feedback within a month we will close this bug as resolved. Thank you for your understanding.
Still happens with 2.4.1.
Thank you for the fast feedback :)
Still happens with 2.5.0. It's kind of annoying, I've a script that will generate moodbars for any file in the playlist but of course it's effectiveness is somewhat reduced as the change cannot be seen till restart.
It seems that the "MoodbarManager" is in charge of finding the moodbar file and then it appears that "PrettyItemDelegate::paintItem" is called to render the moodbar. However, when MoodbarManager runs I do not know. I have seen 12 files added to the playlist and subsequently the MoodbarManager looking at the files and my script starting (independently). The MoodbarManager looked at the first 7, finding and doing nothing. Only after that point had my script managed to finish any moodbar files. In fact it was able to complete all 12 moodbar files and touch the containing directory before the MoodbarManager ran again for files 8 onwards, where it found moodbar files and rendered them. Why did it stop at 7? and why not, after the containing dir was touched, did it not update?
problem persists with 2.6-git
Amarok doesn't need to be restarted to pick up moodbar files. As stated in the manual [1]: "Note that the moodbars will not appear in Amarok until Amarok rescans the collection." After generating .mood files, just click on Tools -> Update Collection This is by design; I'm changing this bug to wish. [1] http://userbase.kde.org/Amarok/Manual/Various/Moodbar
That is not even a wish but should just be closed as it can't be reproduced. FWIW: there was a caching bug with the collection prior to 2.7.90, might have been fixed in the same commit.