I use the curl commands to control some behaviour of my players. For instance, I switch them off automatically when I leave my home.

I have also set up the players through BubblUpnp Server to get integrated support for Tidal and Qobuz.

Since the players run through BubbleUpnp, I have lost the possibility to use the curl command to switch the players off. Also, in Kazoo the player will always show as ON (power icon not greyed), even though the player is OFF.

This is the curl command I use to switch off the player:

curl -m 4 http://minidsi.local:80/myapp/mediaplayer/setStandbyMode?value=true

When I issue this command, the player will not switch off but will move to the next track.

Is there any solution?

Hi Guus,

Which version of MediaPlayer are you using?

I test with my latest version (v0.0.9.3) and when using the RESTFul api to toggle standby mode the mediaplayer is sending teh StandBy Devent to the ProductProvider as it should be doing.

Snap 2019-03-16 at 15 35 48

However, when using the Windows version of Kazoo this does not update the status of the standby button, but the iPhone button is working as expected, so I suspect there is an issue with Kazoo Windows, which version of Kazoo are you using?

Thanks,

Pete.

Hi Pete,

Thanks for coming back so quickly!

I have checked a few things and also installed the latest version of MediaPlayer.

Please note that the mediaplayer.jar file in com.upnp.mediaplayer/download/beta has a different time stamp from the one in the zip file in the same directory. I have tried both.

Both versions indicate 0.0.9.3 in the web page. This is also the version that was running before I reported my issue, so I assume it's the latest version. I have also updated the mediaplayer_lib directory.

I still get the same behaviour:

1) icon not greyed out when player is off (both Kazoo Mac and Kazoo iOS, both latest versions) 2) the curl command moves the player to the next song instead of stopping the player

Below is my app.properties file. Note that AVTransport is ON, because otherwise the player does not show up in BubbleUpnpServer.

And this is the output of mediaplayer.log when I send the curl, so it is registered as a Standby instruction.

2019-03-17 15:31:38,074 [Thread-2] DEBUG [org.rpi.providers.PrvAVTransport] GetTransport Info Adapter: 192.168.1.35 uriPrefix: http://192.168.1.35:52821/device-MiniDSi-MiniDSi-MediaRenderer/Upnp/resource/ Version:1 2019-03-17 15:31:38,629 [Grizzly-worker(2)] DEBUG [org.rpi.web.rest.MediaPlayerRest] Setting StandbyMode: true 2019-03-17 15:31:40,092 [Thread-3] DEBUG [org.rpi.providers.PrvAVTransport] GetTransport Info Adapter: 192.168.1.35 uriPrefix: http://192.168.1.35:52821/device-MiniDSi-MiniDSi-MediaRenderer/Upnp/resource/ Version:1 Best wishes, Guus

Modified Using the Web Page

Wed Jun 20 10:33:42 CEST 2018

airplay_audio_start_delay=true airplay_enabled=true airplay_latency_enabled=true airplay_master_volume_enabled=true airplay_port=5002 java_sound_software_mixer_enabled=false java_soundcard_suffix=[PLUGHW\:0,0]--PRIMARY SOUND DRIVER log_console_level=debug log_file_level=info log_file_name=mediaplayer.log mediaplayer_enable_avTransport=true mediaplayer_enable_receiver=true mediaplayer_friendly_name=MiniDSi mediaplayer_max_volume=70 mediaplayer_player=mpd mediaplayer_playlist_max=1000 mediaplayer_save_local_playlist=true mediaplayer_startup_volume=30 mpd_host=localhost mpd_port=6600 mpd_preload_timer=3 mplayer_cache_min=80 mplayer_cache_size=520 mplayer_path=/usr/bin/mplayer mplayer_playlist=asx,b4s,kpl,m3u,pls,ram,rm,smil,wax,wvx openhome_log_level=Error openhome_port=52821 songcast_latency_enabled=true web_server_enabled=true web_server_port=80

Hi Guus,

Can you show me the rest of the log file after the Standby request.

When you say it skips to the next song after the standby request, is that when playing a Tidal/Quboz playlist or a standard playlist or radio?

Does it still skip to the next track if you are playing a standard playlist/radio?

Thanks,

Pete.

Hi Pete,

I will answer coming weekend. I am currently travelling.

Greetings, Guus

Hi Pete,

Log file attached.

Skipping occurs both with Qobuz and standard playlist (local files).

Thanks, Guus

mediaplayer.log

Hi Guus,

Looking at the log file it seems that you are using v0,0.9.1

