Sean Meighan
Software => Bugs in xLights/Nutcracker => Topic started by: futuretechguy on January 21, 2018, 11:26:18 AM
-
Hi Guys,
I am not sure if this in a bug but whenever I trigger a xSchedule "Back" ("Prior step in the current playlist") button function, the xSchedule stops playing the current step, if the current position is the first (top) step in the playlist. This occurs regardless of the method of trigger (manually in xSchedule or from a remote script). Is there a simple fix or workaround that does not involve more coding on my end?
This was interrupting my show last Christmas when my audience were using the buttons during the first step.
(http://futuretechoptions.com/Support/images/xSchedulerPlaying.png)
(http://futuretechoptions.com/Support/images/ESP8266ButtonPress.png)
-
To be sure I have this right ... if you try to jump to prior step it is stopping the playlist.
My options seem to be. Restart the first step or jump to the last step but only if the playlist is being looped. Would that make sense.
-
Correct, however I think it should jump to the last (since that was logically the previous step) but only if the status is playing (as it does when not at the first or the last step). It also stops playing if "Next" is executed while the last step is being played; in this case I think it should go the first step.
-
I can agree but only if it is set to be looping. If not looping then next is correct to stop if on the last step.
-
Okay, that makes sense.
-
I would expect Next to be disabled if on the last song and not looping.
-
Perhaps, but remaining enabled creates options, providing the ability to manually keep going (a step a time) if desired. The scenario is that playing stops, but if the "Next" button is executed the next logical step in the last (played) playlist is executed. I am mostly focused on my audience after my show ends, if they hit the button the next of previous step(not the entire playlist) runs only once and stops.
-
I'm not talking about your side I mean the xLights side. If you are on the last song in a sequence with no looping set then I would expect a next command to do nothing instead of halt the sequence.
-
Yes, since it was designed to stop after the last step when looping is not enabled, then any button(s) using "Next step in current playlist" should be disabled. The same also for buttons(s) using the "Prior step in the current playlist" when the position is at the top or first step.
-
I don’t agree. Next on the last step will end the playlist. Prior on the first step will restart the first step.
-
I can see it now. Some kid will run up and hit the Next button and then the whole show stops and all the kids start crying....lol.
-
But the show would have stopped at the end of the song anyway. If it is set to loop then all would be ok.
-
Luckily I don't need to come here to get code changes.
-
#ifdef GIL
-
Ok I'll stop trolling....I don't care what the button does... :)
-
You are correct, I tested it again with the 64 bit version and the "Back" button does correctly move to the last step if the current position is the first step when pressed, so I stand corrected.
However the "Next" button does stop the playlist if pressed while current position is last step, even with looping enabled.
Okay, if this is by design then so be it.
-
I have tested this ... it works as expected. To get the behaviour I think you expect you have to have the playlist looping.