Issue 1

Hi, I want use sc2mpd to implement multiroom, I installed upmpdcli and sc2mpd in my ubuntu computer and install linn songcast in my windows7, After runned upmpdcli in ubuntu, songcast can’t find receiver in it’s receiver list, I can’t find sc2mpd help document, Can you help me ？ Thank you

Hi,

For Songcast to see the upmpdcli receiver, it must be in the stopped state (if it’s paused playing a song it won’t appear). Otherwise, it usually works. Do you see the upmpdcli playlist service from a windows Control Point (e.g. Kazoo) ?

What version are you running ? I am currently making some progress on multiroom with songcast. If you are comfortable building from git code and testing stuff, I’d be glad to point you to the current state of things and would appreciate any feedback (once we’ve solved your initial problem).

Thanks, I will try it in the stopped state,The version of upmpdcli is installed from ubuntu ppa, But I can building from git code.I have compiled git code to my mini2440 board(A arm board), and it worked perfectly.Now I’m trying to implement multiroom in my couples of arm board. I hope to know more about multiroom knowledge.fForgive my poor Englist ( ^_ )

No problem about the English, it is not my language either :) I am going away for the day, but let me know how your Receiver goes.

I am working on initial multiroom support, I hope I can give you something to try soon (hopefully tomorrow).

Hi, I have tried again, Now I can see upmpdcli in songcast receiver, But there is a problem again, I upload a picture 

This is my upmpdcli log: src/ohreceiver.cxx:129::OHReceiver::play: no uri libupnpp/device/device.cxx:321::UpnpDevice: Action failed: Play src/ohmetacache.cxx:123::dmcacheSaveWorker: can’t get task from queue

This is weird, I’ve never seen it. The uri should have been set by a preceding "SetSender" call, I need to see the whole log to try and determine what happened.

Could you please set the umpdcli log level to 6, restart upmpdcli, then restart the windows machine and try to activate songcast, then send me the upmpdcli log ?

Linn songcast make me crazy,When songcast crashed once, it can’t run again. I uninstalled and reinstalled Linn songcast many times.But it still can’t work. I will install songcast in my another computer and try it again. Thanks

I run SOngcast in a Win 7 virtual machine, and I usually don’t have too many problems. Only thing is I sometimes have to restart the machine (but quite rarely). I never had to reinstall to this point. My current version is 4.4.177, new from today and seems to work same as previous which was 4.3.7

Hi, I changed to another computer, My songcast have same problem,But I have log a level 6 file: src/mpdcli.cxx:212::MPDCli::checkForCommand: addtagid libupnpp/upnpplib.cxx:72::LibUPnP: serveronly 1 &hwaddr 0xbfa829ac ifname [] inip [] port 0 libupnpp/upnpplib.cxx:104::LibUPnP: Using IP 192.168.0.100 port 49154 libupnpp/upnpplib.cxx:215::LibUPnP::o_callback: event type: UPNP_EVENT_SUBSCRIPTION_REQUEST libupnpp/device/device.cxx:257::UPNP_EVENT_SUBSCRIPTION_REQUEST: urn:av-openhome-org:serviceId:Product src/ohproduct.cxx:63::OHProduct::OHProduct: sources: <SourceList > <Source > <Name >Playlist</Name > <Type >Playlist</Type > <Visible >true</Visible > </Source > <Source > <Name >UpnpAv</Name > <Type >UpnpAv</Type > <Visible >true</Visible > </Source > <Source > <Name >Receiver</Name > <Type >Receiver</Type > <Visible >true</Visible > </Source > </SourceList >