The strange thing is when I test in my environment, the MediaPlayer receives the SetStanby request from Kazoo, and then stops the track playing and

2019-04-01 16:38:18,233 [Thread-7] DEBUG [org.rpi.providers.PrvProduct] SetStandby: true Adapter: 192.168.1.181 uriPrefix: http://192.168.1.181:52821/device-Garden-rpigarden-MediaRenderer/Upnp/resource/ Version:1 2019-04-01 16:38:19,229 [Thread-0] DEBUG [org.rpi.mpdplayer.StatusMonitor] Status Changed From : Playing To: Stopped 2019-04-01 16:38:19,229 [Thread-0] DEBUG [org.rpi.mpdplayer.MPDPlayer] Status Changed: Stopped 2019-04-01 16:38:19,229 [Thread-0] DEBUG [org.rpi.player.PlayManager] EventStatusChanged: Stopped 2019-04-01 16:38:19,229 [Thread-0] DEBUG [org.rpi.player.PlayManager] SetStatus: Stopped 2019-04-01 16:38:19,230 [Thread-0] DEBUG [org.rpi.providers.PrvAVTransport] Status: Stopped

And in your log file, MediaPlayer stops playing the track, but it seems as though something, probably the ControlPoint is then telling MediaPlayer to play the next track:

The MediaPlayer receives the Standby Request, it stops playing the track:

2019-03-31 18:17:17,825 [Grizzly-worker(4)] DEBUG [org.rpi.web.rest.MediaPlayerRest] Setting StandbyMode: true 2019-03-31 18:17:17,863 [Thread-3] DEBUG [org.rpi.providers.PrvAVTransport] Get Position Info Adapter: 192.168.1.11 uriPrefix: http://192.168.1.11:52821/device-Classik-Classik-MediaRenderer/Upnp/resource/ Version:1 2019-03-31 18:17:17,880 [Thread-6] DEBUG [org.rpi.providers.PrvAVTransport] GetTransport Info Adapter: 192.168.1.11 uriPrefix: http://192.168.1.11:52821/device-Classik-Classik-MediaRenderer/Upnp/resource/ Version:1 2019-03-31 18:17:18,600 [Thread-0] DEBUG [org.rpi.mpdplayer.StatusMonitor] Status Changed From : Playing To: Stopped 2019-03-31 18:17:18,601 [Thread-0] DEBUG [org.rpi.mpdplayer.MPDPlayer] Status Changed: Stopped 2019-03-31 18:17:18,601 [Thread-0] DEBUG [org.rpi.player.PlayManager] EventStatusChanged: Stopped 2019-03-31 18:17:18,601 [Thread-0] DEBUG [org.rpi.player.PlayManager] SetStatus: Stopped 2019-03-31 18:17:18,602 [Thread-0] DEBUG [org.rpi.providers.PrvAVTransport] Status: Stopped

But, something (Control Point?) is still requesting the Position of the Track

2019-03-31 18:17:18,605 [Thread-7] DEBUG [org.rpi.providers.PrvAVTransport] Get Position Info Adapter: 192.168.1.11 uriPrefix: http://192.168.1.11:52821/device-Classik-Classik-MediaRenderer/Upnp/resource/ Version:1 2019-03-31 18:17:19,520 [Thread-5] DEBUG [org.rpi.providers.PrvAVTransport] Get Position Info Adapter: 192.168.1.11 uriPrefix: http://192.168.1.11:52821/device-Classik-Classik-MediaRenderer/Upnp/resource/ Version:1 2019-03-31 18:17:19,892 [Thread-3] DEBUG [org.rpi.providers.PrvAVTransport] Get Position Info Adapter: 192.168.1.11 uriPrefix: http://192.168.1.11:52821/device-Classik-Classik-MediaRenderer/Upnp/resource/ Version:1 2019-03-31 18:17:19,906 [Thread-6] DEBUG [org.rpi.providers.PrvAVTransport] GetTransport Info Adapter: 192.168.1.11 uriPrefix: http://192.168.1.11:52821/device-Classik-Classik-MediaRenderer/Upnp/resource/ Version:1 2019-03-31 18:17:19,920 [Thread-7] DEBUG [org.rpi.providers.PrvAVTransport] Get Position Info Adapter: 192.168.1.11 uriPrefix: http://192.168.1.11:52821/device-Classik-Classik-MediaRenderer/Upnp/resource/ Version:1

Some client/Control Point then sends a SetNextAVTransport request!

