HouseBot

When I create a task with an execution list of CDJ prop changes (no conditions), the task remains in a "running" state even after changing all the props.



However, if I tack on a delay at the end of the execution list the task

DOES seem to complete ok (was using a 5000 millisecond delay)



The task state not going to "waiting", or whatever the state is for being completed, seems to lead to CDJ going into a state where it will not complete subsequent attempts to change properties (although the only properties I'm trying to change are the CDJ props)

Tom,



I gave this a quick try and was not able to reproduce what you are seeing. Can you give me an outline of the task that details which properties are changing and to what values?



Thanks,

Scott

I'll provide more specifics after I take a harder look at the problem



I'm having another issue where the properties that show the CDJ feedback from current item playing in playlist doesn't always show up - so here's a question:



If I use playlist_getitem[], response from which fills in various feedback props like "CDJ Album", will that somehow prevent "CDJ Album" and other props from getting set properly by later feedback that comes back about the currently playing item after I do playlist_play?



I'll be looking for more detail on the nature of these issues if you just want to wait for that first...

ScottBot wrote:Tom,

I gave this a quick try and was not able to reproduce what you are seeing. Can you give me an outline of the task that details which properties are changing and to what values?

Thanks,
Scott

tnelson wrote:If I use playlist_getitem[], response from which fills in various feedback props like "CDJ Album", will that somehow prevent "CDJ Album" and other props from getting set properly by later feedback that comes back about the currently playing item after I do playlist_play?

Tom,



Any of the Properties that share the same responses (searchlist_item[], playlist_item[], playing[]) run the risk of being overwritten when another response is received.



I was figuring that if the user specifically asked for the data with the searchlist_item or playlist_item calls, they would process and act on it immediately (of course this does screw up the currently playing values).



The alternative is to have separate Properties for the searchlist and/or playlist queries. It starts to get a little messy with so many similar sounding Properties, but if you think it is better that way, I can change it.



Let me know. Since I don't actually use it, you are in a much better position to judge the alternatives.



Scott

Scott,



I think the design is good - I think its completely reasonable and usable to share the properties in this way. I'm just seeing a situation where the values seem to get "stuck" and don't change as I would expect them to in response to the changing state of the playlist as its playing.

I think I'm wasting your time though until I can identify a scenario I think you can reproduce so - hold that thought, 'till I get back to you :-)



-Tom

ScottBot wrote:

tnelson wrote:If I use playlist_getitem[], response from which fills in various feedback props like "CDJ Album", will that somehow prevent "CDJ Album" and other props from getting set properly by later feedback that comes back about the currently playing item after I do playlist_play?

Tom,

Any of the Properties that share the same responses (searchlist_item[], playlist_item[], playing[]) run the risk of being overwritten when another response is received.

I was figuring that if the user specifically asked for the data with the searchlist_item or playlist_item calls, they would process and act on it immediately (of course this does screw up the currently playing values).

The alternative is to have separate Properties for the searchlist and/or playlist queries. It starts to get a little messy with so many similar sounding Properties, but if you think it is better that way, I can change it.

Let me know. Since I don't actually use it, you are in a much better position to judge the alternatives.

Scott