Summary: | Long slotAboutToFinish() delays cause repeat of tracks + wrong current track to be displayed (external mysql database) | ||
---|---|---|---|
Product: | [Applications] amarok | Reporter: | Alan Ezust <alan.ezust> |
Component: | Playlists/Saved Playlists | Assignee: | Amarok Developers <amarok-bugs-dist> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | bart.cerneels, matej |
Priority: | NOR | ||
Version: | 2.5.0 | ||
Target Milestone: | 2.6 | ||
Platform: | Debian testing | ||
OS: | Linux | ||
Latest Commit: | http://commits.kde.org/amarok/cb3674aa81eeca4f85041eb77a42a33064362d59 | Version Fixed In: | 2.6 |
Sentry Crash Report: | |||
Attachments: | SqlPlaylist-don-t-observe-track-and-re-save-whole-pl.patch |
Description
Alan Ezust
2012-06-12 02:24:37 UTC
I just counted the number of lines of output that I clipped from the output above. Each line looked like this: amarok: saving track with url "amarok-sqltrackuid://2de48345e20824101da573bfc850f226" There are over 16,000 of these lines! Which happens to be the number of rows in my urls and statistics tables. Where is your external database located, on a remote share? How do you access this? via TCP, i access mysql via localhost. The drive is mounted locally. Adding a dummy comment so I can get rid of "needsinfo" status. Created attachment 71779 [details] SqlPlaylist-don-t-observe-track-and-re-save-whole-pl.patch Alan, please apply this patch atop of the current Amarok git master and report whether it fixes the problem for you. Good guide to compiling Amarok is at http://blogs.fsfe.org/myriam/archives/87 Waiting for reporter. I can't reproduce my original issue with the current amarok GIT trunk (so in other words, ahhh, much better!), but I am testing both that and the patched version to see if I can notice any performance difference. I will post more info when I have it. ok, the patched version definitely works better for me than the unpatched one. I tried running the latest unpatched git against my newer database, it upgraded the DB, hung, and when I re-ran it, I am seeing infinite saving track with url: lines and it is just stuck. So it seems the patch does resolve my issue! I would sign of on that patch, there is little benefit to live updates of playlists. On save is enough. (In reply to comment #9) > I would sign of on that patch, there is little benefit to live updates of > playlists. On save is enough. I agree, but we don't currently save playlists on Amarok close, do we? In case not, the playlist entries can become stale when url of the track changes while Amarok is running. Another alternative would be to store uidUrl() that shouldn't change, but that would require extending CollectionManager and Collections to add trackForUidUrl(). Yet another alternative would be to update just relevant tracks from SqlPlaylist::metadataChanged(). Git commit cb3674aa81eeca4f85041eb77a42a33064362d59 by Matěj Laitl. Committed on 13/06/2012 at 00:52. Pushed by laitl into branch 'master'. SqlPlaylist: don't observe track and re-save whole playlist on track change No other playlist does that and this causes problems when someone has really big playlists and slow connection to external MySQL db. Not updating track metadata should not hurt, these are immediately replaced by real ones by MetaProxy::Track. Moreover for uidUrl updates there is SqlTrack::updatePlaylistsToDb() (I don't however know whether it works as expected). Acked by Bart on the bug. FIXED-IN: 2.6 M +1 -0 ChangeLog M +0 -24 src/playlistmanager/sql/SqlPlaylist.cpp M +1 -9 src/playlistmanager/sql/SqlPlaylist.h http://commits.kde.org/amarok/cb3674aa81eeca4f85041eb77a42a33064362d59 |