2019-03-31 18:17:19,940 [Thread-5] DEBUG [org.rpi.providers.PrvAVTransport] SetNexAVTransport: 0 Adapter: 192.168.1.11 uriPrefix: http://192.168.1.11:52821/device-Classik-Classik-MediaRenderer/Upnp/resource/ Version:1

MediaPlayer then starts to load the next track because it received the SetNextAVTransport request

2019-03-31 18:17:19,940 [Thread-5] DEBUG [org.rpi.player.PlayManager] Set Next AV Track :
2019-03-31 18:17:19,940 [Thread-5] DEBUG [org.rpi.mpdplayer.MPDPlayer] PreLoad Next Track: 2019-03-31 18:17:19,940 [Thread-5] ERROR [org.rpi.radio.parsers.FileParser] java.net.MalformedURLException: no protocol: 2019-03-31 18:17:19,941 [Thread-5] ERROR [org.rpi.mpdplayer.TCPConnector] Error: ACK [50@0] {addid} Not found 2019-03-31 18:17:19,961 [Thread-3] DEBUG [org.rpi.providers.PrvAVTransport] Stop: 0 Adapter: 192.168.1.11 uriPrefix: http://192.168.1.11:52821/device-Classik-Classik-MediaRenderer/Upnp/resource/ Version:1 2019-03-31 18:17:19,981 [Thread-6] DEBUG [org.rpi.providers.PrvAVTransport] GetTransport Info Adapter: 192.168.1.11 uriPrefix: http://192.168.1.11:52821/device-Classik-Classik-MediaRenderer/Upnp/resource/ Version:1 2019-03-31 18:17:20,063 [Thread-7] DEBUG [org.rpi.providers.PrvAVTransport] SetAVTransport: 0 URL: http://192.168.1.14:9790/minimserver/*/Music/ALAC/Musica*20Nuda/Musica*20Nuda*20-*2055*2021*20(2008)/02*20Musica*20Nuda*20-*20Si*20Viaggiare.m4a MetaData: object.item.audioItem.musicTrack</upnp:class>Si Viaggiare</dc:title>Musica Nuda</dc:creator>Musica Nuda</upnp:artist>http://192.168.1.14:9790/minimserver/*/Music/ALAC/Musica*20Nuda/Musica*20Nuda*20-*2055*2021*20(2008)/02*20Musica*20Nuda*20-*20Si*20Viaggiare.m4a/$!picture-12724-95049.jpg?connection=close</upnp:albumArtURI>Musical</upnp:genre>2008-01-01</dc:date>55\21</upnp:album>http://192.168.1.14:9790/minimserver/*/Music/ALAC/Musica*20Nuda/Musica*20Nuda*20-*2055*2021*20(2008)/02*20Musica*20Nuda*20-*20Si*20Viaggiare.m4a Adapter: 192.168.1.11 uriPrefix: http://192.168.1.11:52821/device-Classik-Classik-MediaRenderer/Upnp/resource/ Version:1 2019-03-31 18:17:20,177 [Thread-5] DEBUG [org.rpi.providers.PrvAVTransport] Play: 1 Adapter: 192.168.1.11 uriPrefix: http://192.168.1.11:52821/device-Classik-Classik-MediaRenderer/Upnp/resource/ Version:1 2019-03-31 18:17:20,180 [Thread-5] DEBUG [org.rpi.channel.ChannelPlayList] object.item.audioItem.musicTrack</upnp:class>Si Viaggiare</dc:title>Musica Nuda</dc:creator>Musica Nuda</upnp:artist>http://192.168.1.14:9790/minimserver/*/Music/ALAC/Musica*20Nuda/Musica*20Nuda*20-*2055*2021*20(2008)/02*20Musica*20Nuda*20-*20Si*20Viaggiare.m4a/$!picture-12724-95049.jpg?connection=close</upnp:albumArtURI>Musical</upnp:genre>2008-01-01</dc:date>55\21</upnp:album>http://192.168.1.14:9790/minimserver/*/Music/ALAC/Musica*20Nuda/Musica*20Nuda*20-*2055*2021*20(2008)/02*20Musica*20Nuda*20-*20Si*20Viaggiare.m4a 2019-03-31 18:17:20,186 [Thread-5] DEBUG [org.rpi.player.PlayManager] Play AV Track : http://192.168.1.14:9790/minimserver/*/Music/ALAC/Musica*20Nuda/Musica*20Nuda*20-*2055*2021*20(2008)/02*20Musica*20Nuda*20-*20Si*20Viaggiare.m4a

