Trigger an event from within a sequence

[Bos Lights]

I agree the stop should work as soon when triggered regardless if looping or not, out of curiousity I will have to run a test to learn if a none looping effect can be stopped from within a sequence file.

[CaptainMurdoch]

I think you are off on a rabbit trail.   How are you telling the effect to loop,  you can't do that through the UI or the event. The effect is only running once and stopping by itself.  I think the issue is still "why doesn't the stop work".

I was looking at your screen shot and video.  In both, you indicate that you are starting the effect directly from the event, you aren't running a script to start the effect looping.

[brichi]

I think you are off on a rabbit trail.   How are you telling the effect to loop,  you can't do that through the UI or the event. The effect is only running once and stopping by itself.  I think the issue is still "why doesn't the stop work".

I was looking at your screen shot and video.  In both, you indicate that you are starting the effect directly from the event, you aren't running a script to start the effect looping.

sorry, ive ran a ton of tests, in a few i use a script, its just not in that particular video.



#!/bin/sh
###########################################################
# StartEffectLooping - Start an effect in a loop          #
#                                                         #
# The effect will loop until stopped.                     #
###########################################################


# Edit this line to hold the effect name in quotes (WITHOUT the ".eseq" ending)
EFFECTNAME="TUNESHORT"


fpp -e "${EFFECTNAME},0,1"

[CaptainMurdoch]

I just tested and I can stop effects fine whether the effect is marked as looping or not and whether it has completed one loop or not.

Can you do the following?

- clear the fppd.log file
- set your log level to debug
- check the Effects, Events, and Sequence Log Mask checkboxes
- login to the FPP system either via ssh or at the console
- start the effect (non-looping) using "/opt/fpp/src/fpp -e YourEffectName"
- stop the effect using "/opt/fpp/src/fpp -E YourEffectName"
- start the effect looping using "/opt/fpp/src/fpp -e YourEffectName,0,1"
- stop the effect using "/opt/fpp/src/fpp -E YourEffectName"

If those work, then try to start/stop via the Effects page in the FPP UI.  If they don't work, check check the fppd.log for the log messages.  You should see entries like this:

2019-03-26 11:37:41 (6998) effects.cpp:128:Starting effect GarageSaleArrows at channel 0

2019-03-26 11:33:31 (6998) effects.cpp:223:StopEffect(GarageSaleArrows)

2019-03-26 11:37:44 (6998) effects.cpp:246:StopEffect(0)

The two different stops are from the command line stopping via effect name and the UI stopping via a running effect ID number.

If starting/stopping works via the UI, then try via the control channels again.  In testing, I was able to successfully start/stop effects on-demand using both the CLI and the UI, I did not have to wait until the effect looped through once before I could stop it.

[brichi]

will do once I get home later.


I know off the top of my head that I can manually stop the effect by going to the effects tab at any time and clicking on the running effect and click "stop effect"

[CaptainMurdoch]

will do once I get home later.


I know off the top of my head that I can manually stop the effect by going to the effects tab at any time and clicking on the running effect and click "stop effect"

OK, thanks.  One other thing, either before or after the remote test, test by manually triggering the event from the FPP UI.  I'm trying to determine where the disconnect is if things aren't working properly via the control channels.

[brichi]

will do once I get home later.


I know off the top of my head that I can manually stop the effect by going to the effects tab at any time and clicking on the running effect and click "stop effect"

OK, thanks.  One other thing, either before or after the remote test, test by manually triggering the event from the FPP UI.  I'm trying to determine where the disconnect is if things aren't working properly via the control channels.

I can successfully go into status/control>events,,, click on the 1/1 evetn and click trigger and it will start the event, clicking 1/2 event and triggering it stops the event. the disconnect seems to be when doing this from xlights.

[CaptainMurdoch]

I can successfully go into status/control>events,,, click on the 1/1 evetn and click trigger and it will start the event, clicking 1/2 event and triggering it stops the event. the disconnect seems to be when doing this from xlights.

That is where it isn't making sense because xLights doesn't have any idea what the values in those control channels do, it just set the values and FPP interprets them.  If the 1/1 'on' event triggers properly, then the 1/2 'off' event should trigger as well.

[brichi]

I just tested and I can stop effects fine whether the effect is marked as looping or not and whether it has completed one loop or not.

