It should fail once or twice when in multiroom mode. The system can’t connect to the slave device and fails. Does it work if you wait a bit?
I’ve added some error handling to fix your previous problem with Title not being in hex format. Could you download the latest version and test?
Could you try to execute http://<your_ip>/httpapi.asp?command=multiroom:getSlaveList on your devices and post the output? It seems as if your devices behave quite differently from mine in a number of ways 
Never tryed to have them on multiroom mode.
{ “slaves”: 0 } is the output on command=multiroom:getSlaveList
Nothing changed regarding cover and info from TuneIn. The cover remains until restart.
Forgot to mention… the link for testing TuneIn cover i used is https://github.com/nicjo814/home-assistant/blob/noiuri/homeassistant/components/media_player/linkplay.py
Is this correct?
That’s the one to use. Does the cover art change if you change tunein station?
Yes, it does.
malinduta,
Thank you for your work.
BTW, just for inform you: on my HA this script regularly write this error to log:
2019-02-15 12:51:26 ERROR (MainThread) [homeassistant.helpers.entity] Update for media_player.kolonki_na_kukhne fails
Traceback (most recent call last):
File “/usr/local/lib/python3.6/site-packages/homeassistant/helpers/entity.py”, line 221, in async_update_ha_state
await self.async_device_update()
File “/usr/local/lib/python3.6/site-packages/homeassistant/helpers/entity.py”, line 349, in async_device_update
await self.hass.async_add_executor_job(self.update)
File “/usr/local/lib/python3.6/concurrent/futures/thread.py”, line 56, in run
result = self.fn(*self.args, **self.kwargs)
File “/config/custom_components/media_player/linkplay.py”, line 647, in update
if upnpclient.Device(entry.location).friendly_name ==
File “/usr/local/lib/python3.6/site-packages/upnpclient/upnp.py”, line 105, in init
headers=self.http_headers
File “/usr/local/lib/python3.6/site-packages/requests/api.py”, line 75, in get
return request(‘get’, url, params=params, **kwargs)
File “/usr/local/lib/python3.6/site-packages/requests/api.py”, line 60, in request
return session.request(method=method, url=url, **kwargs)
File “/usr/local/lib/python3.6/site-packages/requests/sessions.py”, line 519, in request
prep = self.prepare_request(req)
File “/usr/local/lib/python3.6/site-packages/requests/sessions.py”, line 462, in prepare_request
hooks=merge_hooks(request.hooks, self.hooks),
File “/usr/local/lib/python3.6/site-packages/requests/models.py”, line 313, in prepare
self.prepare_url(url, params)
File “/usr/local/lib/python3.6/site-packages/requests/models.py”, line 387, in prepare_url
raise MissingSchema(error)
requests.exceptions.MissingSchema: Invalid URL ‘192.168.1.100’: No schema supplied. Perhaps you meant http://192.168.1.100?
and speakers not on 192.168.1.100 — they has another IP-address
All credits go to @ nicjo814. It is his work, not mine.
I also get some non important logs related to linkplay when not using the speakers for few days. When using them, it is working great!
Thank you nicjo814! 
1 Like
hey,
I’m new to the HA thing and trying to get this working, but keep getting this error: Platform not found: media_player.linkplay when checking the config, any assistance to what I’m doing wrong would be great.
I’ve updated the code to fix the issue with media info not changing when you go from TuneIn to webradio. Could you download from the same link as before and report back if it’s working?
Hi,
Could you please post your linkplay configuration from the configuration.yaml file? Looks like maybe some things are missing there…
Hi,
You need to create the folder “custom_components/media_player” in your HA config folder. The location of your HA config folder varies by OS so I’m not sure where yours are. Within this new folder you need to place the linkplay.py file linked to in post
Let me know how it goes.
- platform: linkplay
name: Колонки на кухне
host: !secret speaker_kitchen_host
# Media
speaker_kitchen_host: 192.168.1.80
That’s all
Yes, working as expected!
Once again, thank you for your work and for your time!
Ok, I’d like to try two things to see if your problem goes away. First I would like you to make sure that the name you’ve specified for the device in the configuration file is exactly the same as in your “companion app” that you control the speaker with from Android/iOS. Next the name in the configuration might need quotes surrounding the name like ‘Колонки на кухне’. Finally if you could disable the !secret when testing and just enetering the IP directly in the host section. Not sure if any of this will work, but it could be worth a test Is anything working for you from within HA?
EDIT: I’ve pushed a new version of the component that should catch the exception being thrown in your error log. Could you give it a try?
No worries, glad I could make it work. Would you be interested in trying out multiroom too? It will probably crash and throw lots of errors
Thank you for your support.
I have completed all your recommendations and installed the latest version of the script. Errors are no longer repeated.
Then I gradually changed the configs to my previous version.
The main thing that I understood is that the name of the speaker in the configs should exactly match the name in the “companion app”. This was previously not obvious to me.
Now I was also able to display the second speaker that are connected as a slave to the main one.
There is a request. It would be great if we can to give devices the other names inside HA that are convenient for its interface. For example, do it through the field “friendly_name”.
And, if necessary, I will be happy to help with testing new options.
Now I have two speakers: GGMM E3 (now as a master) and GGMM E5 (now as a slave).
Setting up other parts of HA, I came to the conclusion that using the “name” field to indicate the name of the speaker in the “companion app” is incorrect.
The fact is that in many other places in HA this field is used to specify the name of the device for the frontend. So, in your case, there is a violation of the general logic of the structure of the config. For users, this will constantly lead to errors in configs due to misunderstanding.
I think that it is more correct to bring the field values to unified standards.
Yes, you are absolutely correct! I need to introduce a new required setting like “companion_app_name” (if you have a good name for this let me know ) and make the current “name” setting optional and use it as friendly_name. I wont be able to work on it this week though due to work load…