Version: 2.3.0 (using KDE 4.4.2) OS: Linux If I edit a song's tag or rating from either the playlist or from the Context View applet, the changes are not saved when using an external MySQL database for the collection. Such changes are saved when using the internal database. Reproducible: Always Steps to Reproduce: No special steps required to reproduce. Simply edit a rating from the Context View for example. The stars will change. Actual Results: Observe that the rating shown in the playlist does not change. Right click on the track and display the track details; observe that the rating has not in fact changed. Open the MySQL database and observe that the rating as stored in the "statistics" table for the track has not changed. Expected Results: The rating should change in the playlist and should change in the track details; meaning, the rating should be saved to the MySQL database.
Please check your permissions for the external MySQL, this should not work differently from the embedded one.
Database name is amarok; user name is amarok; user amarok has every assigned privilege I can find in the MySQL Administrator. Plus, if it were a permissions problem, would you not expect that saving tag/rating info from any part of amarok would fail, as opposed to only specific parts?
Thank you for the feedback.
I can't replicate this. Using current git, mysql 5.1.46.
I can reproduce this with amarok-2.3.1, external mysql 5.1.50. I recently migrated to external mysql and have the problem since then. Any ratings that are changed 'via plasmoids' are not persistent. However. When I open a single song's info and change the rating there it will be saved to the database. Can you please reopen this bug?
I'll reopen, but changing the component.
Hmm, a reboot later it seems to work. Now I can't reproduce this anymore. Weird. When I had the issue I tried restarting the mysql server and restarting amarok, but that did not help. For me it's gone for now.
I'm not sure why you keep focusing on the mysql database, but as you found in #5 the issue has to do with the plasmoid, not the database...
Well, I never had this problem while I was using embedded mysql in a file. It was triggered when I migrated to external mysql. That's why I would say the current summary misses that point.
As the original bug reporter, I will confirm what Thomas says. This bug only happens when using an external mysql database. When using the embedded database it does not happen. I can also confirm, per comment #7, that this bug is intermittent. It went away on me for quite a while, then resurfaced again recently, then went away again. I can't pin down the circumstances that are triggering it.
If the bug is intermittent, then I would need proof that it's triggered by the external database. The code in Amarok for external vs. internal is almost entirely the same -- all that is different is simply the original calls that connect to the database. The only difference I've ever seen between the two databases is if one of them simply doesn't work at all (like if there are issues connecting to it). Maybe it's possible that your distro packages have some strange problem with mysql embedded vs. external, but that would be a super strange bug.
*** Bug 251908 has been marked as a duplicate of this bug. ***
Confirmed by duplicate.
Hello, I filed the duplicate bug. Now I find that it works... don't know what happened really. I just restarted the app, than it ran for a while, and when reading this bugreport I checked the database page in the config settings. Didn't really change anything there, only viewed it. Now it works.
forgot to add: the "use external mysql database" setting was turned off on the database page.
Tom, in comments #14 and #15 you clearly lay to rest the idea that this has anything to do with internal vs. external database. Can we please not focus on the database as the issue here? All actual evidence instead points to issues with the plasmoid.
Is this still valid with current 2.4-git? I can't reproduce this here at all (never could earlier either, btw).
I can't reproduce this here at all, most likely already fixed.