mherger wrote:
> That's something I only realised when looking into this issue: for
> remote tracks integrated into the library, there can be two types of
> track objects: the database track object, and the remote track object.
> The latter is being used in streaming and has the negative ID (negative
> is the sign for remote tracks).
>
> I'm very surprised that none of the LMS own code seems to have a problem
> with this. But your plugin definitely does. I added a workaround/fix for
> one issue. Now the ID could be another one... are you relying on the ID
> to track tracks? These wouldn't survive rescans, would they?
The dynamicplaylist_history is filled when tracks are added to the
current playlist, the table contains the client id to have separate
histories per player and the track id+url to identify the track. The
history is cleared in a number of situations, for example when a rescan
done event occurs or when a new dynamic playlist is played, it only
keeps history for currently playing dynamic playlists. It should
probably not clear the history when a new/changed rescan is triggered
but I think it does today. The intention with the history is to avoid
that a track is repeated before all possible tracks matching the
playlist filter has been played. I dont rely on tracks.lastPlayed since
the logic should be separate for each player and also because a bunch
(typically 10) of tracks are added to current playlist (same rolling
window logic as Random Mix plugin) and lastPlayed might not have been
updated yet if the player hasnt played a track previously added yet.
Theoretically it would be possible to join with the url instead of id,
but as I remember I use id to improve performance. I think I joined url
initially when I wrote the plugin but dont remember if I even released
that version. So Im indeed relying on the track id being the same as in
the tracks table.
If its complicated to change it in the LMS core it might be possible to
handle it in the plugin if its possible to somehow retrieve the
database track object through an extra call/query if the plugin get a
remote track object from objectForUrl. However, since Im not able to do
this myself it could maybe be a bit tricky for a new developer to
implement such fix. This of course assumes there is a database track
object available. Not sure in which situations objectForUrl would return
a remote track object ? I guess we are still talking about a track
belonging to your favorites in the streaming service or is tracks you
have played after searching/browsing the streaming service also added to
tracks table ? Only those you have integrated in you library should be
included in a dynamic playlist.
I suspect the difference between my plugin and LMS core usage of
objectForUrl is that LMS core mostly query the database using DBIx so
the Slim::Schema objects are already there when objectForUrl is called
while my plugin query the database using raw SQL and only provides the
url so objectForUrl needs to query the database to fetch and create the
Slim::Schema objects.
Erland Isaksson ('My homepage' (http://erland.isaksson.info))
Developer of 'many plugins/applets'
(https://wiki.slimdevices.com/index.php/User_Erland.html)
*Starting with LMS 8.0 I no longer support my plugins/applets* ('see
here for more information'
(https://forums.slimdevices.com/showthread.php?49483-Announce-New-versions-of-erlands-plugins&p=998836&viewfull=1#post998836)
)
------------------------------------------------------------------------
erland's Profile: http://forums.slimdevices.com/member.php?userid=3124
View this thread: http://forums.slimdevices.com/showthread.php?t=49483
_______________________________________________
plugins mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/plugins
