Hello,
I’m trying to use rygel as a renderer for my Home Assistant.
My Pc is on debian 12 (ie using pipewire).
I well see the rygel DLNA server and I can send my sounds.
But nothing play and I always have such message in the debug console of Rygel:
RygelRenderer-WARNING **: 17:11:54.394: Impossible d’accéder à la ressource en http://xxxxxxxxxxx:8123/api/tts_proxy/1xb4ONV7LPdd-2BD-cgSug.mp3 : Method Not Allowed.
Thank you for your help.
My suspicion is that homeassistant does not like the HEAD request that the renderer does, but rygel should work around that.
Can you run rygel from console with
G_MESSAGES_DEBUG=all rygel -g 5
And try to play that again and post the logs here?
Ok, tried myself. Playback works fine if using Google TTS. I cannot test homeassistant TTS since I do not have homeassistant cloud.
Thanks for your reply !
In fact the problem not seem to be specific to TTS. If I try to play music, I have the same message.
The debug was very verbose ! I paste here two extract who appear to me interesting. I hope they were use full for you.
In the beginning I have this message :
rygel:5106): RygelCore-DEBUG: 18:43:02.856: rygel-plugin-loader.vala:151: Trying to load plugin ‘Playbin’
(rygel:5106): RygelRendererGst-DEBUG: 18:43:02.865: rygel-playbin-player.vala:648: No audio sink configured, using default: Aucune valeur disponible pour « Playbin/audio-sink »
(rygel:5106): RygelRendererGst-DEBUG: 18:43:02.865: rygel-playbin-player.vala:661: No video sink configured, using default: Aucune valeur disponible pour « Playbin/video-sink »
And at the moment where I try to send a TTS message :
rygel:5106): GLib-GIO-DEBUG: 18:53:00.669: GSocketClient: Starting new address enumeration
(rygel:5106): GLib-GIO-DEBUG: 18:53:00.669: GSocketClient: Address enumeration succeeded
(rygel:5106): GLib-GIO-DEBUG: 18:53:00.669: GSocketClient: Starting TCP connection attempt
(rygel:5106): GLib-GIO-DEBUG: 18:53:00.669: GSocketClient: TCP connection successful
(rygel:5106): GLib-GIO-DEBUG: 18:53:00.670: GSocketClient: Starting application layer connection
(rygel:5106): GLib-GIO-DEBUG: 18:53:00.670: GSocketClient: Connection successful!
(rygel:5106): RygelRenderer-DEBUG: 18:53:00.670: rygel-av-transport.vala:851: Peer does not support HEAD, trying GET
(rygel:5106): RygelRenderer-WARNING **: 18:53:00.670: Impossible d’accéder à la ressource en http://192.168.11.20:8123/api/tts_proxy/BeG9WMuCHLw6C6hi9UuIhA.mp3 : Method Not Allowed
hm. Weird. Can you add also GUPNP_DEBUG=1 - will be more verbose… Leaning a bit towards something being off with home assistant (e.g. access needing a password or something like that)
You’re right, I tried with stream what you hear, it’s walk fine … Rygel is ok.
I’ve cut and paste the URL I found in logs ( http://192.168.11.20:8123/api/tts_proxy/50TqFnWr2wc-V38bbwqNMg.mp3) in a browser… It work fine !
I suspect there is a network restriction somewhere ? Or the format of the mp3 produce by HomeAssistant is not well recognized by Rygel on my PC ??
I will experiment to to an other PC on Debian 12 as soon as possible.
Thank you very much for spending time on my problem !
No, if Rygel would not accept the MP3 itself there would be a different error. Can you try the GUPNP_DEBUG=1 again, that would show what method Rygel tries (should be GET)
yeah that is probably missing a bit above that, you can send me a mail to logs@rygel-project.org?
I send all the logs from starting Rygel to the error.
Thank you for your help.
Best regards
I try with an other PC under Debian 12 … I have exactly the same behavior, with the same warning message… Very weird
Ah sorry, the renderer interaction is not included in GUPNP_DEBUG, it seems. That needs fixing. Otherwise, I am lost. To me this is pointing towards a HomeAssistant configuration problem
You’re right !
I found an error in HomeHassistant logs (by mail)
There is a discussion here DLNA-DMR Fails to Connect · Issue #126275 · home-assistant/core · GitHub
But no solution yet 
I would consider all of them with status code 500 “normal” as a result of Rygel not being able to access the uri, but the two with 400 are weird - they should also trigger a warning log on the Rygel side 
The first one should be 500/701 (Transition not possible) - Which makes me think that home assistant randomly might mix ipv4/v6?
Can you try to turn off ipv6 in Rygel and see if it works then?
Should be ipv6=false right on top of ~/.config/rygel.conf, in section [general]
Error during call async_media_stop: UpnpResponseError("Error during async_call(), action: Stop, args: {'InstanceID': 0}, status: 400, body: ")
Error during call async_play_media: UpnpResponseError('Error during async_call(), action: SetAVTransportURI, args: {\'InstanceID\': 0, \'CurrentURI\': \'http://192.168.11.20:8123/api/tts_proxy/BeG9WMuCHLw6C6hi9UuIhA.mp3\', \'CurrentURIMetaData\': \'<DIDL-Lite xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/" xmlns:sec="http://www.sec.co.kr/"><item id="0" parentID="-1" restricted="false"><dc:title>Home Assistant</dc:title><upnp:class>object.item.audioItem</upnp:class><res protocolInfo="http-get:*:audio/mpeg:*">http://192.168.11.20:8123/api/tts_proxy/BeG9WMuCHLw6C6hi9UuIhA.mp3</res></item></DIDL-Lite>\'}, status: 400, body: ')
I send the logs with IPV6 disable in ~/config/rygel.conf.
I found this topic Add webhook trigger allowed_methods/local_only options by esev · Pull Request #66494 · home-assistant/core · GitHub. Do you think it can have an impact ?
It tried with a local connection to my HomeAssistant instance, but the behavior is the same.
Thanks
I’m slightly lost, sorry
I am lost too…
I did some tests :
- The same HomeAssistant config on an other PC (Debian12+docker) : Exactly the same message
- On this new PC with a new config from scratch : idem
- On this new PC with a new config from scratch and an older version of HomeAssistant (2022.12) : Same thing
So the problem may be in an other place … from Debian 12 ? From my network ?
I keep looking …