can you provide d_plugins log output.  it should show a note from Randomplay at every song transition, adding tracks or an indication of when/why it may stop adding.

(In reply to comment #1)
> can you provide d_plugins log output.  it should show a note from Randomplay at
> every song transition, adding tracks or an indication of when/why it may stop
> adding.
> 

Well, I've just done a complete re-install of the 6th Jan nightly and a new option has magically appeared on the Random Mix settings page ("Add new items when old ones finish") which was, of course, unchecked. Checking it fixes the "bug".

You can put this bug down to user error.

thanks for letting us know :)
cheers.

This is occurring again, likely due to some callback changes.  Jan 30 nightly.  Log section:

2006-01-30 13:07:38.1162 RandomPlay: Play track
2006-01-30 13:07:38.1485 RandomPlay: playRandom called with type track
2006-01-30 13:07:38.3205 RandomPlay: -1 songs remaining, songIndex = 0
2006-01-30 13:07:38.5438 RandomPlay: Starting random selection of 10 items for type: track
2006-01-30 13:07:39.0308 RandomPlay: Find returned 10 items
2006-01-30 13:07:39.0751 RandomPlay: Playing track: side2.mp3, 502
2006-01-30 13:07:40.2938 Adding 9 tracks to end of playlist
2006-01-30 13:07:40.4294 RandomPlay: Playing continuous track mode with 10 items
2006-01-30 13:07:41.1688 RandomPlay: received command playlist loadtracks
2006-01-30 13:07:41.1688 RandomPlay: while in mode: track, from 127.0.0.1
2006-01-30 13:07:41.1702 RandomPlay: cyclic mode ending due to playlist: playlist loadtracks command
2006-01-30 13:07:41.1712 RandomPlay: playRandom called with type disable
2006-01-30 13:07:41.1722 RandomPlay: 9 songs remaining, songIndex = 0
2006-01-30 13:07:41.1733 RandomPlay: cyclic mode ended


my guess is that the async command response is causing the loadtracks to arrive too late, and it is getting trapped.

cc'ing fred for suggestions.  I'll also try to take a look at it tonight.

The problem is I think the module believes some other code did the loadtracks. This modules plays around subscribing, unsubscribing to the notification system to avoid being notified for stuff it did.

Request.pm proposes a solution with the ->source() call. RandomPlay would subscribe once, then test in its notification handling routine if the request source is itself (and return in such a case).

I guess calling source on the returned request object of executeRequest could work. Even though the request has been executed at this point, the notification will only happen once idle() is reached again.

I thought about RandomPlay when changing to async but could not find a good reason why it would not work in principle, but as we see, in practice there are a couple of issues :-)

checking against the source would be fine.  Execution of the loadtracks is what we want; we just want to avoid seeing that and stopping the 'cyclic' mode.  It is either that, or have the callback in RandomPlay swallow the first loadtracks from the same client.  This would clearly involve a new global var for the plugin to set during playRandom and clear from the callback.

source is cleaner I think. Which one you wanna fix, repeat 2 or this one? 

I can probably take care of both, now that I have noticed that the source function already exists. I'm guessing you have lots on your list anyway.

Mostly enhancements on my list, I've been lucky with bugs so far (and admittedly, the "random 2" bug is not a CLI bug. The same happens from the web interface I am sure). 

I'll take care of Random, it is easier for me than to investigate the many wonders of Source.pm and playmode.

Fixed 5973. Can you try it again?

Thanks

will check it out tonight.

works for me.