src/mpdcli.cxx:441::MPDCli::consume:0 src/ohplaylist.cxx:105::ohPlaylist: cache restore done src/upmpd.cxx:618::Entering event loop libupnpp/upnpplib.cxx:215::LibUPnP::o_callback: event type: UPNP_EVENT_SUBSCRIPTION_REQUEST libupnpp/device/device.cxx:257::UPNP_EVENT_SUBSCRIPTION_REQUEST: urn:av-openhome-org:serviceId:Receiver libupnpp/upnpplib.cxx:215::LibUPnP::o_callback: event type: UPNP_EVENT_SUBSCRIPTION_REQUEST libupnpp/device/device.cxx:257::UPNP_EVENT_SUBSCRIPTION_REQUEST: urn:av-openhome-org:serviceId:Volume libupnpp/device/device.cxx:317::UpnpDevice::notifyEvent urn:upnp-org:serviceId:RenderingControl LastChange src/avtransport.cxx:288::UpMpdAVTransport::getEventDataTransport: <Event xmlns="urn:schemas-upnp-org:metadata-1-0/AVT_RCS" > <InstanceID val="0" > <CurrentRecordQualityMode val="NOT_IMPLEMENTED"/ > <RecordMediumWriteStatus val="NOT_IMPLEMENTED"/ > <PossibleRecordStorageMedia val="NOT_IMPLEMENTED"/ > <RelativeCounterPosition val="0"/ > <TransportState val="STOPPED"/ > <PossibleRecordQualityModes val="NOT_IMPLEMENTED"/ > <CurrentTrack val="1"/ > <CurrentMediaDuration val="00:00:00"/ > <TransportPlaySpeed val="1"/ > <CurrentTransportActions val="Next,Previous,Play"/ > <TransportStatus val="OK"/ > <AbsoluteTimePosition val="0:00:00"/ > <NumberOfTracks val="1"/ > <CurrentTrackDuration val="00:00:00"/ > <CurrentPlayMode val="NORMAL"/ > <RelativeTimePosition val="0:00:00"/ > <PlaybackStorageMedium val="NONE"/ > <PossiblePlaybackStorageMedia val="HDD,NETWORK"/ > <AbsoluteCounterPosition val="0"/ > <RecordStorageMedium val="NOT_IMPLEMENTED"/ > </InstanceID > </Event >

libupnpp/device/device.cxx:317::UpnpDevice::notifyEvent urn:upnp-org:serviceId:AVTransport LastChange libupnpp/device/device.cxx:317::UpnpDevice::notifyEvent urn:av-openhome-org:serviceId:Info BitRate libupnpp/device/device.cxx:317::UpnpDevice::notifyEvent urn:av-openhome-org:serviceId:Time Seconds src/mpdcli.cxx:616::MPDCli::getQueueSongs: 0 songs src/ohplaylist.cxx:144::OHPlaylist: current ids: libupnpp/device/device.cxx:317::UpnpDevice::notifyEvent urn:av-openhome-org:serviceId:Playlist TransportState libupnpp/upnpplib.cxx:215::LibUPnP::o_callback: event type: UPNP_CONTROL_ACTION_REQUEST libupnpp/device/device.cxx:201::UPNP_CONTROL_ACTION_REQUEST: Play. Params: <?xml version="1.0"? > <u:Play xmlns:u="urn:av-openhome-org:service:Receiver:1" >/u:Play

src/ohreceiver.cxx:121::OHReceiver::play src/ohreceiver.cxx:129::OHReceiver::play: no uri libupnpp/device/device.cxx:229::UpnpDevice: Action failed: Play 215::LibUPnP::o_callback: event type: UPNP_CONTROL_ACTION_REQUEST libupnpp/device/device.cxx:201::UPNP_CONTROL_ACTION_REQUEST: SetSender. Params: <?xml version="1.0"? > <u:SetSender xmlns:u="urn:av-openhome-org:service:Receiver:1" > <Uri >ohz://239.255.255.250:51972/92e1ad7ef78ce405bb968c29818ed0a4</Uri > <Metadata ><DIDL-Lite xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/" xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/"><item id="0" restricted="True"><dc:title>ACER-PC</dc:title><res protocolInfo="ohz:_:_:u">ohz://239.255.255.250:51972/92e1ad7ef78ce405bb968c29818ed0a4</res><upnp:class>object.item.audioItem</upnp:class></item></DIDL-Lite></Metadata > /u:SetSender

