Presets to play the latest version of a playlist.

[r5yk5]

I have some playlists that update every hour that I can play on my wiim devices via dlna. I can choose them as presets in home music share using either Emby or Minim Server. But when I use the remote to play them using the numbered buttons the version of the playlist that was present at the time I set the preset plays, not the current one. If I go through the menus (Home Music Share > Server > Playlists > Playlist) then the current version plays.
Is it possible to have the preset buttons on the remote load and play the current version of the playlist please? Many thanks.

 

[Burnside]

I have some playlists that update every hour that I can play on my wiim devices via dlna. I can choose them as presets in home music share using either Emby or Minim Server. But when I use the remote to play them using the numbered buttons the version of the playlist that was present at the time I set the preset plays, not the current one. If I go through the menus (Home Music Share > Server > Playlists > Playlist) then the current version plays.
Is it possible to have the preset buttons on the remote load and play the current version of the playlist please? Many thanks.

I think this has been mentioned before - presets seem to store the play queue rather than a link to the playlist itself. I struggle to see the logic in what it does…

I’d suggest you should raise a ticket to WiiM via the more/feedback section in the app to highlight this discrepancy

 

[r5yk5]

Thanks, I've done that.

 

[simbun]

I have some playlists that update every hour that I can play on my wiim devices via dlna. I can choose them as presets in home music share using either Emby or Minim Server. But when I use the remote to play them using the numbered buttons the version of the playlist that was present at the time I set the preset plays, not the current one.

There isn't a reliable (across all servers) way to bookmark playlists/albums/artists in UPnP, they're all just items in a list, the pointers of which can change at any time.

WiiM may have chosen to store the items of the playlist as they can be more stable, especially when using MinimServer as they're based on the OS path of the track.

 

[r5yk5]

As you say the playlists are just lists of absolute paths to files, eg

/mnt/Music/Music/Roots/World Music/Silvana Estrada/Marchita/1-02 La corriente.flac
/mnt/Music/Music/Roots/Jazz/Julia Hulsmann Quartet/Not Far From Here/1-03 This Is Not America.flac
/mnt/Music/Music/Roots/Jazz/Andrea Motis/Live at Jamboree_ Barcelona/1-04 Sun Showers.flac

If I remove an album from my hard drive then there is a possibility the file won't exist in the playlist until it updates. I don't know how MinimServer or Emby work really but from what I've seen, if the file listed in a playlist doesn't exist then it's simply not included in the playlist but all the existing ones are. So a new newly updated playlist is far more likely to contain existing files than an older one. (Not that I'm in the habit of moving or deleting files anyway). So, for me at least, it would be more stable to have wiim play the current list.

That being said all I really want is to press number 2 and have a new mixture of Bluesy tunes play rather than the same one that started this morning, if that's possible.

 

[simbun]

As you say the playlists are just lists of absolute paths to files

I wasn't talking about playlists specifically; every level in the browse hierarchy is an item from a list (in very simple terms) that's been sent from the server (MinimServer/Emby) to the control point (WHA) for displaying to the user.

If we take MinimServer as an example, the initial browse tree is sent to the control point as DIDL:

<DIDL-Lite>
  <container id="0$albums" parentID="0" restricted="1" searchable="1">
    <dc:title>8 albums</dc:title>
    <upnp:class>object.container</upnp:class>
  </container>
  <container id="0$items" parentID="0" restricted="1" searchable="1">
    <dc:title>30 items</dc:title>
    <upnp:class>object.container</upnp:class>
  </container>
  <container id="0$playlists" parentID="0" restricted="1" searchable="1">
    <dc:title>2 playlists</dc:title>
    <upnp:class>object.container</upnp:class>
  </container>
  <container id="0$=Artist" parentID="0" restricted="1" searchable="1">
    <dc:title>Artist</dc:title>
    <upnp:class>object.container</upnp:class>
  </container>
  <container id="0$=Genre" parentID="0" restricted="1" searchable="1">
    <dc:title>Genre</dc:title>
    <upnp:class>object.container</upnp:class>
  </container>
  ...
  ...
</DIDL-Lite>

As you can see we have our initial browsing hierarchy:

8 albums
30 items
2 playlists
Artist
Genre
...

When we select '2 playlists' the WHA requests the next level in the hierarchy from MinimServer:

<DIDL-Lite>
  <container id="0$playlists$*p0" parentID="0$playlists" childCount="1" restricted="1" searchable="1">
    <dc:title>Playlist aa</dc:title>
    <upnp:class>object.container.playlistContainer</upnp:class>
  </container>
  <container id="0$playlists$*p1" parentID="0$playlists" childCount="1" restricted="1" searchable="1">
    <dc:title>Playlist zz</dc:title>
    <upnp:class>object.container.playlistContainer</upnp:class>
  </container>
