Lost settings on abnormal shutdown

Hi there,

I reported a bug a while back
(https://bugs.kde.org/show_bug.cgi?id=198987) about how various settings
seem to get lost whenever amarok is terminated in any way other than by
right-click -> Quit on the systray icon.

Anyway I just updated to 2.2, and still get the problem. While it may be
a KDE/Qt problem, it does only happen to me in Amarok.

Does anyone here have any ideas on what might be going on? Since I don't
see others complaining, and as it's quite a pain, I've been presuming
that I'm in a minority of people affected by this. Is this the case?

Any tips would be greatly appreciated.

Thanks,
Mike.
_______________________________________________
Amarok mailing list
Amarok@...
https://mail.kde.org/mailman/listinfo/amarok

On Sat, Oct 17, 2009 at 9:24 AM, Michael Liddle <michael@...> wrote:

> I reported a bug a while back
> (https://bugs.kde.org/show_bug.cgi?id=198987) about how various settings
> seem to get lost whenever amarok is terminated in any way other than by
> right-click -> Quit on the systray icon.
>
> Anyway I just updated to 2.2, and still get the problem. While it may be
> a KDE/Qt problem, it does only happen to me in Amarok.
>
> Does anyone here have any ideas on what might be going on? Since I don't
> see others complaining, and as it's quite a pain, I've been presuming
> that I'm in a minority of people affected by this. Is this the case?
>
> Any tips would be greatly appreciated.

Well. Amarok remembers _some_ "settings" after a crash, but not all.
Let me go into more detail:

What we do store immediately (syncing HDD) is all normal settings from
the "Configure Amarok" dialog. As soon as you press "Ok" or "Apply",
those are stored on your harddisk.

However, some things are not stored immediately, partly for
performance reasons, and partly because we forgot (detailed hints
welcome). One example of data that is not stored immediately is the
current playlist. Some users have giant playlists (like 10,000
tracks), which I find a bit crazy, but that's how things are. Storing
this after each modification is quite slow, performance wise. It could
be done, but it's complicated. I have some ideas for implementing this
in the future.

I should also mention that with traditional application design such
data is always stored on shutdown. Only lately it has become a trend
to store this data immediately, as it makes things crash persistent.
Generally I think this is a good trend.


Alright, I hope I managed to explain this properly. Any more questions?

--
Mark Kretschmann
Amarok Developer
www.kde.org - amarok.kde.org
_______________________________________________
Amarok mailing list
Amarok@...
https://mail.kde.org/mailman/listinfo/amarok

(Resending to list too, sorry Mark)

Mark Kretschmann wrote:
> However, some things are not stored immediately, partly for
> performance reasons, and partly because we forgot (detailed hints
> welcome).

Major one's I've noticed:

- Changes to widgets (added/removed/moved)
- Changes to the main window layout (i.e. the new dockable panels in 2.2)
- Playlist (see below)

Album covers seems to have been fixed in 2.2.

> One example of data that is not stored immediately is the
> current playlist. Some users have giant playlists (like 10,000
> tracks), which I find a bit crazy, but that's how things are. Storing
> this after each modification is quite slow, performance wise. It could
> be done, but it's complicated. I have some ideas for implementing this
> in the future.

Hmmm... well the rationale here seems fairly sound: incremental saving
of these settings shouldn't be particularly noticable to the user.
Although, I'm with you on the massive playlist being a bit crazy (though
I do listen to much music on a fairly "traditional" album-by-album
basis). Thinking of myself mostly (I rarely have more than 200 tracks in
the playlist), would it be possible to save the playlist immediately if
it's less than a certain size?

> I should also mention that with traditional application design such
> data is always stored on shutdown. Only lately it has become a trend
> to store this data immediately, as it makes things crash persistent.
> Generally I think this is a good trend.

While crash resistance would definitely be cool, the major one for me is
 when I log out. If I didn't explicitly quit amarok from the systray,
all of the above are lost. I don't know how it works (TERM signal?), but
it'd be great if its possible to handle this like a "normal" shutdown.

Thanks,
Mike.

>
>
> Alright, I hope I managed to explain this properly. Any more questions?
>

_______________________________________________
Amarok mailing list
Amarok@...
https://mail.kde.org/mailman/listinfo/amarok

On Sat, Oct 17, 2009 at 11:40 AM, Michael Liddle <michael@...> wrote:
> Mark Kretschmann wrote:
>> However, some things are not stored immediately, partly for
>> performance reasons, and partly because we forgot (detailed hints
>> welcome).
>
> Major one's I've noticed:
>
> - Changes to widgets (added/removed/moved)
> - Changes to the main window layout (i.e. the new dockable panels in 2.2)

Ok, that's interesting. As these are rather new features, we probably
forgot to sync to HDD. I assume we'll be able to fix this.

>> One example of data that is not stored immediately is the
>> current playlist. Some users have giant playlists (like 10,000
>> tracks), which I find a bit crazy, but that's how things are. Storing
>> this after each modification is quite slow, performance wise. It could
>> be done, but it's complicated. I have some ideas for implementing this
>> in the future.
>
> Hmmm... well the rationale here seems fairly sound: incremental saving
> of these settings shouldn't be particularly noticable to the user.
> Although, I'm with you on the massive playlist being a bit crazy (though
> I do listen to much music on a fairly "traditional" album-by-album
> basis). Thinking of myself mostly (I rarely have more than 200 tracks in
> the playlist), would it be possible to save the playlist immediately if
> it's less than a certain size?

