New in 7.9: "Don't Stop The Music"

[mechaMecha]

The command adding that URL to a playlist then is responsible of
grabbing the track information it wants to show. That's why I keep
asking for the command used in this action.

Yeah, sorry, I just haven't had the time to dig into that, but I don't understand how that gets to the root of the problem, either, because as I mentioned before, the data that DSTM adds to the play queue for streaming tracks is the exact same data that's transferred when I add those tracks to a playlist. Neither include any #EXTINF data. That's what slartibartfast has discovered as well, and I'd be willing to bet that's the case for everyone.

The ONLY tracks in the play queue and any playlist that don't include #EXTINF data are streamed tracks added to the play queue by DSTM. Every other track, whether it's a DSTM-added local track or a manually added local or streamed track do not exhibit this problem at all.

[mherger]

New in 7.9: "Don't Stop The Music"

> As stated earlier, it is Material that is invoking JSONRPC to add a
> track to a -stored- playlist via:
>
> ["playlists", "edit", "playlist_id:<playlist id>", "cmd:add", "url:<track url>"]

The original poster mentioned a message "adding null to playlist". I
can't find this string in LMS. Are you showing this? (obviously
respecing that "null" isn't part of the message, of course).

[cpd73]

> As stated earlier, it is Material that is invoking JSONRPC to add a
> track to a -stored- playlist via:
>
> ["playlists", "edit", "playlist_id:<playlist id>", "cmd:add", "url:<track url>"]

The original poster mentioned a message "adding null to playlist". I
can't find this string in LMS. Are you showing this? (obviously
respecing that "null" isn't part of the message, of course).

Nope, can't find any "Adding <> to playlist" messages in Material... I, perhaps wrongly, assumed that after DSTM added a track to the queue, Material adding this track to a stored playlist, that a) in the stored playlist this track had no meta-data and b) when adding to the track back to the queue (at a later date?) it also had no meta-data.

[slartibartfast]

Nope, can't find any "Adding to playlist" messages in Material... I, perhaps wrongly, assumed that after DSTM added a track to the queue, Material adding this track to a stored playlist, that a) in the stored playlist this track had no meta-data and b) when adding to the track back to the queue (at a later date?) it also had no meta-data.

When I add a Tidal track from the play queue to a playlist I see a message
Added to 'playlistname'
Also while it does add the track to the playlist in LMS it doesn't save the m3u file so when LMS is restarted the playlist reverts to the old saved playlist. In default skin the changed playlist can be saved manually but I can't find a way to do that in Material skin.

Sent from my Pixel 3a using Tapatalk

[cpd73]

When I add a Tidal track from the play queue to a playlist I see a message
Added to 'playlistname'
Also while it does add the track to the playlist in LMS it doesn't save the m3u file so when LMS is restarted the playlist reverts to the old saved playlist. In default skin the changed playlist can be saved manually but I can't find a way to do that in Material skin.

Sent from my Pixel 3a using Tapatalk

Hmmmm.... LMS should save playlist on changes, and does for me. With appropriate logging enabled, when adding a track from the queue to a playlist I see:

[22-04-10 19:00:54.3931] Slim::Player::Playlist::modifyPlaylistCallback (1081) Checking if persistPlaylists is set..
[22-04-10 19:00:54.3933] Slim::Player::Playlist::modifyPlaylistCallback (1084) no client or persistPlaylists not set, not saving playlist
[22-04-10 19:00:54.4106] Slim::Control::Commands::playlistsEditCommand (2274) Playlist has changed via editing - saving new list of tracks.
[22-04-10 19:00:54.4151] Slim::Control::Commands::playlistsEditCommand (2281) Writing out playlist to disk..
[22-04-10 19:00:54.4155] Slim::Formats::Playlists::M3U::write (251) Writing out: /home/craig/Downloads/lms/Playlists/Test.m3u

The 'Save' button on the default skin does a rename (with overwrite). So, I could do that, but it should not be required. Material's 'Rename' on a playlist checks if the name has changed, and if not does not try a rename.

[slartibartfast]

Hmmmm.... LMS should save playlist on changes, and does for me. With appropriate logging enabled, when adding a track from the queue to a playlist I see:

[22-04-10 19:00:54.3931] Slim::Player::Playlist::modifyPlaylistCallback (1081) Checking if persistPlaylists is set..
[22-04-10 19:00:54.3933] Slim::Player::Playlist::modifyPlaylistCallback (1084) no client or persistPlaylists not set, not saving playlist
[22-04-10 19:00:54.4106] Slim::Control::Commands::playlistsEditCommand (2274) Playlist has changed via editing - saving new list of tracks.
[22-04-10 19:00:54.4151] Slim::Control::Commands::playlistsEditCommand (2281) Writing out playlist to disk..
[22-04-10 19:00:54.4155] Slim::Formats::Playlists::M3U::write (251) Writing out: /home/craig/Downloads/lms/Playlists/Test.m3u

The 'Save' button on the default skin does a rename (with overwrite). So, I could do that, but it should not be required. Material's 'Rename' on a playlist checks if the name has changed, and if not does not try a rename.

Hmm I checked the modification time of the m3u file and it wasn't updated until I saved it and overwrote it from the default skin. Which logging settings should I use?

Sent from my Pixel 3a using Tapatalk

