So it does seem everything should be working correctly.
This morning I have tried a fresh install on HA (version 100.2) using python 3.7 and everything is in fact working… I tried a few things and was able to reproduce your error.
Can you please confirm you actually have at least one station and one playlist (a playlist you created, not an automatic playlist) added to your google music library?
Actually you nailed it. Now I feel silly. The only playlists I had were the automatically created playlists. I made a new one called test, and everything works. Thanks for your help. And for putting this together.
In fact I think that explains why it work on your computer and phone. You see these are using the official Google apps. This gmusic_play is using the unofficial gmusicapi. It is in the documentation of this unofficial api that is stated to work in the US only.
I’m honestly not sure though… Any chance you would be able to try a free trial period to all-access (if you have one available) and see if it starts working?
I’m glad part is working but if we can in fact prove one way or another if this is the unofficial api limitation. I’m not sure how else to do that unless you can test as a subscriber to see if it starts to work.
I came across this python script by @rodpayne that you can combine with an automation to help do this. Trying to keep the “Default Media Receiver” synced up is tricky but this should provide a good starting point.
#==================================================================================================
# python_scripts/set_state.py
#==================================================================================================
#--------------------------------------------------------------------------------------------------
# Set the state or other attributes for the entity specified in the Automation Action
#--------------------------------------------------------------------------------------------------
inputEntity = data.get('entity_id')
if inputEntity is None:
logger.warning("===== entity_id is required if you want to set something.")
else:
inputStateObject = hass.states.get(inputEntity)
inputState = inputStateObject.state
inputAttributesObject = inputStateObject.attributes.copy()
for item in data:
newAttribute = data.get(item)
logger.debug("===== item = {0}; value = {1}".format(item,newAttribute))
if item == 'entity_id':
continue # already handled
elif item == 'state':
inputState = newAttribute
else:
inputAttributesObject[item] = newAttribute
hass.states.set(inputEntity, inputState, inputAttributesObject)
Thanks for this. Unfortunately even though the script correctly sets those attributes the image and title do not show on the MiBox. I thought i would change the automation to set those values as soon as the gmusic_receiver changes its state to playing (instead of waiting 2 seconds) but it seems to set it and then immediately it gets cleared. Still busy troubleshooting
Just updated to the latest version.
but now it wont pull my playlist I guess. .input_select] Invalid option: (possible options: )
Lets see what I find out
Trying to get gmusicproxy up and running in docker using the digitallyseamless image and I can get it running but I used portainer and am not too familiar with docker and cant seem to connect tot it.I would probably start a seperate thread for that as its related but not directly to this custom component
Latest version of HA or gmusic_player? Just curious but eithway nothing has changed related to the playlist. I’m on HA 0.100.3. I’ve started to see the same messages in my logs but I have not had it effect gmusic_player. I’ll have a look as well.
I’m trying to rework gmusic_player this so the input_select(s) can become completely optional.
For example:
If you do not have any stations then you should not need an input_select for them.
If you know the name of a playlist and would rather start playback using play_media service.
Also, while it may seem like I’m going the wrong direction (adding more stuff to the package files instead of directly to the custom_componet) I think this might be a better way to go. For example to populate the input_select I actually just calling the input_select.set_options service from inside the component. This can be done just a s easily using a script included in the package file.
Also since a script will become a services in HA, it’s easier to create a more custom service. Example in this case is being able to select the speakers using the play_media service. Unfortunately it seems I can not create a custom service for a platform.(gmusic_player is a custom platform for the media_player integration. At my understanding today gmusic_play would need to become its own separate integration (In other words is own domain). I’ve been around a few times trying to make this switch but I still don’t understand enough to get it working.
What I have been able to do though (Not released yet) is add an event listener to gmusic_player that can be triggered with a script. Then in the package file I can include a script to fire the new event.
Show script
script:
gmusic_play_media:
alias: gmusic_player.play_media
description: 'Fire event: gmusic_play_media'
fields:
speakers:
description: Name of the speakers to play music on.
example: bedroom_stereo
source:
description: Media Source. Should be 'station' or 'playlist'
example: station
name:
description: Name of the station or playlist.
example: I'm Feeling Lucky
sequence:
- event: gmusic_player.play_media
event_data_template:
speakers: "{{ speakers }}"
source: "{{ source }}"
name: "{{ name }}"
So this is what I end up with
This has also made it easier to start playback of a specific station or playlist.
Have to restart a couple of times to get the input_select populated right. my hassio is already a little to big and got his performance issues.
The update for the oauth login Threw me up a little - I used one of the alpha versions until just now.
The fields function is sexy as F.
And an optional input_select is ok as long as it isnt away for good - you need an way to get your stupid assinged playlist names somehow
Does on your side the automation for the next track also triggers often in the middle of an song?
No it will not go away but to better explain, I’m thinking of moving the actual commands that populates the input_select out of the gmusic_player component and into separate scripts for each source Each script would fire a custom event similar to example above. Then we could use an automation to trigger the script to fire when HA starts. In the end this would give the same function provided now. Additionally for example, let’s say you do not use stations - you could just turn-off the automation that fires the script to “set_options for the input_select containing stations” – Even more you would be able to completely remove the input_select for stations and even the script and automation as well. Since the event to populate that input_select would never be fired gmusic_player would no longer crap out if you don’t have it or if the list is empty or whatever.
This might seem silly with only two sources but I’ve been playing around and more is on the way.
I cherry picked these changes already and will be included in gmusic_player shortly.
As it stands now @miikkajo’s fork has removed the playlist functionality. So this has got me thinking maybe some people don’t want every source so rather than have to remove it completely, you could just disable it’s related automation. I think this could effectively allow you to enable or disable different sources right from the HA gui by turning off or on the related automation.
Yes this happens but I can’t control it. gmusic_player itself is not actually playing music. (which is why the “speakers” are required) The songs get cut off because the playback url return by gmusicapi is only valid for a minute. Under certain situations the connection can be reset but since the link is no longer valid playback the song can not continue streaming so it just cuts off. The automation see the “default media receiver” go to an idle state so it triggers the next song. I have always noticed this happen once in a while (like maybe one or two song a month), even back using the original gmusic_switch. I’m not sure why it has gotten so much worse. Since late August it has become so bad that only a few songs ever make it to the end. The quick and easiest workaround to use gmusicproxy. (Needs installed separately) but then you can just set the url in gmusic_config.yaml and gmusic_player will get playback url from gmusicproxy that does not expire.
0.0.0.0:9999 seems to be the ip:port that gmusicproxy is listening on but I cant see anything in the gmusicproxy log when I try to play anything. If I use vlc on a different machine with:
I can see in gmusicproxy log that it gets a track id for that album
192.168.1.43 - - [25/Oct/2019 19:02:28] "GET /get_by_search?type=album&artist=Rolling%20Stones&title=tattoo&exact=no HTTP/1.1" 200 -
Searching for album with query: Rolling Stones tattoo
Selected album: The Rolling Stones - Tattoo You (Buzub7yrmswkll7t7d7kancjtle)
Getting the tracks of the album with id 'Buzub7yrmswkll7t7d7kancjtle': Tattoo You - The Rolling Stones
edit I feel stupid I needed this in my gmusic_config.yaml instead
Ya my edit tells the story learning docker too lol .I wonder why the docker image page wants to map out port 80 when the built image actually listens on 9999