Well, no, that would be a kludge I think. I would prefer to solve it
properly. My idea is using multi-threading for saving the playlist,
and also storing it in the database, which may be faster than storing
as XSPF.

>> I should also mention that with traditional application design such
>> data is always stored on shutdown. Only lately it has become a trend
>> to store this data immediately, as it makes things crash persistent.
>> Generally I think this is a good trend.
>
> While crash resistance would definitely be cool, the major one for me is
>  when I log out. If I didn't explicitly quit amarok from the systray,
> all of the above are lost. I don't know how it works (TERM signal?), but
> it'd be great if its possible to handle this like a "normal" shutdown.

That's definitely not normal. When you log out from your desktop
(let's say KDE), the desktop sends all applications the TERM signal,
then waits a few seconds, then sends KILL to apps that haven't shut
down yet. TERM does the same as a normal shutdown (Quit). So, what
happens here is either your Amarok takes too long to shut down, or
your desktop does something incorrectly.

As for Amarok, start it with "amarok --debug --nofork" from the
terminal once. It will print tons of information. Click "Quit" in
Amarok, and then check if you can see anything weird in the debug
output (it provides timing information too).

--
Mark Kretschmann
Amarok Developer
www.kde.org - amarok.kde.org
_______________________________________________
Amarok mailing list
Amarok@...
https://mail.kde.org/mailman/listinfo/amarok

Mark Kretschmann wrote:
> Well, no, that would be a kludge I think. I would prefer to solve it
> properly. My idea is using multi-threading for saving the playlist,
> and also storing it in the database, which may be faster than storing
> as XSPF.

Yes, well this obviously makes much more sense :)

> That's definitely not normal. When you log out from your desktop
> (let's say KDE), the desktop sends all applications the TERM signal,
> then waits a few seconds, then sends KILL to apps that haven't shut
> down yet. TERM does the same as a normal shutdown (Quit). So, what
> happens here is either your Amarok takes too long to shut down, or
> your desktop does something incorrectly.

Desktop is KDE. See below for timing and behaviour on TERM...

> As for Amarok, start it with "amarok --debug --nofork" from the
> terminal once. It will print tons of information. Click "Quit" in
> Amarok, and then check if you can see anything weird in the debug
> output (it provides timing information too).

Under a "normal" shutdown, App::~App() (which I presume corresponds to
quit?) takes around 1.4s, although I'm not sure how different this would
be after swapping bits of the application out of memory etc... (I have a
pretty old laptop, with only 512M RAM).

Anyway, when I send a TERM signal to the process (`killall amarok`)
App::~App() was not called at all (or at least it doesn't show up in
that debug output). Should/could it be?

Thanks,
Mike.

>

_______________________________________________
Amarok mailing list
Amarok@...
https://mail.kde.org/mailman/listinfo/amarok

On Sat, Oct 17, 2009 at 1:29 PM, Michael Liddle <michael@...> wrote:
> Mark Kretschmann wrote:
> Anyway, when I send a TERM signal to the process (`killall amarok`)
> App::~App() was not called at all (or at least it doesn't show up in
> that debug output). Should/could it be?

Erm, I guess I got the signal wrong. It's not SIGTERM (this terminates
instantly indeed). The desktop is probably using a different
method/signal. But anyway, the result is that it makes the application
quit.