Because the track is playing MediaPlayer takes itself out of Standby Mode

2019-03-31 18:17:20,187 [Thread-5] DEBUG [org.rpi.player.PlayManager] We are playing a Channel, take out of Standby

Can you describe the environment you have configured, so that I can better understand what is happening? Are you using Kazoo, is there anything else that controls/integrates with MediaPlayer?

Hi Pete,

Here is a lot more info. I have finally managed to set up a system that allows me to check what's happening, more or less.

The configuration is the following:

normal operation of the MediaPlayer through Kazoo (only control point). This also allows me to put Mediaplayer in Standby. I may have misreported this previously. So Kazoo is working as expected. below is the SOAPACTION call information which I have been able to capture with Wireshark.

`¸'ëvô$ ×E|@@´ëÀ¨À¨-ø«ÎU+ôÐG{à( ì

òïñ+POST /device-MiniDSi-MiniDSi-MediaRenderer/av.openhome.org-Product-1/control HTTP/1.0 Host: 192.168.1.45:52821 Content-Length: 284 Content-Type: text/xml; charset="utf-8" User-Agent: Linn Kazoo/4.13.40.0 (MacOsX (Unix 18.5.0.0)) SOAPACTION: "urn:av-openhome-org:service:Product:1#SetStandby"

<?xml version="1.0"?>

</u:SetStandby> </s:Body> </s:Envelope> `

in the context of my home automation, I try to control MediaPlayer through API calls, so independent of Kazoo. The main application is to switch all players off when leaving the house or going to bed. This is where things go wrong. The player is apparently put into StandBy, but something is restarting it or at least advancing the track. So I am not able to put the player in StandBy with a curl command. Here is the network capture:

`GET call through curl - this advances the track ¸'ëvô$ ×E¬@@¶»À¨À¨-ÁPñým)F ¼Þ ?ò-ôHGET /myapp/mediaplayer/setStandbyMode?value=true HTTP/1.1 Host: minidsi.local User-Agent: curl/7.54.0 Accept: /

Response to GET call ô$ ×¸'ëvE³@@½À¨-À¨PÁým)FñÅµÝ ôO?ò-HTTP/1.1 200 OK Content-Type: text/plain Date: Thu, 30 May 2019 14:33:15 GMT Content-Length: 2 OK `

So it seems that, in case MediaPlayer is put in Standby independently from Kazoo, Kazoo somehow doesn't recognise the shutdown and tries to keep playing. Perhaps misinterpreting the instruction?

I have been playing around with SOAPACTION Webhooks, but never managed to get that working. Even the Linn people suggest that I use other methods.

I am trying to control the players from a Particle.io device. This allows me to create WebHooks and in principle I should be able to control Mediaplayer through it. But it does not work. Webhooks only work with public IP addresses, not with local ones.

I have tried a local TCP connection as per below, but it doesn't work:

if(client.connect(minidsiip, 80)) { client.println("http://minidsi.local:80/myapp/mediaplayer/setStandbyMode?value=true"); client.println(); delay(100); return 1; } else { return 0; } client.flush(); client.stop(); }

I have tried the same url in the iOS Shortcuts app, which should in principle provide very easy integration with Siri and would make it possible to control any MediaPlayer by voice. This works but only advances the track, so far (as expected at this stage). Return message OK.

When I plug that url into a browser, it also works (to advance the track ;-)). Return message OK.

Hope this helps to further identify the problem. Any suggestion on how to get the call to work on the Particle device would also be appreciated.

Thanks, Guus

Hi Guus,

Sorry about the delay, I've been on holiday.

I tested your scenario and for me it works, I started a track playing using Kazoo control point, I then used Chrome with the URL http://rpistudy:8088/myapp/mediaplayer/setStandbyMode?value=true

And the track stops playing, it did not move to the next track. Attached is the log file from my test.

