Issue 78

Here’s the error

:2:src/upmpd.cxx:132::checkContentFormat: didl parse failed :2:src/avtransport.cxx:393::set(Next)AVTransportURI: unsupported format: uri http://192.168.0.2:12345/MediaItems/20009.mp3 metadata .:2:libupnpp/device/device.cxx:354::UpnpDevice: Action failed: SetAVTransportURI code -101

Using Upnplay and foobar2000 with UPnP/DLNA Renderer, Server, Control Point plugin

it used to work just fine but as soon as I upgraded upmpdcli, it magically stopped working. cant remember the last version im working on. im using default config which should work just fine (if not just let me know what is optimal settings for this). I did test a few of my songs stored on a DLNA server, some songs play most of them dont and return a error just like above with just the 2000*.mp3 is changed with another file name like 11138.mp3. But when I use WMP or Bubbleupnp, the problematic songs plays just fine, in fact all of the songs stored in my DLNA server works just fine using bubbleupnp and wmp. but in home I use mostly upnplay because its free and foobar2000 which is far more better as a control point. Even the "play foobar2000 playback stream capture" doesnt work anymore, it used to work just fine before the upgrade.

tl;dr works fine on wmp and bubbleupnp, and its broken on upnplay and foobar2000.

oh im running this on raspberry pi (1st gen) with a USB sound card and arch linux as the OS.

edit: even the locally stored mp3 files in my computer (not on my NAS) doesnt go well and output the same error with different http url.

I think that the change is due to the fact that upmpdcli now tries to validate the track metadata, specifically the format definition, against what it can play.

It seems that the CP sends the URL without any metadata.

Upplay usually just forwards the metadata from the Media Server. What Media Server are you using ?

In any case, please try to set checkcontentformat = 0 in /etc/upmpdcli.conf

Cheers,

jf

set the checkcontentformat to 0 and it does the same error.

Mar 07 07:42:34 archlinux upmpdcli[23348]: :2:src/upmpd.cxx:138::checkContentFormat: format check disabled Mar 07 07:42:39 archlinux upmpdcli[23348]: :2:src/upmpd.cxx:132::checkContentFormat: didl parse failed Mar 07 07:42:39 archlinux upmpdcli[23348]: :2:src/avtransport.cxx:393::set(Next)AVTransportURI: unsupported format: uri http://192.168.0.2:12345/MediaItems/4823.mp3 metadata .:2:libupnpp/device/device.cxx:354::UpnpDevice: Action failed: SetAVTransportURI code -101

what drives me crazy is now that the songs works intermittently, sometimes it play sometimes its not. im using minidlna as my upnp dlna server,

edit:

now it makes things worse, now, my renderer disappear on my network still plays the song on the background, cant control it anymore, need to restart the service to get it appear on my network.

I think I can safely say that the upmpdcli crashed, all I did is adjust the volume ;( and it crashed. I used WMP as a alternative to stream music on it.

Is there any way that I can revert back to older version?

I had not looked at the code closely enough. Unfortunately, the metadata is parsed even if checkcontentformat is false, and the function fails at this point.

I had to look back at what system you are running, because the symptoms (crashes) ressemble a lot to what happens when you run a raspbian package on debian (or vice-versa).

What versions are you running exactly (libupnpp and upmpdcli) ? Did you compile the code locally ? Was libupnpp built the same way as upmpdcli ?

There is no instability issue that I’m aware of in any of the released upmpdcli versions, except for the Debian/Raspbian issue I mentionned, which can’t be your problem, as you are running arch, but still, I’m suspecting some kind of binary mismatch issue.

Would like to help, but this would need some feedback…

Can you reopen this issue? I have exactly the same one:

:2:src/upmpd.cxx:133::checkContentFormat: didl parse failed :2:src/avtransport.cxx:393::set(Next)AVTransportURI: unsupported format: uri http://10.111.188.112:61212/stream/swyh.mp3 metadata :2:libupnpp/device/device.cxx:355::UpnpDevice: Action failed: SetAVTransportURI code -101

I use StreamWhatYouHear on a windows 10 to stream to a raspberry pi raspbian jessie. If I stream to my AV receiver it works. I just compiled upmpdcli & libupnpp after cloning it from your github channel but all I get is the error message above

I added a bit of code to handle cases where no metadata is sent with the uri. Please pull it, rebuild and retry with checkcontentformat = 0 added to /etc/upmpdcli.conf

Thanks that works.

For the record, I still get this error line printed into the log: :2:src/upmpd.cxx:133::checkContentFormat: didl parse failed

Thanks again for the quick fix.

Just to confirm the issue. I am having the exact same errors with upmpdcli (1.2.14-1 on RPI3) when using minimserver as content server. With minidlna it used to work.

@wdehoog: this error is related to the Control Point, not the Media Server. Precisely the error here is due to the fact that the Control Point calls SetAVTransportURI with an empty metadata parameter (the metadata normally has fields for title, artist, duration, etc.). I’m not sure if it is allowed by the standard (too lazy to check), but it was not accepted by upmpdcli.

So please, what control point are you using, and what does the upmpdcli log say when the error occurs ?

Sorry. You are right. I was using my own control point (using libupnpp). Since rygel worked I assumed it was a upmpdcli issue. Turned out I was not saving the didl that libupnpp gave so was sending an empty one to upmpdcli. After fixing this the error does not occur anymore.

Yes. But actually the standard allows for an empty didl fragment (just checked finally…), so I fixed upmpdcli to accept it and not even print an error message (only if checkcontentformat is not set, else it still causes an error).

Update: Streaming MP3 to upmpdcli work but when I try to stream PCM/L16 to it I get the following error: :2:src/avtransport.cxx:393::set(Next)AVTransportURI: unsupported format: uri http://10.111.188.112:57190/stream/swyh.wav metadata [] :2:libupnpp/device/device.cxx:355::UpnpDevice: Action failed: SetAVTransportURI code -101 note: checkcontentformat = 0 is set

This is weird, I can’t see in the code how this could happen with checkcontentformat = 0.

The easiest way to solve this would be that you add some log messages to the beginning of UpMpd::checkContentFormat() in upmpd.cpp, and see why it returns false.