MPD Stickers ?

mike.errecart

Hi everyone,

Thinking about how to implement a "browsing by cover art" feature, i came across MPD Stickers.

Are MPD Stickers supported in the RuneAudio MPD version ?

I'm not at home for a week, otherwise i would have tried it directly on the Pi.

Thanks in advance !

Mike

ACX

mike.errecart wroteAre MPD Stickers supported in the RuneAudio MPD version ?

Not yet but we already considered to use them for some purpose. How would you exactly use them for the "browsing by cover art" feature?

mike.errecart

Hi ACX,

ACX wroteHow would you exactly use them for the "browsing by cover art" feature?

That was just a path to explore, i don't have a clear idea. By the way, i will make several tests (when i'm back home) on a MPD server supporting stickers, the first test will be to save an image (the binary data) as a BASE64 string in a Sticker, on the Album level (one image per Album). I'd like to know if that is an option (the 'value' of the Sticker seems to be stored as a 'varchar' in Sqlite by MPD, with no problematic limit in size), if performance is an issue with a large music collection, if boot time is acceptable (Sqlite load phase for the database stickers), etc.

The underlying idea was to store the images in MPD (who is in charge of fetching them and storing them has to be thought about...), and since Stickers support an "Album" level, i thought that would be worth some tests.

Mike

mike.errecart

Hi,

I'll make the tests i talked about this WE (BASE64 encoded image binary data in a MPD sticker), but before that :
Does it look like a viable solution for you experienced MPD users/dev ? Or does it sound like a bad idea at all ?

Mike

waves

RuneAudio already displays cover art for the playing file. A browse by cover art mode for the library could display a thumbnail derived from either a folder.jpg in the album folder or from a cover image already embedded in the music file. For that to work really smoothly I'd suspect the thumbnails need be optimized for filesize and displayed in chunks as the user scrolls down. Otherwise a folder with a lot of albums would take a long time to load in cover browse mode. Imagemagick or some similar tool could be used for the optimization and it would only need to be done once for each folder.jpg file.

hondagx35

Hi waves,

i think Mike is on the right way.

Please consider that most user have their music stored on a NAS and control Rune from a remote device.
Rune scans the music and the folder for artwork (embedded, folder or online).
All this consumes bandwidth and time.
So the only way to get this working is to use some sort of database joined directly with the mpd database.

For that to work really smoothly I'd suspect the thumbnails need be optimized for filesize and displayed in chunks as the user scrolls down.

Especially with huge music libraries this is an absolute must.

Frank

waves

hondagx35 wroteSo the only way to get this working is to use some sort of database joined directly with the mpd database.

I suppose that a few folder views will be more crucial than others. For exampe if the user has all albums by all artists in one big main folder
\Band1 - Album1
\Band1 - Album2
\Band1 - Album3
\Band2 - Album1
\Band2 - Album2
...
then album browsing that big main folder will be the thing to optimize. If the user has a two level structure
\Band1\Album1
\Band1\Album2
\Band1\Album3
\Band2\Album1
\Band2\Album2
...
then the first folder will still likely be the by far biggest.

If there is a "bottleneck" folder like that it would make sense if Rune can cache and preload as much of it as possible even before the user navigates to it. Either in some permanent cache on the remote device (smartphone, PC, ...) if possible. Second best is to load it in the background as early as possible when the user starts RuneAudio in the browser on their device. By the time the user clicks into the Library the cached view would be all set up and pop into view almost instantly.

This goes not just for the cover art but also for the file list, see this #3036 . The list would be even quicker to display if preloaded in the background.

This idea could be extended even more if there are filtering capabilities in the next version. For example the user may have a few favorite filters (searches) that they often use and that has a lot of hits. Those favorite filtered results could also be cached and preloaded.

mike.errecart

Hi Frank, Hi Waves.

Thanks for your comments and interest.

hondagx35 wroteSo the only way to get this working is to use some sort of database joined directly with the mpd database

Yes, that was my idea : use a mpd accessible database, to simplify the way MPD gets access to the covers, using a single and unified way : if the cover is present in the database, display it, if not do nothing. That leaved the complexity of the cover database organization/fetch/store to another (unclear, so far) process.

I was pleased by the idea that MPD stickers could be attached to any MPD objects (songs, albums, artists, folders...), so that the "browse by cover art" feature could be extended and used for albums, and for artists too. Attaching a cover to an album can save storage (compared to attaching a cover to all songs). Attaching a cover to an artist could also be used in a nice way (browse by artist cover art, fallback when no cover art is foound for an album etc).

I made some tests this WE, and unfortunately, stickers only seem to be compatible with "song" objects. I was able to affect, list, delete stickers to song objects, but couldn't do anything with albums even if it is specified in the MPD protocol. Stickers on other MPD objects don't seem to be implemented yet.

I posted on the MPD forum, for that purpose. I'll let you know when i get some clarification.

I'll keep on making tests on stickers, on the song level. I'd like to know how SQLite performs with binary encoded data in a sticker value, and a huge music library.

One question : Do RuneAudio use a custom compiled version of MPD ? Someone already investigated on how hard it would be to change the backend of the MPD stickers database to use another SQL system, or maybe to Redis ?

Mike

mike.errecart

Hi all,

I got a reply from Max Kellermann (main current MPD dev) in the MPD forums, and unfortunately, stickers developpment stopped years ago :

"Stickers are only implemented for songs right now. I never continued developing them, after some frustration. People begged to have stickers implemented for years, which I finally did; and after that, nobody actually used them. Client developers ignored the feature."

No way tu use stickers on the "Album" or "Artist" levels for now, unless addding the feature directly in MPD.

Using stickers for storing a cover for each song sounds quite too much to me. What do you think ?

Do RuneAudio use the main MPD code or a customized version ?

Mike

Orion

Hi Mike,
RuneAudio uses a patched version of MPD that adds the native DSD playback feature. All other features are the same as the 0.19.x version.

Best regards.
Simone.