################################ 2019-06-11 10:17:24,667 [Thread-0] DEBUG [org.rpi.mpdplayer.StatusMonitor] Status Changed From : Stopped To: Playing 2019-06-11 10:17:24,667 [Thread-0] DEBUG [org.rpi.mpdplayer.MPDPlayer] Status Changed: Playing 2019-06-11 10:17:24,667 [Thread-0] DEBUG [org.rpi.player.PlayManager] EventStatusChanged: Playing 2019-06-11 10:17:24,667 [Thread-0] DEBUG [org.rpi.player.PlayManager] SetStatus: Playing 2019-06-11 10:17:24,671 [Thread-0] DEBUG [org.rpi.providers.PrvAVTransport] Status: Playing 2019-06-11 10:17:41,480 [grizzly-http-server-0] DEBUG [org.rpi.web.rest.MediaPlayerRest] Setting StandbyMode: true 2019-06-11 10:17:41,480 [grizzly-http-server-0] DEBUG [org.rpi.providers.PrvProduct] update: org.rpi.player.events.EventStandbyChanged@8da0b3 2019-06-11 10:17:41,481 [grizzly-http-server-0] DEBUG [org.rpi.providers.PrvProduct] updateStandby: true 2019-06-11 10:17:41,696 [Thread-0] DEBUG [org.rpi.mpdplayer.StatusMonitor] Status Changed From : Playing To: Stopped 2019-06-11 10:17:41,697 [Thread-0] DEBUG [org.rpi.mpdplayer.MPDPlayer] Status Changed: Stopped 2019-06-11 10:17:41,697 [Thread-0] DEBUG [org.rpi.mpdplayer.MPDPlayer] PETE Stopped Got Here: true 2019-06-11 10:17:41,697 [Thread-0] DEBUG [org.rpi.player.PlayManager] EventStatusChanged: Stopped 2019-06-11 10:17:41,697 [Thread-0] DEBUG [org.rpi.player.PlayManager] SetStatus: Stopped 2019-06-11 10:17:41,698 [Thread-0] DEBUG [org.rpi.providers.PrvAVTransport] Status: Stopped ################################

When you did your test did you see anything in the wireshark trace that would cause the mediaplayer to start the next track?

Try installing the latest version of MediaPlayer, I've made some changes to the stop mechanism, I've also added TuneIn support and Pins support for TuneIn and Kazoo Server. If upgrading it is best to delete the content of the mediaplayer_lib directory because I've upgraded some of the third party jar files.

If your Particle.io needs to use a public IP Address then you would need to: If you don't have a fixed public Ip Address you would some kind of Dynamic Domain Name Service, my router is an ASUS router so I use their own DDNS. You would also need to enable port forwarding on your router to your mediaplayer(s) web server port.

This should allow access from a public ip address to your mediaplayer Restful API.

Thanks,

Pete.

On Thu, 30 May 2019 at 16:47, guussie notifications@github.com wrote:

Hi Pete,

Here is a lot more info. I have finally managed to set up a system that allows me to check what's happening, more or less.

The configuration is the following:

normal operation of the MediaPlayer through Kazoo (only control point). This also allows me to put Mediaplayer in Standby. I may have misreported this previously. So Kazoo is working as expected. below is the SOAPACTION call information which I have been able to capture with Wireshark.

`¸'ëvô$ ×E|@@´ëÀ¨À¨-ø«ÎU+ôÐG{à( ì

òïñ+POST /device-MiniDSi-MiniDSi-MediaRenderer/av.openhome.org-Product-1/control HTTP/1.0 Host: 192.168.1.45:52821 Content-Length: 284 Content-Type: text/xml; charset="utf-8" User-Agent: Linn Kazoo/4.13.40.0 (MacOsX (Unix 18.5.0.0)) SOAPACTION: "urn:av-openhome-org:service:Product:1#SetStandby"

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> 1 </u:SetStandby> </s:Body> </s:Envelope> `

in the context of my home automation, I try to control MediaPlayer through API calls, so independent of Kazoo. The main application is to switch all players off when leaving the house or going to bed. This is where things go wrong. The player is apparently put into StandBy, but something is restarting it or at least advancing the track. So I am not able to put the player in StandBy with a curl command. Here is the network capture:

`GET call through curl - this advances the track ¸'ëvô$ ×E¬@@¶»À¨À¨-ÁPñým)F ¼Þ ?ò-ôHGET /myapp/mediaplayer/setStandbyMode?value=true HTTP/1.1 Host: minidsi.local User-Agent: curl/7.54.0 Accept: /

Response to GET call ô$ ×¸'ëvE³@@½À¨-À¨PÁým)FñÅµÝ ôO?ò-HTTP/1.1 200 OK Content-Type: text/plain Date: Thu, 30 May 2019 14:33:15 GMT Content-Length: 2 OK `

So it seems that, in case MediaPlayer is put in Standby independently from Kazoo, Kazoo somehow doesn't recognise the shutdown and tries to keep playing. Perhaps misinterpreting the instruction?

I have been playing around with SOAPACTION Webhooks, but never managed to get that working. Even the Linn people suggest that I use other methods.

