PDA

View Full Version : Execute Script Plugin Question



jonheal
2006-03-27, 04:00
This question is probably for Kevin, but maybe someone else can answer it.

I've got a .vbs script that I would like executed On Play and On Stop, and I cannot get it to do so. I can execute it manually with the remote by clicking on the Play button while listing the scripts, but it refuses to execute on the events.

I have a couple of other .vbs scripts that are working fine with the Power events, so Execute Script is running properly, in general. Any ideas?

SlimServer Version: 6.2.2 - 6337 - Windows 2000 - EN - cp1252

kdf
2006-03-27, 10:12
On 27-Mar-06, at 3:00 AM, jonheal wrote:
>
> I have a couple of other .vbs scripts that are working fine with the
> Power events, so Execute Script is running properly, in general. Any
> ideas?
>
I think we've done this before have we not?

check the version in Execute.pm, and also run using d_plugins.
if the debug says it is running the given script, then the next line of
code makes the system call
after that, there is little that I can do, as the problem lies with the
system (or somehow, Perl).

I would have expected it to be an all or nothing, so this is a very odd
condition. If you are running the debug and do NOT see the play event
detected, for example, then I do know where to look.

thanks,
kdf

jonheal
2006-03-27, 10:33
On 27-Mar-06, at 3:00 AM, jonheal wrote:
>
> I have a couple of other .vbs scripts that are working fine with the
> Power events, so Execute Script is running properly, in general. Any
> ideas?
>
I think we've done this before have we not?

check the version in Execute.pm, and also run using d_plugins.
if the debug says it is running the given script, then the next line of
code makes the system call
after that, there is little that I can do, as the problem lies with the
system (or somehow, Perl).

I would have expected it to be an all or nothing, so this is a very odd
condition. If you are running the debug and do NOT see the play event
detected, for example, then I do know where to look.

thanks,
kdf
Sorry, Kevin, I forgot about checking the debug flags. I'll do that when I get home and report back.

jonheal
2006-03-28, 03:29
Kevin,

I checked the d_plugins and d_files debug flags. I associated my new script with the Open, Play and Stop events. It appears that the Play event is not being trapped. I don't see the brief animation on the Squeezebox and it is not reflected in the log, which I've attached below. I tried both the version of your script that I modified to add the Power Off event and a fresh copy that I downloaded from your web site.

SlimServer is running on a Windows 2000 box, but I'm pretty sure that the behavior is the same in XP, as I've been switching back and forth between two machines, and the Play event wasn't executing the script on either.

Also, script Activation is not persisting between system restarts.

I've also attached the modified Execute.pm script.

SlimServer Version: 6.2.2 - 6337 - Windows 2000 - EN - cp1252

kdf
2006-03-28, 10:43
Quoting jonheal <jonheal.25dkvz1143541801 (AT) no-mx (DOT) forums.slimdevices.com>:

>
> I tried both the version of your script that I modified to add
> the Power Off event and a fresh copy that I downloaded from your web
> site.

which version of the server are you using again?

> Also, script Activation is not persisting between system restarts.

good. that's the way it is designed. However, I can probably drop
that and just go with the enabled/disabled state in server
settings->plugins now.

Log seems to be the wrong one. That looks like a d_files log, and I
can't see much else. I'll have a look at your patched version if you
still feel like attaching it. I'm not seeing it in this one. Perhaps
send it to me offline slim-mail *at* deane-freeman (dot) com
-k

jonheal
2006-03-28, 12:51
Quoting jonheal <jonheal.25dkvz1143541801 (AT) no-mx (DOT) forums.slimdevices.com>:

>
> I tried both the version of your script that I modified to add
> the Power Off event and a fresh copy that I downloaded from your web
> site.

which version of the server are you using again?

> Also, script Activation is not persisting between system restarts.

good. that's the way it is designed. However, I can probably drop
that and just go with the enabled/disabled state in server
settings->plugins now.

Log seems to be the wrong one. That looks like a d_files log, and I
can't see much else. I'll have a look at your patched version if you
still feel like attaching it. I'm not seeing it in this one. Perhaps
send it to me offline slim-mail *at* deane-freeman (dot) com
-k
I had turned on both d_plugin and f_files turned on, but I'll send you another log tonight with just d_plugin messages listed. Also, although I am far from a perl expert, I see in your script where you check the value of $slimCommand for the state of the player. I thought I would add this line to the commandCallback sub after the variables are set:

$::d_plugins && msg($slimCommand);

Then I can see if "play" is being returned at all.

kdf
2006-03-28, 14:07
Quoting jonheal <jonheal.25eb1q1143575706 (AT) no-mx (DOT) forums.slimdevices.com>:

> Then I can see if "play" is being returned at all.

Looks like it isn't in all cases. Using the web, if you hit the play
button then the "play" command is issued. If you hit the play button
on the remote, or in my case sofsqueeze virtual remote, then the
"button, play" command is issued. In the latter case, the callback
never gets to the Execute plugin, nor any other plugin that has
subscribed to the play command.

log attached...and this looks like it affects Trackstat as well.
-k

