Hey there.
First of all, thank you very much for this project. It's finally the solution I was searching for. :)

Right now I'm working on a simple MPD dashboard that runs in a browser. It gets the data from the MPD api and displays it.

I'm using upmpdcli 1.2.16 because newer versions seem to crash BubbleUpnp.

However, I seem to have found an anomaly when I stream Tidal (HiFi) with BubbleUpnp.
Some albums have stripped meta data. For example the album title is missing. I also have modified the Upmpdcli::dirObjToUpSong function to copy the Tidal AlbumId into the MPD comment section so I can get more information about the running track. This also seems to get unset when the song starts playing. For other albums it works fine. It behaved like this before I've touched the code.

I get the song information with currentsong and the playlistinfo[0] MPD api.
Even more strange is the fact that the other playlist items from the same album seem to have this metadata, until they get played. Then they get cut.

This is the result of a "faulty" meta data set (currentsong):

{ file: 'http://xxxxx:57645/proxy/tidal/xxxxxxxxx.flac',
  Title: 'One More Time',
  Artist: 'I Prevail',
  Comment: '00888072012417_1_11',
  Pos: '10',
  Id: '37',

The second item in the playlist of the "faulty" album (playlistinfo 1):

{ file: 'http://xxxxxxx:57645/proxy/tidal/xxxxxxx.flac',
    Comment: '{"id":"tidal/albums/65897142/65897144","parentId":"tidal/albums/65897142"}',
    Artist: 'I Prevail',
    Album: 'Lifelines',
    Title: 'Stuck In Your Head',
    Track: '2',
    Pos: '1',
    Id: '46' }

Calling currentsong on a working album looks like this on my end (client parsed):

{ file: 'http://xxxxxx:57645/proxy/tidal/xxxxxx.flac',
   { id: 'tidal/albums/90856271/90856274',
     parentId: 'tidal/albums/90856271' }, // Comment gets transferred, but parsed clientside
  Artist: 'Between The Buried And Me',
  Album: 'Automata II',
  Title: 'Voice Of Trespass',
  Track: '3',
  Pos: '0',
  Id: '40'

I have already tried to fix this problem on my own and invested a few hours without success.
My hope is that it's actually an easy problem to fix when you know the code.
That the comment has this "00888072012417_1_11" string inside makes me wonder if some data get's corrupted, or upmpdcli does not restore the meta data correctly.

Maybe you have a clue how to fix this issue. I would like to help too! :)


  • medoc


    Trying to make sure I understand: did you also modify mpdcli.cxx:send_tag_data() to send the comment data to mpd instead or in addition of the bogus "client=upmpdcli" ?

    If this is the case, and once send_tag_data() is called, I think that any change to the metadata can only happen inside MPD.

    I guess that this would be possible if the stream has embedded metadata, which probably overrides what is set with send_tag_data() (not 100% sure).

    So I'd try to download one of the affected tracks
    and see if it has metadata.

    Not 100% sure though, it's more an idea of something to explore.

    I may have a bit of trouble responding in the next few days, so don't be surprised if I'm a bit slow.

    Last edit: medoc 2018-10-11
  • lmoe

    Thank you for your response!

    Yes you are right. I use send_tag_data (comment) to set a comment for a song. That works fine.

    And you are right with the metadata of the flac file too.
    It seems like Tidal has tracks with, and without flac metadata.

    I had checked a file without flac metadata, and thought it's always like that. I was wrong. Sigh. What a waste of time :D

    Now I have to find a way to disable fetching this metadata and use the manually applied data instead. As there is no configuration for this, I'll have to fork and extend MPD itself. But that looks rather simple.

    You are my hero right now. Thanks again! :)

  • medoc

    By the way, the issues between Bubble UPnP and upmpdcli are supposedly fixed in upmpdcli 1.3.6

    Also if you have ideas for improvements, your are most welcome :)

  • lmoe

    Yeah I've looked into the code yesterday and saw the commit.
    But compiling the current version resulted in a few linker errors I didn't want to put my hands on at midnight. Probably just a libupmpdcli version mismatch..

    But I will def. take a look soon because that sounds great! :)

    What really would be nice, is an API that provides all these tag informations in some way so people like me don't have to modify the code.

    I know it places metadata files on the filesystem, but a simple HTTP API / MPD like socket API would be great, especially because the file seems to get removed and recreated, instead of overwritten so it's harder to put a watcher on the file.

    Otherwise upmpdcli is a real lifesaver and it does the job very well.
    I can finally play HiFi music gapless streamed from my phone. Something even bigger applications like Kodi can't provide.

    In the mean time I have "patched" mpd. I only use mpd for upmpdcli, so the hack is fine for me.

    If someone is interested in this take a look at here:

    And my music dashboard is ready for the next party:

    Thanks again, I'll make sure leave a donation next month :)

    Last edit: lmoe 2018-10-11
  • Anonymous

    If I recall correctly I did compile both master branches which produced the linker errors. But I will try it again today after work.

    My dashboard is written in Nodejs and I've tried a few UPnP libraries out. However it was easier to just use the MPD bindings. But learning is a great thing, so maybe I'll get into it again too. :)

  • medoc

    Send me the link errors if you get them again, As far as I know, the master or maintenance branches should build all right at the moment.

    There are no js bindings for libupnpp at the moment. The Python bindings are based on Swig, so it would probably not be impossible to generate JS bindings, but I've learned while doing the Python ones that bindings for C++ APIs are not always piece of cake...

  • lmoe

    Sorry for the late reply. I guess you know how time consuming our job can get. :)
    I had an older version of libupnpp installed in /usr/local/ and the new one in /usr/. configure used the /usr/local one as a default producing the errors. So it's all fine now after fixing the paths.

    My first idea to get the track information was to use upnp, but I like to tinker and the upnp libraries didn't provide what I needed. So I put my hands on the source itself. Which is fine for me. :)

    Donation went out. Thank you for help!

  • medoc

    • status: open --> closed
    • milestone: -->

Cancel   Add attachment