Serento: The audiophile UPnP controller app for iOS/macOS

[serento]

I'm going to get a little technical to explain what happened.

What Serento does during a sync

When a server advertises Search with a upnp:class predicate, Serento takes a fast path instead of walking the tree album by album. It issues a single paged enumeration, Search(ContainerID="0", SearchCriteria=upnp:class derivedfrom "object.item.audioItem.musicTrack", Filter="*,upnp:userAnnotation[tag.musicbrainz_albumid],...", RequestedCount=500), and then builds albums, artists, tracks and genres on the client side from the properties carried on the returned musicTrack items. Albums come from upnp:album, artists from upnp:artist[@role="AlbumArtist"], and genres come only from upnp:genre on those items, aggregated per album. On that path there is no second source for genre.

What I observed on your library

Your server identifies as MinimServer (Posix/200809.0 UPnP/1.1 ohNet/1.0) and GetSearchCapabilities includes upnp:genre, so Serento took the Search path. In your sync my log line reads: albums=940 tracks=10969 artists=673 genres=0. Albums, artists and tracks were all correct. The genre aggregate came out empty, and every album I inspected afterwards carried an empty genre string.

What the bug on my side was

The Search result had exactly one sanity check before Serento accepted it: did it return zero albums? That check exists because some servers advertise Search and then enumerate nothing. It never looked at any other field. So 940 albums sitting next to 0 genres passed as a valid and complete answer, it was written to the database, and the Genres screen was then correctly displaying what the database held, which was nothing. That is my defect, and it is fixed.

What I cannot tell yet

From my logs alone I cannot distinguish two very different causes: either the property was not present in the responses Serento parsed, or the files in your library do not carry Genre tags. I am not claiming the first. That is precisely why the fix does not assume either.

The fix

When a Search enumeration returns albums but zero genres, and the server advertised upnp:genre as searchable, Serento now asks one cheap question before deciding: Search(ContainerID="0", SearchCriteria=upnp:genre exists true, RequestedCount=1). If that returns a match, the genre data is there and the fast path missed it, so Serento falls back to the Browse walk, which reads the genre from the album containers. If it returns nothing, the library genuinely has no genre tags and the Search result is accepted as it stands. I deliberately did not make it fall back unconditionally, because that would force every library without genre tags into the slow per album walk on every single sync, forever, to rediscover nothing.

What would help me narrow it down

The MinimServer user guide says the server reads and indexes Artist, AlbumArtist, Date, Genre and Composer by default, and that this set is configurable through the indexTags property. Genre is therefore there unless something has changed it. So there are two documented places where it can go quiet, and both take a minute to check: is Genre still listed in your indexTags, and do the files themselves carry a Genre tag? If Genre is indexed and the files are tagged, then the fault is entirely mine and the fix above is what closes it.

For what it is worth, the Filter Serento sends begins with *, and the UPnP ContentDirectory specification defines that as returning all supported properties, required and optional. Album and artist came back on the same responses, so the request was clearly being answered generously. That is why I am asking about the tags rather than about the server.

To be clear about timing: the fix is not in the build you have. It will be in a coming update, so nothing you do right now will make the genres appear. The checks above are only so I know whether the fix is enough on its own.