Issue 1

Hi,

BubbleUPnP dev here.

Congrat for this new mpd based renderer.

For the volume issue, it seems upmpdcli always return 0 for the volume, both through GetVolume() and the Volume variable eventing. This is not specific to BubbleUPNP as it also return 0 with the Device Spy tool on Windows.

Setting the volume with BubbleUPNP (and other Control Points) always fails with "server error: 52"

I’m running the latest git version, compiled on Ubuntu 12.04 32 bits, using mpd 0.16.5.

Hi,

Getting in touch was on my TODO anyway :)

About the "0" volume, I think that I know what’s happening: mpd does not return a volume when it’s not playing or paused. I need to cache/fake a volume in this situation. I’ll try this, and see if I get a control then.

About error 52, don’t know what this is, I’ll check. But volume control does work in general, for example, with audionet or upnp-inspector. I’ll take a better look anyway.

upmpdcli also seem to return Mute=1 (associated to Volume 0). In BubbleUPnP, when you change volume with hardware volume buttons, this trigger SetMute(0), followed by SetVolume(x) which fails:

libupnpp/device.cxx:169::UPNP_CONTROL_ACTION_REQUEST: SetMute. Params: <?xml version="1.0"? > <u:SetMute xmlns:u="urn:schemas-upnp-org:service:RenderingControl:1" > <InstanceID >0</InstanceID > <Channel >Master</Channel > <DesiredMute >0</DesiredMute > /u:SetMute

upmpd/mpdcli.cxx:233::MPDCli::setVolume: vol 1 isMute 1 upmpd/mpdcli.cxx:239::MPDCli::setVolume: restoring premute 0 upmpd/mpdcli.cxx:94::mpd_run_set_volume(M_CONN, volume) failed: problems setting volume upmpd/mpdcli.cxx:97::mpd_run_set_volume(M_CONN, volume) server error: 52 libupnpp/device.cxx:169::UPNP_CONTROL_ACTION_REQUEST: SetVolume. Params: <?xml version="1.0"? > <u:SetVolume xmlns:u="urn:schemas-upnp-org:service:RenderingControl:1" > <InstanceID >0</InstanceID > <Channel >Master</Channel > <DesiredVolume >0</DesiredVolume > /u:SetVolume

I tried with UPnPlay and volume control doesn’t work either.

The errors that you are seeing (problems setting volume and server error:52) are actually coming from mpd, I believe that you should see an error message about volume control with another mpd client such as mpc. I think that you should try to restart mpd and check that volume settting works with a native mpd client. Maybe something got in a funny state.

Otherwise, I have fixed the code to return a cached volume value when mpd is not playing, and I’m seeing something strange: - With Bubble UPnP running on a Nexus 7, I have no volume slider at all (so can’t test setting the volume …) - With Bubble UPnP running in a VirtualBox intel Android, I do have a volume control and setting the volume does work.

The new code is on GitHub.

The primary volume control in BubbleUPNP is hardware volume buttons.

It looks like it was an mpd issues after all: I switched from ALSA output to PulseAudio (in /etc/mpd.conf) and now it works perfectly fine (using your latest code). So it was a weird ALSA/mpd issue with volume always returning muted/Volume=0 no matter what and giving that "error 52" message.

I’ve seen mpd have volume control trouble a number of times actually, so I would like to understand, and I’ll keep it under surveillance.

Ok, the 3rd time I read the phrase about the hardware volume buttons I got it. Not the buttons on the stereo receiver, those on the phone :) Works perfectly ok now, I’ll fix the web page. Not convinced it’s very natural when the music is not playing on the mobile device though, but it’s mostly a question of taste.

You can enable the volume slider in Settings > Now Playing > Show volume slider. By default, it is enabled only on tablets. You also have Vol- / Vol+ buttons in the notification area and in widgets.

Unrelated to this issue, but I would be nice if the renderer implemented ConnectionManager::GetProtocolInfo(), returning the list of supported protocolInfos (eg mime-types). Many Control Points use it to determine what a renderer supports and select an appropriate stream to play. You can try it on the BubbleUPnP renderer to have an idea of the output.

Thanks, seriously, I should have guessed it, but I’m not too familiar with mobile devices. By the way, the control did not appear by default on the Nexus 7, a tablet.

I’ll look at the ConnectionManager service when I get back from holidays, the week after next. Also I need to stop making up the protocolinfo and DLNA stuff which I return in TrackMetadata fields, somebody will eventually see it :) Next week.