Mpd, libupnp & co. question

This is actually a set of questions for @adekker but I think a number of other people have invested time.

Background. I wanted a functioning dlna client. I had been using donnie up til version 3.4. @wdehoog then very kindly updated his personal repo on obs to support aarch64. I thought I’d try to push it to chum. After getting libupnp, libupnpp, libmpdclient and donnie into chum:testing, @rinigus wisely asked, ‘conflicts’?

So, I believe there are not from harbour or obs but I believe I would conflict with the oft newer libraries from ade!?

And the question: does SMPC [fork] | — Community Repository System support dlna ?


I’m not the dev of SMPC, but use it everyday (and translated it to French). I never saw such an option, but if my memory is good @adekker want to implement it.

I think we touched most of this in your “state of mpris” thread, which pherjung is already referring to.

Music Player Daemon (MPD) | — Community Repository System itself does support upnp since a few releases as promised (see features compiled).

BTW this has litte to do with an client like SMPC (so yes, any MPD client will support dlna), for those it is transparent and it still talks to a server and port.

I did not upload the missing part for this (if you run mpd on your phone): upmpdcli. This process is the UPnP Renderer front-end to MPD. It is added now: upmpdcli | — Community Repository System. The reason I did not upload it, is because it seems the MPD state file does not always seem to get updated and I am not sure if that’s an MPD bug or not.

After starting upmpdcli (systemctl --user start upmpdcli) you need to tell the mpd.conf that you are using upnp. Then you should be able to access your dlna sources via the filebrowser in SMPC and play content locally.

And if the required libraries will conflict with the older ones you want to upload, you should test yourself I guess.

Edit not only mpd clients will work, a dlna aware program like Jupii will also be able to play music locally.

With donnie and the older libupnp6, libupnpp and libmpdclient, smpc installs without issue, but I have not idea if it’ll work :slight_smile: I’d need to set up a server. But I already have 2 dlna servers :slight_smile:

I think it’s not such a dangerous situation since people can install you’re newer libs anyway. Might kill donnie, but that’s not such a big deal. Thinking aloud. I think for the ‘general user’ donnie is fine, and users who want full mpd can steer around it?

Like I said, those libs have nothing to do with an MPD client like SMPC. It’s server side related or related to mpdcli. The fact that SMPC has no conflicts does not say anything in this case.

That is what I meant with this statement. If the libupnp(p) libs I have conflict with mpdcli.

My current testing of donnie in chum:testing indicates this will be the case. donnie doesn’t like the newer versions I’m testing.

I think, for the sake of peace and simplicity that I’ll static link them after rebuilding the project. It’s a tomb.

for reference, Jupii is also shipping its own version of libupnpp: Jupii/libs/libupnpp at master · mkiol/Jupii · GitHub

I was aware of this having spoken with the author. I’ve now tested installing your libupnp and c++ wrappers and they work fine in parallel. Donnie uses libupnp6 and libupnpp whereas both your packages and jupii supply libnpupnp4 and libupnpp11 or the like. so no name clashes apparently.

I haven’t tested upmpdcli or mpd but I don’t forsee that will be an issue.

I’m pusing donnie from testing. If anyone has issues just ping me.