- fixed typo in cartwall config (thanks, Cad)
- fixed start menu links and uninstaller
Hi Torben,
On this build (and 271), when in AUTO - The NEXT item always plays from PlayerA, even if B or C are shown as “next”. I couldn’t see any new config option, so this one took me by surprise! I can understand that AUTO defaults to PlayerA “from cold” ie: as the first item to play, but I’d expect an ABCABCABC order thereafter…
Is this a bug or a new feature ?!
Sorry, I don’t get the point. The item marked “next” is the top-most, loaded, non-playing item. And this is exactly the same item the automation will play next (although it doesn’t consider the next flag, but it follows the same strategy when picking the item to be played).
Can you please clarify this?
Torben
What I meant was, when playing from Player B - The next item was loaded in Player C, but upon pressing “next”, it plays from Player A.
In which order did the items appear in the playlist?
By the way, I found the following inconsistency between the automation and the NEXT flag: If the top-most player happens to be paused when automation is engaged, it will not be flagged as NEXT, but the automation will play the item anyway. I therefore decided, for consistency, that also paused players should be candidates for the NEXT flag. However, the NEXT flag will only be shown in the playlist “A (NEXT)”, the player will still display PAUSE to indicate its paused state.
Same on 274, although the About box still says 273…
Item playing in Player B…
I press NEXT and it appears in Player A, despite Player C being “next” in the queue…
Hm, looks like - for some reason - the players switch items. Do you have a Fade Out time defined for Bonnie Tyler, or is it played until the very end?
Yes - the Fade Out / Segue Point is set. Any of my playlist items with an end-type set have been through the Ramp/Fade procedure. Although, in my example, I pressed next early just to show what happens.
I tried it myself - I cannot reproduce it 
There must be some special conditions that lead to this strange behavior.
You mentioned that you noticed this in build 271 - can you reproduce the issue it with earlier versions of the 1.5 release? Maybe we can identify the version in which it started.
However - if I get you right, the playlist is worked in the right order, it’s only that the player assignment unexpectedly changes, right? If so, it’s not a mission critical bug I suppose. I’m confident that we will manage to identify the cause, but let’s give it a lower priority than the other issues that remain.
Torben
No - It’s not in the 1.5.x releases - Just the beta 271 onwards. It’s just quite un-expected, to have Player C faded up and then for it to play out of A.
EDIT: Found it… It’s partly my found - My NEXT button on the keyboard actually carries out 3 commands (!) AUTOMATION 1 ON;AUTOMATION 1 NEXT;AUTOMATION 1 PLAY - this is because it functions as a single Go/Next button. So what happens is when I press it, it “resets” the automation order - The same happens if I click AUTO with the mouse on the playlist bar.
Ah, ok … now I see what’s the problem - although I don’t quite understand why it is happening in build 271 but not in the 1.5.55 release, because the this particular source code file hasn’t changed since then.
Anyway, you are right: Enabling/disabling the automation unloads any idle player, and then loads all (then empty) players again with the top-most items. This is to make sure that the playlist is worked from the beginning, even if you had manually loaded a “later” item into one of the players while in ASSIST mode.
I will modify the playback control so that this does NOT happen if automation is already engaged when you issue the AUTOMATION 1 ON command. In other words, AUTOMATION 1 ON will simply be ignored if already in automation mode.
Expect a new build within a few minutes.
Torben
PS: Since a while ago, AUTOMATION NEXT will implictly issue a PLAY if the automation is not playing by then. So you can shorten your action to “AUTOMATION 1 ON;AUTOMATION 1 NEXT”.