I am trying to control the players from a Particle.io device. This allows me to create WebHooks and in principle I should be able to control Mediaplayer through it. But it does not work. Webhooks only work with public IP addresses, not with local ones.

I have tried a local TCP connection as per below, but it doesn't work:

if(client.connect(minidsiip, 80)) { client.println(" http://minidsi.local:80/myapp/mediaplayer/setStandbyMode?value=true"); client.println(); delay(100); return 1; } else { return 0; } client.flush(); client.stop(); }

I have tried the same url in the iOS Shortcuts app, which should in principle provide very easy integration with Siri and would make it possible to control any MediaPlayer by voice. This works but only advances the track, so far (as expected at this stage). Return message OK.

When I plug that url into a browser, it also works (to advance the track ;-)). Return message OK.

Hope this helps to further identify the problem. Any suggestion on how to get the call to work on the Particle device would also be appreciated.

Thanks, Guus

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/PeteManchester/MediaPlayer/issues/77?email_source=notifications&email_token=AA5RVJZP7KE6RCX7XMACJ3DPX7ZHTA5CNFSM4G663WB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWSWGLY#issuecomment-497378095, or mute the thread https://github.com/notifications/unsubscribe-auth/AA5RVJ5DPOHJFPNKYOTFZY3PX7ZHTANCNFSM4G663WBQ .

Hello Pete,

No problem. I've been away too, and will be again soon.

I think I am getting to the origin of the problem. In my initial post I mentioned that I am using BubbleUpNP. This is to give me Tidal and Qobuz functionality.

Without the Bubble UpNP server active, MediaPlayer functions as expected and I can switch it off the way it should and the way you test it. But when I activate Bubble UpNP, the problems described occur.

I have updated MediaPlayer on one of my players with the latest version. This doesn't change the behaviour, but I don't get pin and TuneIn support so maybe I did not change all the files as necessary. I will check that later.

So I think the problem is somehow with the Bubble UpNP Server integration. Perhaps Bubble corrects some of the actions.

I don't have time to check with WireShark until a few weeks from now. But will report when I do.

If you have added pin and TuneIn support, would it be feasible to somehow also add Qobuz and Tidal support, like in Bubble UpNP? That way Bubble would not be needed and MediaPlayer would function as expected.

I will be able to continue trying in July.

Thanks, Guus

That is interesting about Bubble UpNP..

I knew you would ask about Tidal and Quboz support :-) ,I don't have any plans yet to add Tidal or Quboz support.

I will send you an email about Pins and TuneIn support..

On Tue, 11 Jun 2019 at 22:28, guussie notifications@github.com wrote:

Hello Pete,

No problem. I've been away too, and will be again soon.

I think I am getting to the origin of the problem. In my initial post I mentioned that I am using BubbleUpNP. This is to give me Tidal and Qobuz functionality.

Without the Bubble UpNP server active, MediaPlayer functions as expected and I can switch it off the way it should and the way you test it. But when I activate Bubble UpNP, the problems described occur.

I have updated MediaPlayer on one of my players with the latest version. This doesn't change the behaviour, but I don't get pin and TuneIn support so maybe I did not change all the files as necessary. I will check that later.

So I think the problem is somehow with the Bubble UpNP Server integration. Perhaps Bubble corrects some of the actions.

I don't have time to check with WireShark until a few weeks from now. But will report when I do.

If you have added pin and TuneIn support, would it be feasible to somehow also add Qobuz and Tidal support, like in Bubble UpNP? That way Bubble would not be needed and MediaPlayer would function as expected.

I will be able to continue trying in July.

Thanks, Guus

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/PeteManchester/MediaPlayer/issues/77?email_source=notifications&email_token=AA5RVJZ3OOSABKVWZVZ743TP2AKJRA5CNFSM4G663WB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXOR2FA#issuecomment-501030164, or mute the thread https://github.com/notifications/unsubscribe-auth/AA5RVJZ5NTQP6ZD6YLIBU2TP2AKJRANCNFSM4G663WBQ .

Bubble UpNP takes care of Qobuz and Tidal quite well, so no need for you to integrate it. It just requires and additional machine to fund the server.

But somehow adding Bubble in the chain seems to distort the signaling.

I don't think Bubble is open source, but I can try to check with the author.

PeteManchester / MediaPlayer

Problem with curl command when player set up through BubbleUpnp server #77

Modified Using the Web Page

Wed Jun 20 10:33:42 CEST 2018