Re: idleStreams

mherger wrote: 
> I think what might take the most time is randomization...
> 
> One workaround _might_ be (to be tested) to sacrifice some randomness in
> 
> favor of performance: track IDs are numerical, increasing values. You 
> can easily get the largest and the smallest number. Create random values
> 
> in that range and select just that one track in a loop.
> 
> As I said: I'm not sure this is any faster than randomizing the full 
> result set. But it would avoid creating a (background) copy of the table
> 
> for the randomized values.

I've been meaning to switch to track IDs for some time. Did that +
looking up track objects later and only if necessary. Saved a little
time but still...
The thing is, so far I don't think I can do without the randomization in
the SQLite code. Not to randomize the tracks *in* the limited result
set. I only use it because order by random happens -before- the results
are limited and it helps to avoid always getting the same batches of
tracks when you start a dynamic playlist.

I've looked at your -RandomPlay- plugin (esp. '*these lines*'
(https://github.com/Logitech/slimserver/blob/public/8.4/Slim/Plugin/RandomPlay/Mixer.pm#L108-L113))
which seems to use a different approach. From what I gather, it
retrieves *all* track IDs matching the query params, shuffles this
idList and then limits the results (in Perl I think). SQlite queries
against the LMS database without a limit take more time here. The key to
RandomPlay's speed could be that it uses
Slim::Control::Queries::_getTagDataForTracks to fetch the track IDs.
Just a guess.
DPL always uses fully fleshed out SQLite statements.  And
_getTagDataForTracks seems to expect separate arguments (album id, genre
id...). Not sure if I could break up a fully fleshed out SQLite query
(esp. if it contains multiple statements) into single arguments in a
-reliable- way.

There was one nice '*approach*'
(https://tpetry.me/20210507-how-to-optimize-order-by-random) using
spatial extensions (which also nicely explained the problems with other
order by random replacements) but it requires building platform-specific
extensions and I don't even know by how much it would make things
faster. Implementation might be above my paygrade anyway.
So I'll stick with order by random for now. Not ideal but better than
starting with the same tracks over and over again.



For '*bug reports*' (https://github.com/AF-1/), *FAQ* (if available) and
more detailed information about my plugins, please see the
'*GitHub*' (https://github.com/AF-1/) page or
the *first post* in the support thread for a plugin. Please post *bug
reports* for my plugins *only* on '*GitHub*' (https://github.com/AF-1/).
Thank you.
------------------------------------------------------------------------
AF1's Profile: http://forums.slimdevices.com/member.php?userid=39306
View this thread: http://forums.slimdevices.com/showthread.php?t=117004