Custom Skip isn't very effective if you like the skip many tracks.
When Dynamic Playlist needs more tracks, the following happens:
1.
It retrieves additional tracks from the plugin that supplies the
playlist. In the case of a SQL Playlist playlist this means that it
executes the SQL statement you've listed in your playlist.
2.
It checks each track against all available filters in Custom Skip, as
soon as a track matches a skipping filter it will discard it and
continue with the next. The process is iterated over all tracks
returned in step 1.
3.
If there aren't enough tracks remaining after step 2, it repeats the
process and executes 1 and 2 again to try to find more tracks. This
process can be repeated many times if the skipping filters matches most
tracks. The "Number of retries when filtering" parameter in the Dynamic
Playlist settings controls how many times it retries before giving up
and ends the playlist.
4.
When there are tracks that haven't been skipped it adds them to the
current playlist.
I think the major performance hit is every time it in step 3 realizes
that it needs to execute 1 and 2 again, especially if this happens
several times. I think the Custom Skip filters themselve probably is
very fast, but you can probably check if this is the case by enabling
some debugging in the Custom Skip plugin. If you have debug logging
enabled, I think you should be able to see the timestamps when each
Custom Skip filter is evaluated to calculate the time for each skip
filter. You can enabled debug logging also for Dynamic Playlist to see
how long it takes to retrieve the tracks in step 1.
The only solution I see that completely will solve the performance
issues is if the skipping logic is incorporated in the SQL statement
executed in step 1. However, this cannot easily be done with two
separate plugins, especially since step 1 might not even be a SQL
statement depending on which plugin that provides the playlist. As an
example think of a plugin that likes to provide dynamic playlists based
on MusicIP mixes, in that case the skipping logic would have to be
incorporated in the query against MusicIP which isn't SQL at all.
What is the reason that you don't think it's easy to maintain the
genres in SQL Playlist ?
Is it because you are going to want to exclude the same genres in
several playlists ?
Is it because you need to edit the SQL directly instead of having
simple checkboxes to mark ?
By the way, your SQL doesn't just return non rated tracks it also
limits the tracks returned to those that haven't been played the last 3
hours.
Since you also has the logic to not play tracks that have already been
played in this playlist, it might get a bit faster if you remove the 3
hour limit. Should be something like:
Code:
--------------------
-- PlaylistName:Phil's Not Rated Songs
-- PlaylistGroups:Songs
-- PlaylistStartAction1:cli:customskip setsecondaryfilter
skip_non_songs.cs.xml
-- PlaylistStopAction1:cli:customskip clearsecondaryfilter
select tracks.url from tracks
left join track_statistics t2 on
tracks.url=t2.url and t2.rating>0
left join dynamicplaylist_history on
tracks.id=dynamicplaylist_history.id
where
tracks.audio=1
and t2.url is null
and dynamicplaylist_history.id is null
group by tracks.id
order by rand()
limit 10;
--------------------
An additional change you can try if you use this in a new 7.1 release,
is that you could replace "track_statistics" with "tracks_persistent"
and join using tracks_persistent.track instead. This would be something
like:
Code:
--------------------
-- PlaylistName:Phil's Not Rated Songs
-- PlaylistGroups:Songs
-- PlaylistStartAction1:cli:customskip setsecondaryfilter
skip_non_songs.cs.xml
-- PlaylistStopAction1:cli:customskip clearsecondaryfilter
select tracks.url from tracks
left join tracks_persistent t2 on
tracks.id=t2.track and t2.rating>0
left join dynamicplaylist_history on
tracks.id=dynamicplaylist_history.id
where
tracks.audio=1
and t2.track is null
and dynamicplaylist_history.id is null
group by tracks.id
order by rand()
limit 10;
--------------------
The "tracks_persistent" table is a new table in the SqueezeCenter
database introduced in 7.1 that will survive full rescans, the purpose
is to implement rating support directly in SqueezeCenter (enhancment
#142). The table and some logic got into the 7.1 release while the user
interface for changing ratings will be introduced in 7.2 or 7.3.
The reason "tracks_persistent" might be faster than "track_statistics"
(the TrackStat table) is that you can join with integer columns in
"tracks_persistent" while "track_statistics" needs to join using
"url"(text) columns.
Philip Meyer;321922 Wrote:
>
> Would it be possible to create a custom skip filter that allows
> multiple genres to be picked in one filter?
>
For the above mentioned reasons I'm not sure it will improve
performance a lot because I think the major performance penalty happens
if step 1 needs to be executed several times.
Philip Meyer;321922 Wrote:
>
> Also, I would like to exclude songs that exist in a certain folder path
> (to ensure all podcasts are excluded, as they don't all have
> genre=podcast), but there's no custom skip filter for that.
>
If you are using the Multi Library plugin, you can create a library
that only contains files in that directory. You can then use the Custom
Skip filter that skips everything within that library. If you don't
already have a separate library for podcasts, you probably want to make
sure to uncheck all menu checkboxes when you create the library to make
sure an additional pod cast library doesn't cause extra startup delays
in the Custom Browse plugin (which I think you are using).
I've been thinking of adding a path skipping filter in Custom Skip, but
the problem is that it is a lot of work because then I would need to be
able to enter text through the player interface when creating the
filter which is something I don't do today. All filters available today
can be edited from the player interface, so a specific rule for path
filter that it only can be edited from the web interface would also be
a lot of extra work to handle. So for now I think the Multi Library
approach should work pretty well as a workaround if you like to do path
based filtering.
--
erland
Erland Isaksson
'My homepage' (http://erland.isaksson.info) 'My download page'
(http://erland.isaksson.info/download)
(Developer of 'TrackStat, SQLPlayList, DynamicPlayList, Custom Browse,
Custom Scan, Custom Skip, Multi Library and Database Query plugins'
(http://wiki.erland.isaksson.info/index.php/Category:SlimServer))
------------------------------------------------------------------------
erland's Profile: http://forums.slimdevices.com/member.php?userid=3124
View this thread: http://forums.slimdevices.com/showthread.php?t=50115
_______________________________________________
plugins mailing list
plugins@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/plugins
