[chromecast] Unable to "send" Stream URLs

[regnets]

I am unable to play stream urls to my chromecast audio for example: http://www.wdr.de/wdrlive/media/einslivedigi.m3u http://mp3channels.webradio.rockantenne.de/rockantenne http://mp3channels.webradio.rockantenne.de/rockantenne.aac

openHAB 2.0 Build #684 Chromecast Binding Build #225

Here is my test items file:

Group gTest "Test"
Player P_BR_Chromecast_Player (gTest) { channel="chromecast:audio:2233408551fc01019e6a2a027ea76298:control"}
Dimmer P_BR_Chromecast_Volume (gTest) { channel="chromecast:audio:2233408551fc01019e6a2a027ea76298:volume"}
String P_BR_Chromecast_URL    (gTest) { channel="chromecast:audio:2233408551fc01019e6a2a027ea76298:playuri"}
Switch TestTTS "TTS Test" (gTest)

Here is the corresponding rule:

rule "TTS Test"
when 
  Item TestTTS changed
then 
  P_BR_Chromecast_URL.sendCommand("http://mp3channels.webradio.rockantenne.de/rockantenne.aac")
end

I got no errors in the server.log file while running this action. However i can hear a beep, if i change the volume via openhab

[TS-Tec]

Any updates?

I am also unable to send any urn's :(

[lolodomo]

These 3 URLs are working well with my Android TV box when I use the stream console command like for example

smarthome:audio stream chromecast:chromecast:68531fbf51cfff589ca6043630b411bb http://mp3channels.webradio.rockantenne.de/rockantenne

Can you check if such a command works with a Chromecast Audio ? If it does not work, there is a specific problem with Chromecast Audio. If it does work, there is a problem with the handling of the URL channel.

[lolodomo]

Using the console command:

smarthome:send FreeboxPlayerMini_PlayURI http://www.wdr.de/wdrlive/media/einslivedigi.m3u

leads to this error:

10:35:59.037 [ERROR] [chromecast.handler.ChromecastHandler] - Failed playing media: Unable to load media

So I would suppose a problem in the handling of the URL channel.

[lolodomo]

The only difference I can see in the code when using the URL channel is that no MIME type is provided when requested the loading of the media.

[TS-Tec]

I can confirm smarthome:audio stream xxChromeCastxxx xxStreamxxx works!

So what is the difference to the URI-Channel? How can I implement the console command e.g. in my HABPanel widgets as work around?

[tavalin]

That audio stream only works for audio files. The play uri channel also works for video streams. However your HABPanel question is better off in the forums as it's not relevant to the issue raised.

[TS-Tec]

OK, but the play uri does not work if you read the posts above! Only audio stream works! So what is the solution to use the play uri channel with a Chromecast Audio?

[tavalin]

As @lolodomo mentioned earlier, the playurichannel does not attempt to specify the MIME type of the stream whereas the audio stream makes an assumption (using the audio framework).

I suspect the fix would be to determine the MIME type of the URI you send to the the playurichannel - however at this point in time I don't know how difficult that would be.

So the proper solution is to wait for a fix - however you could probably work around it with a rule that calls stream() when the URI String item is changed/updated.

[lolodomo]

As I already said yesterday, I think the problem is that in one case we set a MIME type (audio/xxx), in the other we don't. I will confirm that later by updating the binding. How could the binding determine a MIME type for any URL provided by the user ? It could be a video, an audio... we don't know. The only solution I can imagine is that this information would be provided by the user in addition to the URL.

[TS-Tec]

...or if the thing is a Chromecast Audio, always use MIME type audio...

Here is my log output if I use the send command, maybe this also helps:

[WARN ] [rg.jivesoftware.smack.XMPPConnection] - Connection closed with error
java.io.EOFException: no more data available - expected end tag </stream:stream> to close start tag <stream:stream> from line 1, parser stopped on END_TAG seen ...<![CDATA[result=23393211]]></oa></iq>... @1:646

In the Google Home app, you can see that the stream is recognized but you can not start playing by pressing the play button - nothing happens if you press it.

[lolodomo]

Even for audio several MIME are possible.

[tavalin]

MIME type audio? Is that MP3 or wave? Not as straight forward as "audio" so I'd rather do this properly.

Also that log output looks like it is from the Harmony Hub binding.

[TS-Tec]

I just recognized that the item update information after used the send command looks strange:

[INFO ] [smarthome.event.ItemCommandEvent ] - Item 'ChromecastWZ' received command http://www.wdr.de/wdrlive/media/einslivedigi.m3usmarthome:send

Why is smarthome:send added to the end of the string? Is this correct? I did not send this...

[TS-Tec]

Also that log output looks like it is from the Harmony Hub binding.

Maybe your right! I have installed this! Just saw this /stream hint and thought it belongs to chrome cast... sorry for confusion..

[tavalin]

M3U:

Having read this link, Google Cast devices don't support m3u streams so it's only due to the good work in the implementation of the audio system that it even works with audio stream!!

The audio stream path uses URLAudioStream - the URLAudioStream constructor calls createInputStream() which has some logic to create an input stream from a URL- as an example, for m3u files this logic opens the stream and retrieves the real audio URL.

So for now playuri is working as per the Cast spec (i.e. doesn't support m3u streams). Potentially we could reuse the URLAudioStream class to allow it to handle m3u streams in handlePlayUri but this gives us another problem of working out whether the given URL is a video or audio file.

AAC:

Though related to the above, this should work and can be fixed. PR #1844 raised.

[lolodomo]

What is required now is only to package the binding with the new library we rely on.

[mroggi]

Dear friends, any update on this? I would love to use this to play streams on my Google Home via OpenHab2. Any work around you use in the mean time? Thanks!

[tavalin]

I believe a fix was implemented. Are you using a recent build?

[mroggi]

I believe so. How could I check my Openhab2 version or the binding version? (Sorry, I am still an OpenHab rookie) I have tried to stream:

www.radioeins.de/live.m3u www.radioeins.de/live.pls http://radioeins.de/stream

But did not get it to work. Volume works and local files stream works fine as well. Thanks a lot for your help!

[tavalin]

As I mentioned above, Chromecasts can't play m3u files. A potential workaround is to use the same process as the URLAudioStream and open the m3u, establish where the mp3 etc is and send the location to the Chromecast.

Could you try the AAC URL in the original post and see if that works?

[mroggi]

Will do, thanks! Will report back on results

[mroggi]

Just tested the aac stream with no success (http://mp3channels.webradio.rockantenne.de/rockantenne.aac). I hear the beep when changing the volume and also hear a beep when starting the stream, but no sound afterwards. I would be extremely thankful for help from this group!!!

[tavalin]

I tried on my production OH and that AAC stream doesn't work, but when I tried in Eclipse using the latest code from master branch it works. So for AAC support I would suggest to try again when the next build is available. If it's not working then I'll try and look again, although as far as I know the upstream library incorporated my suggested changes and all should be working.

As for M3U support, you're probably out of luck.

[wborn]

Is this still an issue @regnets, @lolodomo, @tavalin?