Bluetooth Cover Art and metadata

[alex124.rh]

Hi there,

Just wondering if you have any idea why/ or if it’s not automatic - how to get the cover art to work from bluetooth and my iPhone. Thanks!

Also a side note on metadata, spotify seems to spit out a line that says video available when there is a music video on the spotify app or an animated album art, and it makes its way into the metadata of the track. Just wondered if there’s a solution to hide these bits. see Figure A

And the second metadata issue is that when you skip track forward on your phone, the end number of the time code, goes to a weird random number then jumps to the correct one. See Figure B.

Thirdly when you skip a track forward on the phone , the metadata of the time code doesn’t update. Leading from this maybe the ability to scan through a song and fast forward could be added with a long press on skip buttons.

https://drive.google.com/drive/folders/ ... p_Su6HneRG images attached

[hudiy]

Hello,

Hudiy uses BlueZ to manage media playback and all related functionalities.

The version of BlueZ included in Raspberry Pi OS Bookworm does not yet support fetching cover art over Bluetooth. However, this feature, along with several improvements to metadata handling was added to BlueZ some time ago:
https://github.com/bluez/bluez/commit/5 ... 50e99df852

We are waiting for the new version of BlueZ to become available in Raspberry Pi OS and we will add support for fetching cover art directly from it.

Regarding Figure A:
The text shown comes directly from the phone. It appears that your media player concatenates this text with the album name. A possible workaround on Hudiy's side is to implement a custom Now Playing widget using HTML and JavaScript, where you can filter or format the metadata as needed.
An example showing how to access media metadata via the API and display it using HTML/JavaScript is available at:
https://github.com/wiboma/hudiy/blob/ma ... media.html

Regarding Figure B:
It looks like the phone or BlueZ is temporarily reporting the track length as 4294967295, which corresponds to the maximum value of a 32-bit unsigned integer. Does this happen consistently or only for specific tracks?
You may try building and installing the latest version of BlueZ to see if it resolves the issues with track duration.

Hudiy also supports injecting cover art manually. For example, a script can use a service such as https://musicbrainz.org to fetch the appropriate cover image based on metadata.
A working example of cover art injection can be found here:
https://github.com/wiboma/hudiy/blob/ma ... verarts.py

Docs for the coverart injection api https://github.com/wiboma/hudiy/blob/ma ... proto#L750

[alex124.rh]

Thanks for the food for thought and detailed answers. Do you have any thoughts on my last point about it loosing sync if i fast forward on the phone, and also about having it be able to fast forward on long press.

TIA

[hudiy]

Do you have any thoughts on my last point about it loosing sync if i fast forward on the phone

This also appears to be closely related to how metadata is transmitted between BlueZ and the phone. Compiling and installing the latest version of BlueZ manually might help, as there have been numerous recent commits in the BlueZ repository related to media metadata handling.

and also about having it be able to fast forward on long press.

We tested the fast forward and rewind functionalities provided by BlueZ, but they didn’t work with any of our test phones (both Android and iOS). We’ll continue monitoring this feature and revisit it once a newer version of Raspberry Pi OS (likely Trixie) is released.

[alex124.rh]

Thanks for the reply. I tried to update blueZ but got a bit lost. Any guidance on this would be great. Thanks