Can you do the following?

- clear the fppd.log file
- set your log level to debug
- check the Effects, Events, and Sequence Log Mask checkboxes
- login to the FPP system either via ssh or at the console
- start the effect (non-looping) using "/opt/fpp/src/fpp -e YourEffectName"
- stop the effect using "/opt/fpp/src/fpp -E YourEffectName"
- start the effect looping using "/opt/fpp/src/fpp -e YourEffectName,0,1"
- stop the effect using "/opt/fpp/src/fpp -E YourEffectName"

If those work, then try to start/stop via the Effects page in the FPP UI.  If they don't work, check check the fppd.log for the log messages.  You should see entries like this:

2019-03-26 11:37:41 (6998) effects.cpp:128:Starting effect GarageSaleArrows at channel 0

2019-03-26 11:33:31 (6998) effects.cpp:223:StopEffect(GarageSaleArrows)

2019-03-26 11:37:44 (6998) effects.cpp:246:StopEffect(0)

The two different stops are from the command line stopping via effect name and the UI stopping via a running effect ID number.

If starting/stopping works via the UI, then try via the control channels again.  In testing, I was able to successfully start/stop effects on-demand using both the CLI and the UI, I did not have to wait until the effect looped through once before I could stop it.

All of these tests worked successfully, each command line triggered the effect as it should and turned it off as it should. The thing i notice too is even if i start a short 30 second effect not looping, it never clears from the running effects window till i manually stop it. Im not sure what ts doing on the matrix being i dont have my actual screen hooked up, its packed away


i attached the fppd.log after clearing, setting the debug options, testing and saving


If its easier for you I can jump in ZOOM later on and you can see and mess with my setup

[Bos Lights]

Brichi just curious if you have any updates

[CaptainMurdoch]

It looks like the OverlayEffect() function in effects.cpp is not handling closing the effect when the effect completes.  It has the following code:

    FSEQFile::FrameData *d = e->fp->getFrame(e->currentFrame);
    if (d == nullptr && e->loop) {
        e->currentFrame = 0;
        d = e->fp->getFrame(e->currentFrame);
    }
    e->currentFrame++;
    if (d) {
        d->readFrame((uint8_t*)channelData);
        delete d;
        return 1;
    }

the first part handles looping the effect when we hit the end, but I think there should be an 'else' on the "if (d)" statement to handle closing the effect when we're not looping or if looping failed to get a frame.

I think we can add a call to StopEffectHelper() in an else there to clean up the non-looping effect.   I'll make and test a patch for that and post back once tested.

[Bos Lights]

Thanks for the update

[brichi]

awesome, thanks for the update.. ill give it a shot once posted.

[brichi]

It looks like the OverlayEffect() function in effects.cpp is not handling closing the effect when the effect completes.  It has the following code:

    FSEQFile::FrameData *d = e->fp->getFrame(e->currentFrame);
    if (d == nullptr && e->loop) {
        e->currentFrame = 0;
        d = e->fp->getFrame(e->currentFrame);
    }
    e->currentFrame++;
    if (d) {
        d->readFrame((uint8_t*)channelData);
        delete d;
        return 1;
    }

the first part handles looping the effect when we hit the end, but I think there should be an 'else' on the "if (d)" statement to handle closing the effect when we're not looping or if looping failed to get a frame.

I think we can add a call to StopEffectHelper() in an else there to clean up the non-looping effect.   I'll make and test a patch for that and post back once tested.

Not sure if you're completely done with this fix but I see this was added to the latest FPP update """Clean up non-looping effect when it finishes"""


I tested it and the effect starts and stops when its triggered to start but on the stopping end 2 things are still happening

1. You still cannot stop the event from Xlights until the effect has completed at least once
2. If I use the script to "start effect looping" then you can't stop it at all from Xlights even after 1 full play like we used to be able to do

[CaptainMurdoch]

I tested it and the effect starts and stops when its triggered to start but on the stopping end 2 things are still happening

1. You still cannot stop the event from Xlights until the effect has completed at least once
2. If I use the script to "start effect looping" then you can't stop it at all from Xlights even after 1 full play like we used to be able to do

When you say 'from xLights' are you talking about using E1.31 data sent to FPP or is this via xSchedule?  When you try to stop the effect from xLights, what shows up in the fppd.log file?