kdf
2006-03-28, 21:51
I've posted a new version (1.13) that should hopefully fix the problems.
-k

jonheal
2006-03-29, 03:34
I've posted a new version (1.13) that should hopefully fix the problems.
-k
Rats, I'm still using 6.2.2.

jonheal
2006-03-29, 05:39
I've posted a new version (1.13) that should hopefully fix the problems.
-k
Kevin,

I replaced "play" with "newsong" in this block:

elsif ($slimCommand eq "newsong") {
$::d_plugins && msg("Execute: Play Started: ");
$runScript = Slim::Utils::Prefs::clientGet($client, 'script'.1);
if ((!defined($runScript)) || ($runScript eq '')) {
$runScript = Slim::Utils::Prefs::get('plugin-Execute-play');
}
if (defined($runScript) && ($runScript ne "(none)")) {
$runScript = catfile($scriptPath,$runScript);
$::d_plugins && msg("Execute: Executing: ".Slim::Music::Info::standardTitle($client, $runScript)."\n");
Slim::Display::Animation::showBriefly($client,stri ng('PLUGIN_EXECUTE_GO'),$runScript);
system $runScript;
} else {
$::d_plugins && msg("Execute: No Script Selected \n");
}
}

I think the version 1.7 script is now working in 6.2.2.

kdf
2006-03-29, 09:24
On 29-Mar-06, at 2:34 AM, jonheal wrote:

>
> kdf Wrote:
>> I've posted a new version (1.13) that should hopefully fix the
>> problems.
>> -k
> Rats, I'm still using 6.2.2.
>
well, I had asked...
and really it was the 6.5 version that had the problem, but I can try
to take a look at the older one.

kdf
2006-03-29, 09:40
On 29-Mar-06, at 4:39 AM, jonheal wrote:

>
> kdf Wrote:
>> I've posted a new version (1.13) that should hopefully fix the
>> problems.
>> -k
> Kevin,
>
> I replaced "play" with "newsong" in this block:
>
newsong isn't always accurate. It can depend on the file format. I
suspect the problem is the same as with 1.12. I'll need to add a
watcher for "button play".
-k

jonheal
2006-03-29, 10:55
On 29-Mar-06, at 2:34 AM, jonheal wrote:

>
> kdf Wrote:
>> I've posted a new version (1.13) that should hopefully fix the
>> problems.
>> -k
> Rats, I'm still using 6.2.2.
>
well, I had asked...
and really it was the 6.5 version that had the problem, but I can try
to take a look at the older one.
Kevin,

I added a line to print all values of $slimCommand to the debug log ($::d_plugins && msg("$slimCommand Value: ".$slimCommand); -- within the commandCallback sub). Neither "button, play" nor "button play" appeared in the log.

However, if I changed this line:

elsif ($slimCommand eq "play")

to this:

elsif ($slimCommand eq "play" || "button, play")

the script fired when I clicked ANY button on the remote.

These changes were made to the version of the script I downloaded from your web site, not my basterdized version.

kdf
2006-03-29, 11:49
Quoting jonheal <jonheal.25g0dz1143655202 (AT) no-mx (DOT) forums.slimdevices.com>:

>
> I added a line to print all values of the $slimCommand to the debug log
> (within the commandCallback sub). Neither "button, play" nor "button
> play" appeared in the log.
>
> However, if I changed this line:
>
> elsif ($slimCommand eq "play")
>
> to this:
>
> elsif ($slimCommand eq "play" || "button, play")

that will always be TRUE, since "button, play" is a value and not a
conditional.
it doesn't phrase like spoken language, you have to do the logic each time:
elsif ($slimCommand eq "play" || $climCommand eq "button, play")

However, that isn't what you need to find anyway.
what you want to look for is:

elsif ($slimCommand eq "play || ($slimCommand eq "button" && $paramOne
eq "play"))

and that will only work when there is actually a play event. However,
as it turns out, there isn't always such a thing. if you load a
playlist, it will start playing as part of the load and there is no
play event. However, that's how slimserver works and I really don't
have to motivation to go on a mission to change that. Execute will
still do what is says...run a script on a play event.

Depending on what your script is doing, you may want to stick with
checking for "newsong" or some other event. "newsong" will at least
be a good one if you want to update a blog entry with the new song
infomation, for example.

using the 6.2.2 version, the debug needs to be --d_stdio to get the
command watcher output. in 6.5 versions, I changed to the more
standard d_plugins. The point of that was to provide the tools for
people, such as yourself, to easily change the events to be whatever
they want. Simply match the $slimCommand, $paramOne or any other
params at will and you can hijack any of the four events to be
whatever suits your needs.

as another note, copy line 159 (the setExecuteCallback) to just above
the last } in the initPlugin function (two lines above "sub lines") to
make the plugin activate on startup instead of having to activate
manually each time.
-k

jonheal
2006-03-29, 12:02
Quoting jonheal <jonheal.25g0dz1143655202 (AT) no-mx (DOT) forums.slimdevices.com>:

>
> I added a line to print all values of the $slimCommand to the debug log
> (within the commandCallback sub). Neither "button, play" nor "button
> play" appeared in the log.
>
> However, if I changed this line:
>
> elsif ($slimCommand eq "play")
>
> to this:
>
> elsif ($slimCommand eq "play" || "button, play")

that will always be TRUE, since "button, play" is a value and not a
conditional.
it doesn't phrase like spoken language, you have to do the logic each time:
elsif ($slimCommand eq "play" || $climCommand eq "button, play")

However, that isn't what you need to find anyway.
what you want to look for is:

elsif ($slimCommand eq "play || ($slimCommand eq "button" && $paramOne
eq "play"))

and that will only work when there is actually a play event. However,
as it turns out, there isn't always such a thing. if you load a
playlist, it will start playing as part of the load and there is no
play event. However, that's how slimserver works and I really don't
have to motivation to go on a mission to change that. Execute will
still do what is says...run a script on a play event.

Depending on what your script is doing, you may want to stick with
checking for "newsong" or some other event. "newsong" will at least
be a good one if you want to update a blog entry with the new song
infomation, for example.

using the 6.2.2 version, the debug needs to be --d_stdio to get the
command watcher output. in 6.5 versions, I changed to the more
standard d_plugins. The point of that was to provide the tools for
people, such as yourself, to easily change the events to be whatever
they want. Simply match the $slimCommand, $paramOne or any other
params at will and you can hijack any of the four events to be
whatever suits your needs.

as another note, copy line 159 (the setExecuteCallback) to just above
the last } in the initPlugin function (two lines above "sub lines") to
make the plugin activate on startup instead of having to activate
manually each time.
-k
Kevin,

Thanks for your help with all of this. I will watch the d_stdio log for grins, but for now, I'll probably stick with trapping for "newsong" since what you described is exactly what I'm trying to do -- update a web page with "now playing" info. 95% of my collection is FLAC, and it seems to work with those files. The rest are mp3s. I haven't tried it with those, so I don't know if "newsong" is issued when an mp3 is played or not, but frankly, after listening to FLACs, I can't stand listening to the mp3s any more anyway.

I'll put in the change you outlined to keep the script activated.

Thanks again. Sorry if I've been a pain in the a$$.

jonheal
2006-03-30, 08:49
Kevin,

Everything is working fine, so far. I have one final issue that I wonder if you would mind helping me with. I would like to listen for the player/Slimserver stopping. If I issue a command (with a button press) that stops playback, then Execute.pm traps for the event. If however, I simply let the song/playlist play through and end, no stop message is generated.

Can you point me in the direction I should look to figure out how to do this? I've been looking through the various scripts, and I'm wondering if there's something in CLI.pm? I'm kind of in the dark here -- especially with my limited perl skills.

Ultimately, I'm hoping to add some code to my bastardized Execute.pm script to listen for the "stopped state."

Thanks in advance.

kdf
2006-03-30, 10:10
On 30-Mar-06, at 7:49 AM, jonheal wrote:
>
> Can you point me in the direction I should look to figure out how to do
> this?
I'll have to think about this one. Nothing springs to mind, and I work
mostly with 6.5 and developer branches, so I've got the new cli in my
head.
-k

jonheal
2006-03-30, 10:36
On 30-Mar-06, at 7:49 AM, jonheal wrote:
>
> Can you point me in the direction I should look to figure out how to do
> this?
I'll have to think about this one. Nothing springs to mind, and I work
mostly with 6.5 and developer branches, so I've got the new cli in my
head.
-k
I'm figuring that there must be something that generates the stopped message because the word "STOP" in the web UI player frame highlights when a playlist (and I guess anything and everything you play is technically a playlist) ends. Something must be forcing that frame to reload. But maybe that message is coming from the firmware.

jonheal
2006-03-30, 11:54
In the version of the script for 6.2.x, this appears in the callback sub

if (($debug == 1) && $::d_stdio) {
print "----------------------------\n";
print "| COMMAND: $slimCommand\n";
foreach my $i (@$paramsRef[1..scalar(@$paramsRef)-1]) {
print "| PARAMS: $i\n";
}
print "----------------------------\n";
}

Where does this actually "print?" I checked d_stdio on the dubug screen, but it didn't generate any extra output during playback in the log.

kdf
2006-03-30, 13:10
Quoting jonheal <jonheal.25hu4p1143740405 (AT) no-mx (DOT) forums.slimdevices.com>:

> I'm figuring that there must be something that generates the stopped
> message because the word "STOP" in the web UI player frame highlights
> when a playlist (and I guess anything and everything you play is
> technically a playlist) ends. Something must be forcing that frame to
> reload. But maybe that message is coming from the firmware.

that's different. the server reports the playmode state. It is the
event that gets you to that state that is required for the plugin


> Where does this actually "print?" I checked d_stdio on the dubug
> screen, but it didn't generate any extra output during playback in the
> log.
>
the print goes to the console. run the server command-line for debug.
I haven't bothered to change it to use the server message facility
becuase it is really just too chatty for recording in the file.
However, you can just change 'print' to 'Slim::Utils::Misc::msg' and
it should then send to the log
-k