</DIDL-Lite>

Which translates to:

Playlist aa
Playlist zz

The only way to bookmark an item (excluding tracks) is to record the container id (Playlist zz = '0$playlists$*p1'), but there is nothing in the UPnP specification to say that the internal browsing id's have to persist across rescans, so for most servers they don't.

If you had bookmarked Playlist zz (0$playlists$*p1) then created a new playlist called 'Playlist mm' and performed a MinimServer rescan, your bookmark would now be pointing to your new playlist, because the container id's MinimServer generates are distributed alphabetically e.g.

Initial scan:

Playlist          Container id
Playlist aa.m3u   0$playlists$*p0
Playlist zz.m3u   0$playlists$*p1

Add 'Playlist mm' and rescan:

Playlist          Container id
Playlist aa.m3u   0$playlists$*p0
Playlist mm.m3u   0$playlists$*p1
Playlist zz.m3u   0$playlists$*p2

I have suggested to WiiM that using UPnP search is a better alternative, but this differs across servers too (some don't even support search!).

Not every server works the same way (I've used MinimServer for years so I know how it works) but hopefully you now understand why it's not a simple request.

 

[Burnside]

I wasn't talking about playlists specifically; every level in the browse hierarchy is an item from a list (in very simple terms) that's been sent from the server (MinimServer/Emby) to the control point (WHA) for displaying to the user.

….

I have suggested to WiiM that using UPnP search is a better alternative, but this differs across servers too (some don't even support search!).

Not every server works the same way (I've used MinimServer for years so I know how it works) but hopefully you now understand why it's not a simple request.

Thanks for that - I had naively assumed (without much thinking) that the UPNP server would have retained the file system full hierarchic name of the playlist as an index key. Now I know better

 

[r5yk5]

Yes thanks, now I know better too.
I suppose if I really wanted to I could get one of those ifra red adapter thingys then buy a fancy universal remote that you can program
and use roon's cli extension or play direct from the server but I can't be faffed with that. I guess I'm just going to have to use my phone and have the presets as radio stations. I was just hoping I could use the wiim remote somehow.

Anyway, onwards and upwards. Thanks for the help

 

[simbun]

Thanks for that - I had naively assumed (without much thinking) that the UPNP server would have retained the file system full hierarchic name of the playlist as an index key. Now I know better

Upon making a selection in the WHA I believe it's the container id (of the selected item) that's passed back to the server so it can deliver the next level in the hierarchy.

Using MinimServer as an example:

container id="0$=ReleaseType$497$=Genre$248$=Label$5063$*a411"

This tells MinimServer that I first chose item 497 from the ReleaseType hierarchy (I don't have 497 items in my ReleaseType category), then item 248 from the Genre hierarchy ...

Because a playlist isn't part of a hierarchy (there's only one way to get to playlists) it should be relatively easy to generate their container id's so they persist across rescans e.g. append the playlist name or a hash of the path+name to 0$playlists$*.

In theory, using the hash of the selected value would also work for all other hierarchies too:
container id="0$=ReleaseType$497" becomes
container id =0$=ReleaseType$f40d94334dbe6e357e7241d6fffd18fc" (f40d94334dbe6e357e7241d6fffd18fc being the MD5 of "Compilation")

I did ask the author of MinimServer to consider persisting container id's (without suggesting a way to do it), but I don't think he's interested as it isn't part of the spec (and very few control points offer the flawed functionality).

Just for sake of completeness, having selected a playlist the server would send the metadata of the tracks that form the playlist:

<DIDL-Lite>
  <item id="0$playlists$*p0$*i28" parentID="0$playlists$*p0" restricted="1">
    <dc:title>Track 1</dc:title>
    <dc:date>2025-01-01</dc:date>
    <upnp:album>Album 1</upnp:album>
    <upnp:artist role="AlbumArtist">Artist1</upnp:artist>
    <upnp:originalTrackNumber>1</upnp:originalTrackNumber>
    <upnp:albumArtURI dlna:profileID="JPEG_SM">http://192.168.99.99:9790/minimserver/*/Testing/Artist*201/folder.jpg</upnp:albumArtURI>
    <res duration="0:00:09.500" size="323434" bitsPerSample="16" bitrate="176400" sampleFrequency="44100" nrAudioChannels="2">http://192.168.99.99:9790/minimserver/*/Testing/Artist*201/01.01.flac</res>
    <upnp:class>object.item.audioItem.musicTrack</upnp:class>
  </item>
  <item id="0$playlists$*p0$*i29" parentID="0$playlists$*p0" restricted="1">
    ...
  </item>
  ...
</DIDL-Lite>

Remembering that neither the control point nor the renderer have access to the filesystem itself; all resources (tracks and images) are delivered over http (the media server).