src/ohreceiver.cxx:235::OHReceiver::setSender src/ohreceiver.cxx:244::OHReceiver::setSender: uri [ohz://239.255.255.250:51972/92e1ad7ef78ce405bb968c29818ed0a4] meta [<DIDL-Lite xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/" xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/" ><item id="0" restricted="True" >dc:titleACER-PC/dc:title<res protocolInfo="ohz:*:*:u" >ohz://239.255.255.250:51972/92e1ad7ef78ce405bb968c29818ed0a4</res >upnp:classobject.item.audioItem/upnp:class</item ></DIDL-Lite >] libupnpp/device/device.cxx:317::UpnpDevice::notifyEvent urn:av-openhome-org:serviceId:Receiver Uri libupnpp/upnpplib.cxx:215::LibUPnP::o_callback: event type: UPNP_CONTROL_ACTION_REQUEST libupnpp/device/device.cxx:201::UPNP_CONTROL_ACTION_REQUEST: SetSourceIndex. Params: <?xml version="1.0"? > <u:SetSourceIndex xmlns:u="urn:av-openhome-org:service:Product:1" > <Value >2</Value > /u:SetSourceIndex

src/ohproduct.cxx:204::OHProduct::setSourceIndex src/ohproduct.cxx:209::OHProduct::setSourceIndex: 2 libupnpp/upnpplib.cxx:215::LibUPnP::o_callback: event type: UPNP_CONTROL_ACTION_REQUEST libupnpp/device/device.cxx:201::UPNP_CONTROL_ACTION_REQUEST: SetSourceIndex. Params: <?xml version="1.0"? > <u:SetSourceIndex xmlns:u="urn:av-openhome-org:service:Product:1" > <Value >2</Value > /u:SetSourceIndex

src/ohproduct.cxx:204::OHProduct::setSourceIndex src/ohproduct.cxx:209::OHProduct::setSourceIndex: 2 libupnpp/upnpplib.cxx:215::LibUPnP::o_callback: event type: UPNP_CONTROL_ACTION_REQUEST libupnpp/device/device.cxx:201::UPNP_CONTROL_ACTION_REQUEST: SetSender. Params: <?xml version="1.0"? > <u:SetSender xmlns:u="urn:av-openhome-org:service:Receiver:1" > <Uri >ohz://239.255.255.250:51972/92e1ad7ef78ce405bb968c29818ed0a4</Uri > <Metadata ><DIDL-Lite xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/" xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/"><item id="0" restricted="True"><dc:title>ACER-PC</dc:title><res protocolInfo="ohz:_:_:u">ohz://239.255.255.250:51972/92e1ad7ef78ce405bb968c29818ed0a4</res><upnp:class>object.item.audioItem</upnp:class></item></DIDL-Lite></Metadata > /u:SetSender

src/ohreceiver.cxx:235::OHReceiver::setSender src/ohreceiver.cxx:244::OHReceiver::setSender: uri [ohz://239.255.255.250:51972/92e1ad7ef78ce405bb968c29818ed0a4] meta [<DIDL-Lite xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/" xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/" ><item id="0" restricted="True" >dc:titleACER-PC/dc:title<res protocolInfo="ohz:*:*:u" >ohz://239.255.255.250:51972/92e1ad7ef78ce405bb968c29818ed0a4</res >upnp:classobject.item.audioItem/upnp:class</item ></DIDL-Lite >] libupnpp/upnpplib.cxx:215::LibUPnP::o_callback: event type: UPNP_CONTROL_ACTION_REQUEST libupnpp/device/device.cxx:201::UPNP_CONTROL_ACTION_REQUEST: Play. Params: <?xml version="1.0"? > <u:Play xmlns:u="urn:av-openhome-org:service:Receiver:1" >/u:Play

src/ohreceiver.cxx:121::OHReceiver::play src/mpdcli.cxx:399::MPDCli::stop src/ohreceiver.cxx:157::OHReceiver::play: executing /usr/local/bin/sc2mpd src/ohreceiver.cxx:164::OHReceiver::play: sc2mpd pid 23675 libupnpp/upnpplib.cxx:215::LibUPnP::o_callback: event type: UPNP_CONTROL_ACTION_REQUEST libupnpp/device/device.cxx:201::UPNP_CONTROL_ACTION_REQUEST: VolumeDec. Params: <?xml version="1.0"? > <u:VolumeDec xmlns:u="urn:av-openhome-org:service:Volume:1" >/u:VolumeDec

libupnpp/upnpplib.cxx:215::LibUPnP::o_callback: event type: UPNP_CONTROL_ACTION_REQUEST libupnpp/device/device.cxx:201::UPNP_CONTROL_ACTION_REQUEST: VolumeDec. Params: <?xml version="1.0"? > <u:VolumeDec xmlns:u="urn:av-openhome-org:service:Volume:1" >/u:VolumeDec

libupnpp/upnpplib.cxx:215::LibUPnP::o_callback: event type: UPNP_CONTROL_ACTION_REQUEST libupnpp/device/device.cxx:201::UPNP_CONTROL_ACTION_REQUEST: VolumeDec. Params: <?xml version="1.0"? > <u:VolumeDec xmlns:u="urn:av-openhome-org:service:Volume:1" >/u:VolumeDec

libupnpp/upnpplib.cxx:215::LibUPnP::o_callback: event type: UPNP_CONTROL_ACTION_REQUEST libupnpp/device/device.cxx:201::UPNP_CONTROL_ACTION_REQUEST: VolumeInc. Params: <?xml version="1.0"? > <u:VolumeInc xmlns:u="urn:av-openhome-org:service:Volume:1" >/u:VolumeInc

libupnpp/upnpplib.cxx:215::LibUPnP::o_callback: event type: UPNP_CONTROL_ACTION_REQUEST libupnpp/device/device.cxx:201::UPNP_CONTROL_ACTION_REQUEST: VolumeInc. Params: <?xml version="1.0"? > <u:VolumeInc xmlns:u="urn:av-openhome-org:service:Volume:1" >/u:VolumeInc

It’s so wired, I’m not changed anything. same comptuer, same software, when I tried again, it suddenly work perfect. Now I’m curious about your multiroom function,waiting for you.O(∩_∩)O

Ok, I have an initial prototype for controlling multiple Songcast receivers. This is quite preliminary but it sort works… Be warned :)

The doc is here: http://lesbonscomptes.com/upmpdcli/scmulti.html

Hi, I have problem again, When I pull your latest git code, I tried to compile latest upmpdcli. This is compile error： scctl_src/scctl.cpp:90:5: error: ‘OHRCH’ does not name a type OHRCH rcv;

I have searched for definition of OHRCH, But I can’t find in libupnpp and openhome.

I think that maybe you forgot to update or install the libupnpp code. OHRCH is in there:

https://github.com/medoc92/libupnpp/blob/master/libupnpp/control/mediarenderer.hxx

Hi, I tried to play multiroom, and run umpdcli in two comptuer(upmpdcli friendlyname is master-audio and slave-audio). In my third computer I run songcast and select "master-audio"(friendlyname) to play, In my slave-audio computer I executed "scctl -s master-audio slave-audio", But There is no sound output from slave-audio. Maybe I do something wrong, Can you tell me How can I do with scctl. Thanks

Hi,

First thing is, the software is quite a bit unstable at the moment.

I have found a solution to obtain good synchronisation between the receivers (this is impossible when going through mpd), but I had to change quite a bit of code, and things are not really back to stability, I need a few more days, and as I won’t be around next week, this may mean end of May now. I need to write some doc too. When things work, they work well, and I really obtain excellent sync, but often everything falls apart and it’s a mess to restart. So good hope, but not right now.

So maybe, the best approach to not lose your time would be to put this aside for the moment.

If you want to give it a try anyway, what does:

say ?

I’ve fixed and pushed 2 bugs, and things appear more stable now. If you want to test, pull from the git repos (libupnpp/upmpdcli/sc2mpd).

I’ve implemented a mode where sc2mpd directly uses alsa to play. This is what allows good synchronisation. If you want to try this, you need to add the following to /etc/upmpdcli.conf:

Of course adjust the card name with something adequately chosen from aplay -L

I still have a bit of trouble with scctl from time to time. If you want to just try the playing, you can just execute the same command line on the slave which you see with ps on the master. Something like:

Just dup the uri from what you see on the master. You need to be in group audio to open the sound device, and then it should play…

Ok, I’ll try it. Thanks

2 fixes seem to have made things to stabilize, so I have uploaded a release and packages to the upmpdcli web site.

Hi, I have met new problem with upmpdcli. When I choose a receiver in Linn Songcast, it always in disconnected status and upmpdcli print "src/ohreceiver.cxx:195::OHReceiver: mpd mode: sc2mpd still not ready to play after 15 seconds"

This is a check I added. Previously, upmpdcli would get stuck forever waiting for sc2mpd if this never switched to the CONNECTED state. Now it generates an error after a reasonable time, and hopefully returns to a usable state.

Here is what I see in the upmpdcli log when I switch the Songcast app to the receiver:

(I shortened the source file paths).

I’m not too sure what may be happening for you. I suppose that you are using the latest github code for libupnpp, upmpdcli and sc2mpd (or the packages) ? My Windows Songcast version is 4.4.177

The latest code seems quite stable Can you please send fragments from the upmpdcli and sc2mpd logs at the time you try to switch the Receiver on ?

As it would seem that Songcast can connect to the receiver service, but that sc2mpd can’t connect to Songcast, one possibility would be to check for possible network or firewall issues, but I’m not too sure, because I’m not too sure what kind of problem would let UPnP through and not Songcast.

Hi, This is my log: src/mpdcli.cxx:405::MPDCli::stop src/ohreceiver.cxx:179::OHReceiver::play: executing /usr/local/bin/sc2mpd src/ohreceiver.cxx:186::OHReceiver::play: sc2mpd pid 12663 libupnpp/upnpplib.cxx:255::LibUPnP::o_callback: event type: UPNP_CONTROL_ACTION_REQUEST libupnpp/device/device.cxx:292::UPNP_CONTROL_ACTION_REQUEST: SetSender. Params: <?xml version="1.0"? > <u:SetSender xmlns:u="urn:av-openhome-org:service:Receiver:1" > <Uri >ohz://239.255.255.250:51972/92e1ad7ef78ce405bb968c29818ed0a4</Uri > <Metadata ><DIDL-Lite xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/" xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/"><item id="0" restricted="True"><dc:title>ACER-PC</dc:title><res protocolInfo="ohz:_:_:u">ohz://239.255.255.250:51972/92e1ad7ef78ce405bb968c29818ed0a4</res><upnp:albumArtURI>http://192.168.0.100:49253/icon</upnp:albumArtURI><upnp:class>object.item.audioItem</upnp:class></item></DIDL-Lite></Metadata > /u:SetSender

src/sc2mpd.cpp:440::scmpdcli: using subnet 192.168.0.0 src/ohreceiver.cxx:195::OHReceiver: mpd mode: sc2mpd still not ready to play after 15 seconds src/ohreceiver.cxx:230::OHReceiver::play: returning src/ohreceiver.cxx:276::OHReceiver::setSender libupnpp/upnpplib.cxx:255::LibUPnP::o_callback: event type: UPNP_CONTROL_ACTION_REQUEST libupnpp/device/device.cxx:292::UPNP_CONTROL_ACTION_REQUEST: SetSourceIndex. Params: <?xml version="1.0"? > <u:SetSourceIndex xmlns:u="urn:av-openhome-org:service:Product:1" > <Value >1</Value > /u:SetSourceIndex

src/ohproduct.cxx:216::OHProduct::setSourceIndex src/ohproduct.cxx:205::OHProduct::iSetSourceIndex: 1 src/ohreceiver.cxx:236::OHReceiver::iStop() src/mpdcli.cxx:405::MPDCli::stop src/ohplaylist.cxx:666::OHPlaylist::idArray (internal) src/ohplaylist.cxx:669::OHPlaylist::idArray: qvers 2 src/ohproduct.cxx:205::OHProduct::iSetSourceIndex: 0 libupnpp/device/device.cxx:410::UpnpDevice::notifyEvent urn:upnp-org:serviceId:RenderingControl LastChange src/avtransport.cxx:288::UpMpdAVTransport::getEventDataTransport: <Event xmlns="urn:schemas-upnp-org:metadata-1-0/AVT_RCS" > <InstanceID val="0" > <CurrentRecordQualityMode val="NOT_IMPLEMENTED"/ > <RecordMediumWriteStatus val="NOT_IMPLEMENTED"/ > <PossibleRecordStorageMedia val="NOT_IMPLEMENTED"/ > <RelativeCounterPosition val="0"/ > <CurrentTrackURI val="http://192.168.0.104:57645/external/audio/media/635010.mp3"/ > <TransportState val="STOPPED"/ > <PossibleRecordQualityModes val="NOT_IMPLEMENTED"/ > <CurrentTrack val="1"/ > <CurrentMediaDuration val="00:00:00"/ > <TransportPlaySpeed val="1"/ > <CurrentTransportActions val="Next,Previous,Play"/ > <TransportStatus val="OK"/ > <AVTransportURI val="http://192.168.0.104:57645/external/audio/media/635010.mp3"/ > <AbsoluteTimePosition val="0:00:00"/ > <NumberOfTracks val="1"/ > <CurrentTrackDuration val="00:00:00"/ > <CurrentPlayMode val="NORMAL"/ > <RelativeTimePosition val="0:00:00"/ > <PlaybackStorageMedium val="NONE"/ > <PossiblePlaybackStorageMedia val="HDD,NETWORK"/ > <AbsoluteCounterPosition val="0"/ > <RecordStorageMedium val="NOT_IMPLEMENTED"/ > </InstanceID > </Event >

It would be interesting to see the sc2cmd log too (the upmpdcli.conf parameters for sc2mpd are documented here: http://lesbonscomptes.com/upmpdcli/sc2mpd.html#Configuration

Otherwise, you can try to activate Songcast on Windows, and start sc2mpd by hand on the Receiver. Command line (based on the uri value in the log you sent):

Hi, Thank for your help, I have get my multiroom worked, But it’s sound like lost sound data, sometimes no sound out, Does it because of udp protocol transfer data, So can’t to avoid this problem?

Did you set up sc2mpd to play through mpd or direct through alsa ?

Le 13 mai 2015 03:07:13 CEST, maosuyun2009 notifications@github.com a écrit :

##

Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.

Play through alsa

Did you try multicast ? It is a parameter In the songcast advanced panel.

Le 13 mai 2015 10:11:23 CEST, maosuyun2009 notifications@github.com a écrit :

##

Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.

Yes, I use multicast in the songcast advanced panel. I have little curious, audio data is transfer throug udp protocol, But udp is a unreliable protocol, How can guarantee not lost audio data when transfer with wifi (easily lost data)

I think that Songcast has some limited ability to ask for retransmit of some audio buffers. But in any case, as it is a real time protocol, any serious amount of retransmission is going to break the synchronisation, and is not in the spirit of the thing. Esp. TCP retransmission of lost packets would cause unacceptable delays in many cases I suspect.

For glitch-free audio, your wifi link needs to be reasonably reliable (meaning: able to transmit at a significantly higher rate than the audio rate), and any serious drops in the link will be audible, I’m afraid that there is not much which can be done about it.

Hi,

I spent most of the day pulling my hair about WIFI issues. Tried with rasp1, no go, rasp2 still no go, macbook pro, same issue…

Actually the answer was simple: many WIFI access points don’t support multicast well. As soon as I switched to unicast, the problems went away, I guess that it will be the same for you.

This is very counterintuitive and seems wasteful, but I don’t think that there is a way around the issue, except maybe for trying other access points. See this link for details: http://superuser.com/questions/730288/why-do-some-wifi-routers-block-multicast-packets-going-from-wired-to-wireless

Thank you answer my quetion, Now i know it.