--
Mark Kretschmann
Amarok Developer
www.kde.org - amarok.kde.org
_______________________________________________
Amarok mailing list
Amarok@...
https://mail.kde.org/mailman/listinfo/amarok

 Lørdag 17. oktober 2009 13.39.43 skrev Mark Kretschmann :
> Erm, I guess I got the signal wrong. It's not SIGTERM (this terminates
> instantly indeed). The desktop is probably using a different
> method/signal. But anyway, the result is that it makes the application
> quit.

I think it uses dbus (at least if it is the same method as `kquitapp` uses).

--
Martin T. Sandsmark
_______________________________________________
Amarok mailing list
Amarok@...
https://mail.kde.org/mailman/listinfo/amarok

Martin Sandsmark wrote:
>  Lørdag 17. oktober 2009 13.39.43 skrev Mark Kretschmann :
>> Erm, I guess I got the signal wrong. It's not SIGTERM (this terminates
>> instantly indeed). The desktop is probably using a different
>> method/signal. But anyway, the result is that it makes the application
>> quit.
>
> I think it uses dbus (at least if it is the same method as `kquitapp` uses).

I'm way out of my league here in terms of C++/KDE/Amarok programming, so
please forgive me if incorrect, but according to
http://techbase.kde.org/Development/Tutorials/Session_Management,
MainWindow should implement saveProperties. It doesn't seem to.

Mike.

>

_______________________________________________
Amarok mailing list
Amarok@...
https://mail.kde.org/mailman/listinfo/amarok

On Sat, Oct 17, 2009 at 2:17 PM, Michael Liddle <michael@...> wrote:
> I'm way out of my league here in terms of C++/KDE/Amarok programming, so
> please forgive me if incorrect, but according to
> http://techbase.kde.org/Development/Tutorials/Session_Management,
> MainWindow should implement saveProperties. It doesn't seem to.

So I've just tested this myself, to be sure. Logged out from KDE
(version 4.3.2) with Amarok running, logged in again. Amarok
remembered everything fine, including the playlist.

It did however not work with "-m --nofork", which I sometimes use for
development. But I assume you're not using these options anyway, as
they're not default.

--
Mark Kretschmann
Amarok Developer
www.kde.org - amarok.kde.org
_______________________________________________
Amarok mailing list
Amarok@...
https://mail.kde.org/mailman/listinfo/amarok

On Sat, Oct 17, 2009 at 12:23 PM, Mark Kretschmann <kretschmann@...> wrote:

> On Sat, Oct 17, 2009 at 11:40 AM, Michael Liddle <michael@...> wrote:
>> Mark Kretschmann wrote:
>>> However, some things are not stored immediately, partly for
>>> performance reasons, and partly because we forgot (detailed hints
>>> welcome).
>>
>> Major one's I've noticed:
>>
>> - Changes to widgets (added/removed/moved)
>> - Changes to the main window layout (i.e. the new dockable panels in 2.2)
>
> Ok, that's interesting. As these are rather new features, we probably
> forgot to sync to HDD. I assume we'll be able to fix this.

Could you maybe create a bug report for this on http://bugs.kde.org?
It would help us to keep track of this specific issue.

Thanks :)

--
Mark Kretschmann
Amarok Developer
www.kde.org - amarok.kde.org
_______________________________________________
Amarok mailing list
Amarok@...
https://mail.kde.org/mailman/listinfo/amarok

Mark Kretschmann wrote:
> Could you maybe create a bug report for this on http://bugs.kde.org?
> It would help us to keep track of this specific issue.

https://bugs.kde.org/show_bug.cgi?id=211509

Mike.
_______________________________________________
Amarok mailing list
Amarok@...
https://mail.kde.org/mailman/listinfo/amarok