which kill signal to get regular termination (that equals shift+Q inside the program)

Submitted by kotzenhuber on Wed, 2013-02-20 16:50

Forums:

Hi, im using 2.5.0-alpha4 on debian/aptosid.

Sometimes I like to kill mocp with a certain delay, so I use sleep && killall mocp.
When I use the killall method, mocp seems to terminate in an other way than when I press "Shift+Q" from inside the terminal. This means my current playlist won't be cached. Shame.
I tried to send different termination signals via killall -s[3,6,15] mocp.
Signal 3 (SIGQUIT) seems to work in some cases, but i can't figure out when and how - sometimes it just leaves a zombie moc.
Maybe there would be another way to kill mocp without having to figure out the PID of the mother process in the first place?

tomaszg

Wed, 2013-02-20 17:34

Simple solution - just use mocp -x :)

kotzenhuber

Wed, 2013-02-20 18:18

Good thing, because I've never thought of that :-)

Unfortunately, the initial problem, that my playlist isn't cached, still remains. I faintly remember that I've probably set this option (save playlist on exit) in the .moc/config or somewhere like that. Maybe this is only used when exiting with shft+Q?

(still, I'll use mocp -x instead of killall :-) )

kotzenhuber

Mon, 2013-03-04 19:05

Sorry to push this... no one any clue still? ;-)
Meanwhile I explicitly set the SavePlaylist option in my config file, but to no avail... neither killall nor mocp -x will keep the current playlist and start there on the next invocation... whereas when I exit by pressing shift+q all the playlist tags are read and mocp will start right where I left... Any ideas?

jcf

Mon, 2013-03-04 19:43

"Meanwhile I explicitly set the SavePlaylist option in my config file, but to no avail..."

Okay, you hadn't told us that so it was assumed that you'd done it and it had fixed the problem, hence no further response.

... "neither killall nor mocp -x will keep the current playlist" ...

killall definitely won't. It's a system command which will cause it to terminate MOC (as opposed to asking MOC terminating itself).

mocp -x should save the playlist if SavePlaylist is set (or defaulted) to 'yes'. mocp -x and 'Q' send the same command to the MOC server and so should result in the same actions -- there must be something else in play.

I'll take another look and try to reproduce the problem.

kotzenhuber

Mon, 2013-03-04 19:54

Hi and thanks.
No, mocp -x definitively does not save the playlist on exiting here. Tried several times. q and Q do. Any helpful information i can supply?
Cheers :)

jcf

Mon, 2013-03-04 20:18

I'll have to trace through the code again. I had thought that the saving of the playlist was done by the server, but when you say it's also saved by 'q' it implies it's actually saved by the client. That would explain your problem, but does raise a couple of other issues.

jcf

Mon, 2013-03-04 21:53

Yes, the playlist is saved and loaded by the client and then only when run as an interface and not when using only command line options. (I realised when investigating this that I'd actually been thinking "tags cache" because that is what I'd more recently been working on.)

But the playlist should have been saved when you last quit the interface client and loaded last time you started the MOC server via that client, as modified by the SyncPlaylist option. However, if you are always starting and stopping MOC via the command line options then the playlist won't be loaded or saved.

There is no immediate solution to this.

kotzenhuber

Tue, 2013-03-05 18:23

Hi, thanks for your efforts :-). You think it would be possible to do s.th. like send a keystroke to the client in the like of echo "Q" > /proc/pid/fd/n?

jcf

Tue, 2013-03-05 19:15

I hadn't thought of that, but give it a try and let us know.

I thought maybe mocp -x with another interface client running might cause it to save the playlist when the server exit causes it to exit, but it doesn't. However, it might be made to do so.

I don't use playlists myself (too busy hacking on the code to actually use MOC much for my own pleasure), so I don't have any use cases for them in my head. In the next release (or maybe the one after if I decide to split it) you will be able to define a keypress to load and save the playlists and I do hope to introduce multiple and dynamic playlists in the future, but I'd like to see a discussion on when MOC should save the playlist (bearing in mind that there may be multiple clients in use) and when it shouldn't. Maybe you could start a new thread on that topic for me.