Sometimes when invoking a track skip, or a number of other user-initiated changes to what is playing, one sees (1) "<new track title> / Now Playing" on the controller (for example) and a little later this is updated with (2) "<new track title> / <new artist> - <new album>".

Occasionally. the display briefly gets reverted to "<old track title> / <old artist> - <old album>" between (1) and (2).  This looks rather odd.

After some investigation this seem to be because (1) is initiated by a displayStatus/showBriefly which may timeout before the playerstatus for (2) arrives. This is especially noticeable with TinySC. Lack of timely update (but without the flip-flop behaviour) also is a feature when dealing with remote tracks.

I looked at statusQuery_filter. I note that it does not send a playerstatus for 'playlist open', nor for 'playlist jump' and this means that the playerstatus will not happen until the 'playlist newsong' when the new song actually starts playing. I think that this is probably the right thing to do, as otherwise the server gets hit hard generating multiple playerstatus updates.

One solution might be to allow 'playlist open' and 'playlist jump' to trigger a playerstatus but with a longer delay that usual - say 1s. This would usually be overtaken by the playerstatus triggered from the 'playlist newsong' and therefore only one playerstatus would be generated. This would be particularly for remote services such as Rhapsody. I think that this ought to be combined with a longer timeout on the display of the showBriefly from the displayStatus.

I have tested this somewhat, without a change to the showBriefly timeout and it looks good.