Bug 76462

Summary:	wishlist: support for user-specified scripts on song-change event
Product:	[Applications] juk	Reporter:	Justin Mason <jm-kde>
Component:	general	Assignee:	Michael Pyne <mpyne>
Status:	RESOLVED WORKSFORME
Severity:	wishlist
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	Debian testing
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Justin Mason 2004-02-29 23:58:00 UTC

Version:            (using KDE KDE 3.2.0)
Installed from:    Debian testing/unstable Packages
OS:          Linux

Me again.   Another wishlist item, this time from xmms: support for song-change events.

Xmms has a nifty plugin called "song-change".  When a song is changed (e.g. start playing from Stop, or one track ends and the next one in the playlist starts), it will expand a user-specified command-line with a couple of %-escapes, and run it.

It's kind of cool for hooking all sorts of rubbish into the player, without causing too much overhead in the player code ;) .  By just expanding a command line and running it, that's a very small amount of overhead in code terms -- and works pretty well in terms of speed overhead, too, since a song-change event doesn't happen that frequently.

Security-wise, it'd probably be best to remove all newline, ' and " chars -- or instead just take a CGI-type approach and pass the metadata to the script in predefined environment variables like "$JUK_SONG_ARTIST" etc.


For example, my .xmms/config has:

enabled_gplugins=libsong_change.so

[song_change]
cmd_line=xmms-song-change.sh "%s"
cmd_line_end=

and that script does:

#!/bin/sh

if [ "$*" = "`cat ~/.xmms.cur`" ] ; then
  exit 0
fi

echo "$*" > ~/.xmms.cur
echo "$*" >> ~/.xmms.log
#echo "Song: $*" | set-osd

pretty simple -- logs all songs played into ~/.xmms.log and sets the on-screen-display (or at least it did before I turned that off). Then I have another shell script which takes ~/.xmms.log and generates a HTML snippet for inclusion on my weblog's front page, hacky hack ;)

Comment 1 Scott Wheeler 2004-03-01 02:20:06 UTC

Since I'm not convinced that something like this belongs in the main GUI I'll probably do something like add a DCOP signal.  If there doesn't happen to be something already that lets you link up DCOP signals to apps, well, that would be relatively easy to hack up.

I've been debating coming up with kind of a page to collect kind of advanced stuff with JuK and something like this would fit.  On the other hand I'm trying to keep most stuff like this out of the GUI since I think 99% of users either don't want it or would find it confusing.

Comment 2 Teemu Rytilahti 2004-03-01 18:01:55 UTC

I've modified my local JuK code to export the current song to the file for "now playing" use in IRC. I also think that this feature shouldn't be implemented directly to the JuK, but a plugin when it'll be possible..

Comment 3 Justin Mason 2004-03-01 18:52:14 UTC

fwiw, Teemu, you can do that now by running 'dcop juk Player nowPlayingString' (or similar, typing from memory).   That command will tell you what's currently playing.   But that's polling; a better approach would be for JuK to notify our apps on song-change, as mentioned.

Scott, I agree a DCOP signal sounds like it would be useful, if that's how DCOP handles one app being notified on an event in another app.  I don't really know enough DCOP to have suggested that myself ;)

Comment 4 Teemu Rytilahti 2004-03-02 01:09:36 UTC

Well, yes, I know I can get it that way but it doesn't seem to work from shell scripts.. And another issue is that I should find a way to update the file remotely, so that's why just writing it to the file is the easiest thing imho. Thanks for the comment anyways :)

Comment 5 Justin Mason 2004-08-26 04:15:38 UTC

actually -- you can get it from scripts.   I think the problem you might be seeing is an X authorisation (or KDE auth) one, where the script is running from somewhere it doesn't have your GUI environment (cron?).

I worked around this by dumping my environment into ~/.exports, and sourcing that from the script I run from cron.

But I agree -- it would be nicer to get Juk to run the script itself, instead of having to start an external script separately.

aside: a very useful thing for this script/signal to provide is the *path* of the currently playing song, and/or id3 metadata; see bug 80849.

Comment 6 Michael Pyne 2005-10-06 22:59:04 UTC

Reporter:

I forgot but a few months ago I added the DCOP signal that Scott was referring to.  It's called trackChanged(), part of JuK's Player interface.  The signal is emitted whenever the song changes (or playback stops).  You can retrieve info on the currently playing song after that using DCOP.

There is a JuK wiki page over at http://wiki.kde.org/tiki-index.php?page=juk where you can see the DCOP documentation.  There is also example code for Ruby's Korundum bindings linked there, which you can view directly from http://grammarian.homelinux.net/~kde-cvs/showPlaying-signals.rb .  The sample file will listen for the trackChanged() signal and update a window with the cover art and some metadata for the playing song.  You can probably dream up better things to do. :)

Is this sufficient to meet your request?  Otherwise it will probably need to wait for KDE 4.0.

Comment 7 Justin Mason 2005-10-06 23:31:50 UTC

sounds like it'll do the trick, alright.  Thanks for adding this!