Our playlist contains fixed-time programs as well as “normal” timed music.
When a program should be played in Assist mode, we’ve made the program load itself, and the colour changes every 500mS, using Item.SetColor(). This works as expected.
There’s a player waveform display as well, with mouse navigation and seek enabled. If the program item isn’t current (colour not flashing) the mouse seek works as expected. But if the colour is flashing, every colour change seems to reset the position back to the start, and the waveform alters as well.
As an experiment I removed the colour change and instead made the item title change every 500mS. That had the same effect of resetting the position to the start…
It almost seems the player is being re-loaded whenever the playlist item colour or title is altered. Is there any way to avoid that behaviour?
I have been able to reproduce the behavior, and in fact, any change to the properties of the item will reset the player, given that it is in “Loaded” state. This will also rewind it back to the Cue In marker (or beginning of the item, if no Cue In was configured). I’m not sure if I can change this behavior without breaking anything, because I’m pretty sure I did it for a reason (there are some property changes that do require a full reset).
Why are you using the waveform seek anyway? Wouldn’t it be better to set a Cue In instead? This can also be done with the mouse by dragging from the left-hand edge of the waveform.
I’d suspected there was some solid design reason behind the reset of the loaded player.
We have several hundred volunteers of widely varying skill levels, so our mAirlIst design tends to be as simple as possible. Just engaging the PlayList Cue (PFL) button (playing through an off-line speaker) and using the mouse seek is elegant and intuitive. We wanted to keep it.
So - we’ve left the colour flashing behind, and will be probably flashing the text on our custom Play button instead. That will do the job.