[kidstypike]

When I add a Tidal track from the play queue to a playlist I see a message
Added to 'playlistname'
Also while it does add the track to the playlist in LMS it doesn't save the m3u file so when LMS is restarted the playlist reverts to the old saved playlist. In default skin the changed playlist can be saved manually but I can't find a way to do that in Material skin.

I don't see that behaviour with material, playlist changes are automatically saved for me. (I don't use any streaming services).


I cleared the play queue.
Started playing 1 track.
Saved the play queue as "kidstypiketest".
Waited until DSTM kicked in.
Added 2 tracks.
Looked at the m3u file in Notepad++, it contained the three tracks.
Restarted LMS, 3 tracks still there, in material and the m3u file.

[cpd73]

Hmm I checked the modification time of the m3u file and it wasn't updated until I saved it and overwrote it from the default skin. Which logging settings should I use?

formats.playlists, player.playlist

[slartibartfast]

formats.playlists, player.playlist

OK, with those logs set to info I get the attached log. The PlayHLS plugin seems to be interfering.

[slartibartfast]

formats.playlists, player.playlist

If I remove the PlayHLS plugin then the playlist is saved but I see a another couple of errors which probably aren't important.

[SAL9K]

Don't Stop The Music (DSTM) Fails from Qobuz Playlist

With DSTM set to "Song Mix (limited to current genres)", and if the current playlist only has local tracks (as in my local library), then DSTM works correctly, and the random list is defined by "URL: randomplay://track?genres=Classical", for example.

However, If I play anything from Qobuz, then DSTM does not work correctly, and plays a random list defined by "URL: randomplay://track", which seems to incorrectly revert to the last Random Mix played (and therefore only the genres manually enabled in that Random Mix).

It appears that DSTM does not (or possibly cannot) generate the valid genres listing it needs from a playlist containing Qobuz tracks??

[SAL9K]

With DSTM set to "Song Mix (limited to current genres)", and if the current playlist only has local tracks (as in my local library), then DSTM works correctly, and the random list is defined by "URL: randomplay://track?genres=Classical", for example.

However, If I play anything from Qobuz, then DSTM does not work correctly, and plays a random list defined by "URL: randomplay://track", which seems to incorrectly revert to the last Random Mix played (and therefore only the genres manually enabled in that Random Mix).

It appears that DSTM does not (or possibly cannot) generate the valid genres listing it needs from a playlist containing Qobuz tracks??

One further thing, If I have a mixed set of local tracks and Qobuz tracks in the current playlist, then DSTM will only grab the genres from the local tracks. Perhaps Qobuz tracks don't have genres in their retrieved metadata?

[SAL9K]

> I don't think that's the problem, because when I use other options for
> DSTM (*not* LastMix/Last.fm), the same null/unknown issue still happens
> with streamed tracks that have been integrated into my music library
> from Tidal and Qobuz. No matter which option I choose, any streamed
> track added to the queue by DSTM results in a null/unknown entry when I
> try to save it to a playlist.

Have you figured out what command is being used to add those tracks to
the playlist? Because everything else is nice chatting, but doesn't
really get us closer to the actual problem...

With DSTM set to "Song Mix (limited to current genres)", and if the current playlist only has local tracks (as in my local library), then DSTM works correctly, and the random list is defined by "URL: randomplay://track?genres=Classical", for example.

However, If I play anything from Qobuz, then DSTM does not work correctly, and plays a random list defined by "URL: randomplay://track", which seems to incorrectly revert to the last Random Mix played (and therefore only the genres manually enabled in that Random Mix).

It appears that DSTM does not (or possibly cannot) generate the valid genres listing it needs from a playlist containing Qobuz tracks??

@mherger These are the DSTM commands I'm seeing generated from a playlist containing Qobuz tracks.

[mherger]

New in 7.9: &quot;Don't Stop The Music&quot;

> However, If I play anything from Qobuz, then DSTM does not work
> correctly, and plays a random list defined by "URL: randomplay://track",
> which seems to incorrectly revert to the last Random Mix played (and
> therefore only the genres manually enabled in that Random Mix).

Online services unfortunately don't know genres (or at least most of
them). Therefore that mix wouldn't work with online tracks. When DSTM
fails to find tracks given the defined mixer it would fall back to a
standard tracks mix, as you've experienced it.

[SAL9K]

> However, If I play anything from Qobuz, then DSTM does not work
> correctly, and plays a random list defined by "URL: randomplay://track",
> which seems to incorrectly revert to the last Random Mix played (and
> therefore only the genres manually enabled in that Random Mix).

Online services unfortunately don't know genres (or at least most of
them). Therefore that mix wouldn't work with online tracks. When DSTM
fails to find tracks given the defined mixer it would fall back to a
standard tracks mix, as you've experienced it.

Thanks for clarifying, @mherger. Interestingly, Qobuz download purchases often require extensive metadata fixes (via MP3Tag, of course), and the genres are typically populated with their french counterpart, E.g. "Classique" instead of "Classical". I do wish the Qobuz plugin had a similar feature set as your excellent Spotty (Spotify) plugin. For personal reasons I just could not keep the Spotify sub, so moved over to Qobuz for their better Classical music selection and Hi-Res. Thanks for all the help and awesome development, I don't know what I'd do without this LMS setup!