Version: 1.4.10 (using KDE 3.5.9) OS: Linux Installed from: Debian testing/unstable Packages [This is http://bugs.debian.org/493550] When amarok crashes the changes made to the playlist since the last time amarok was closed are lost. Although https://bugs.kde.org/108814 talks about the same problem, it also covers another issue which was fixed long time ago. It would be great if the undo/redo issue is fixed so the playlist is saved when changes are made.
We used to have this feature, and we had to remove it for some reason which I don't remember. I'm not sure if this reason is still valid for Amarok 2.
Well, performance reasons. And it is still valid for 2.0.
*** Bug 158548 has been marked as a duplicate of this bug. ***
is a bug...
*** Bug 227146 has been marked as a duplicate of this bug. ***
*** Bug 173904 has been marked as a duplicate of this bug. ***
I believed the replacement of SQlite by MySQL in Amarok 2 would have solved this problem. Is there any plans to improve the situation ?
Amarok also forgets all songs played in the last session before the crash, and loses all relevant statistics, all of which are not desirable behaviours.
This should be fixed in Amarok 2.4.-git now, can somebody test, please? I can't reproduce this here, but I have my system running on an SSD so this might just be fast enough to save everthing.
Closing for lack of feedback. I can' reproduce this here, using Amarok 2.4-git of today with KDE 4.6 beta 2 on Kubuntu 10.10
The problem still exists for me in 2.4-beta1, even in 2.4-git from today. Steps to reproduce: Start Amarok, add some songs to the playlist, let it play. Open terminal, enter "killall amarok". Start Amarok again and look at an empty playlist.
Sorry, but killing is not a correct way to test a crash. Reopening anyway, as I have an SSD here and am not really the person who should test that.. Please somebody with Amarok 2.4 beta or 2.4-git can reproduce this with a real crash?
(In reply to comment #12) > Sorry, but killing is not a correct way to test a crash. It seems to me that killing amarok is a very good way to simulate a crash or an unexpected power failure. And I don't see how a running on an SSD would affect matters - if changes aren't persisted to disk, it doesn't matter how good the access latency is.
I confirm that if you kill Amarok after changing the playlist, you loose this last playlist and you get an older one. To reproduce : 1. You open Amarok with a playlist 'A' 2. With Dynamic Playlist, you regenerate a new one (called 'B') 3. Start to play and jump to the first track of addes tracks 4. killall amarok 5. Restart Amarok 6. You should get playlist 'A' Git version of 2010-12-09 (maybe master 48db5b88f44cb6fd3af07524dc216b2ded763bfd)
I can also confirm that for true crashes in 2.4-beta, sometimes happening when skipping tracks while the label applet is shown.
I also confirm the losing of the playlist on a crash. 2.4.0 crashed a few times for me today and I lost the playlist each time. (Unfortunately, when I recompiled it with debug info and ran in gdb, it wouldn't crash :( )
How about saving the playlist every now and then? We are currently working on a solution to make Amarok do so, but this will not come before 2.4.1 at earliest. Of course, a crash is immediate, so there is no time to save anything, but by saving the playlist in intervals we could at least have one saved. Ideally we will have a non crashing Amarok at some point :) Do you have an idea why it crashed? Just to make sure the case is already reported.
And why not save it after each change ? Is it too often ? In fact, I think the problem is not only a crash in Amarok but a crash in the system (Xorg restart, kernel crash, power cut even if these events don't occur really often)
I agree with comment #18 - why not save the playlist each time it's modified actually? I think it'd make most sense and is quite intuitive IMO.
(In reply to comment #19) > I agree with comment #18 - why not save the playlist each time it's modified > actually? I think it'd make most sense and is quite intuitive IMO. Did you read comment #17?
Yes, I did in fact. To be honest, I really don't like the idea of a program doing something every now and then :P I believe it is best to stick to the on-change saving. As for the reason of the crash - I've really no idea. Just after installing amarok 2.4.0 I couldn't get past the config auto-upgrade. This problem was gone after a reboot. Then a few times I experienced in a row I was experiencing crashes. I don't know the reason but I think that it happened when I had the repeat-playlist mode on and the playing was about to start over from the beginning. After recompiling amarok with debug symbols, when I was ready to prepare a backtrace, the crashes disappeared. I even recompiled amarok once more with the original flags and still haven't experienced any issues ever since.
I guess the 'performance problems' mentioned come about when making many changes to the playlist in a short space of time, resulting in a flurry of writes to disk? Perhaps a way to avoid this is simply to schedule a save a few seconds after the playlist changes.
I can confirm the loss of playlist AND every statistics -- automatic like play count, and manual like ratings -- when crashing "normally" (if a crash can be normal). (comment #8) I'm using amarok v2.4.0 (2:2.4.0-0ubuntu2~maverick1~ppa1). I'm don't know much about amarok ways of saving things, but it seems to me that saving statistics should be done on the fly. And the amount of information is so low that it should be done without any performance problem. That or saving processes are b0rked ?
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.
Bump target.
I can confirm this bug on Amarok 2.4.3. I don't know if it is related, but my playlist gets lost also after closing KDE session without closing Amarok first.
(In reply to comment #26) > I don't know if it is related, but my playlist gets lost also after closing KDE > session without closing Amarok first. I think this can happen when the system is low on memory and amarok is partly swapped to disk. Then shutting down amarok takes longer than usual because things need to be swapped back in so that they can be torn down properly. And, on logout, programs are killed if they take more than 10 seconds to shutdown - thus amarok times out and is killed before it has a chance to save the playlist (this can also happen with other programs, e.g. firefox and saved tabs). So yes, it is related. Crashing, being killed by the user or being killed by the session manager are all interchangable if the playlist hasn't been persisted to disk.
Git commit bde537bb2f150ee49e980e97e4bcffd72e4bdb0c by Alex Merry. Committed on 26/08/2011 at 16:36. Pushed by alexmerry into branch 'master'. Auto-save the playlist so it is not lost if Amarok crashes We save the playlist when it is changed (waiting 5 seconds in case there is a flurry of changes).