Google cast stops after 30 seconds - Nest hub

[hemandk]

Hi,

After the Nest Hub is updated to Fuchsia it stops if I cast home assistant after 30 seconds now instead of 10 minutes as before.

Would it be possible to Use disableIdleTimeout as mentioned in Google docs?

https://developers.google.com/cast/docs/reference/web_receiver/cast.framework.CastReceiverOptions

window.castReceiverManager.start({statusText: "Application is starting", disableIdleTimeout: true});

this was also mentioned in the following issue that was closed: https://github.com/skorokithakis/catt/issues/335

[skorokithakis]

Hmm, @theychx, would a custom receiver solve this?

[theychx]

I think this relates to cast_site, so we would have to roll our own version of dashcast (or similar).

[scooper1]

Can we clone dashcast to make a update I am having similar problems

[tungmeister]

same issue here - dies after ~30 seconds unless I interact with it

[maxi1134]

Would love for a solution to this!

I can test anything on my end on multiple Nest Hubs if you guys need!

[dannymertens]

Same issue on one off my hubs :-(

[mw1066]

It seems Google have removed the only useful feature of the Nest Hub - being able to cast to it with CATT, 10 mins timeout was bad enough, but 30s is crazy. Time to bin it.

[jimbovp]

Same problem here. +1 for a solution. Any chance to find a way to "keep the hub busy"? Like having cast_site behave the same way cast does? For what it's worth, I send a feedback to Google to change the timeout back to 10 minutes or alternatively make it configurable. Don't know if it will change anything, but maybe if enough of us ask the same thing....

[Joost1985]

Same problem here, would be fantastic when somebody can solve this.

[lolouk44]

Chiming in as I have the same issue too.

[dannymertens]

Any updates about this, or someone another solution because it is really annoying now for the family not one of my dashboards is working now, makes it very hard to control stuff in the house for the wife who does not have a smartphone or something like that :-(

[scooper1]

You can do a Google pub sub to control ha via Google hubs just can have useful status display

[dannymertens]

You can do a Google pub sub to control ha via Google hubs just can have useful status display

Hi @scooper1 thanks for your quick reply! I tried to Google it but to be honest not completely clear how to go further here, do you have some example on how I can use this for casting my dashboards to the Nest hubs?

Thanks!

[scooper1]

Sorry no dashboard cast   but it does provide way for Google to control things on ha via a simple screen display.   It's not like a dashboard      it you really want dash board then a old  tablet might solve problems long term.    

[dannymertens]

OK, clear I already use Google relay in HA for devices that are not native supported by HA but do work with Google Assistant, works great for things like that. But for easy controlling devices, scripts, automations I have almost in every room a Nest Hub with a dedicated dashboard what was working great then we got the 10-minute timeout but that we could overcome by casting every 9 minutes again, but now 30 seconds is just crazy!! Thanks for your support, so still hoping that the team can fix CATT because that was working flawless before!

[joey102]

Is it possible to use disableIdleTimeout when casting to work around this? Or maxInactivity?

[rocket59]

Add me to the list also. My Gen 1 hub is exhibiting the same behaviour after the update. So far gen 2 seems to still work ok but no idea for how long.

[CJA85]

also having this same issue on my 3 nesthubs.. would really like this to work, will help with any testing if needed.

[Unlink]

@raulgbcr i tried your fork and it is not working for me. Im not sure if disableIdleTimeout helps, because home assistant controller already has disableIdleTimeout in receiver code.

I connot find source code in github but there is it https://cast.home-assistant.io/receiver.html

[raulgbcr]

@Unlink you need a custom sender with the fork that keeps an active connection with it, catt will just force the url and reload the page on the internal browser, but even with the custom sender keeping the connection it times out around 15 mins. I have ditched the fork since I have created a new receiver with the new CAF and still experimenting with it, but disableIdleTimeout doesn't seems to do what we want it to do 😢

[skorokithakis]

@raulgbcr would it be possible to merge your receiver into Catt or create a new one? @theychx was trying to do the same, AFAIK.

[raulgbcr]

@skorokithakis should be, but It is not working yet, even with the latest API and disableIdleTimeout it stills timeout, so I don't see much utility on it right now. Still playing with it trying to send keepalive messages to the namespace and stuff, but no luck yet...

[lolouk44]

@raulgbcr

it times out around 15 mins

This is still much better timeout than the 30sec were currently getting 😉

[CJA85]

Yeah i have been refreshing every 10 minutes for a few months now and that has worked fine, 15 minutes would be a dream.

hook us up :)

[scooper1]

Did you push an update having problems with site-cast from home assistant to google hub max video feds from camera keep stopping so many things changing it is hard to find the cause i am on the 2021.9 beta that has changed some things on camera feds etc.
Feds are working ok on direct lovelace pages so suspect it might be catt related

[CJA85]

Is this being worked on? Can i do anything to help with testing?

[sondreen]

@raulgbcr PLEASE hook us up, thank you!

[rocket59]

I just rebooted my hub after setting the screen timeout to 5 minutes (in the settings section) my cast is still up (1/2 day so far). Not sure if this is an aberration or whether google has fixed it, although the hub cast and system firmware hasn't changed.

[dannymertens]

I just rebooted my hub after setting the screen timeout to 5 minutes (in the settings section) my cast is still up (1/2 day so far). Not sure if this is an aberration or whether google has fixed it, although the hub cast and system firmware hasn't changed.

I tested it also but does not seem to work for me still the 30 seconds limit here on both hubs :-(

[lolouk44]

Same here doesn't work for me

[rocket59]

I managed to achieve this once quite a while ago and it eventually reverted to the (at the time) 10 minute timeout. What that says is that somehow the cast can stay persistent although it looks like a precarious condition which can revert at any time.

[rocket59]

Sorry guys, after a day of hope it's gone back to 30s :(

[rocket59]

A problem has now cropped up with my other (Gen 2) hub.

As of today (after latest restart by itself) my hub no longer accepts new cast site commands until a cast stop command is issued. Anyone noticed this? Previously I could just issue a cast site and it would recast no matter what's on screen.

[scooper1]

A problem has now cropped up with my other (Gen 2) hub.

As of today (after latest restart by itself) my hub no longer accepts new cast site commands until a cast stop command is issued. Anyone noticed this? Previously I could just issue a cast site and it would recast no matter what's on screen.

after a restart a few days ago this problem now happens on both my hub maxes inserting a stop command before the 10 minute cast renew has fixed the problem - it is quite nasty as it stops the hassio ssh web terminal accepting new commands after a cast without a stop

[Itzarthi]

If you do the following then it will work again:

Add “catt -d “your_device” stop” to your reload script to stop the cast stream before reloading.

if ! catt -d “your_device” status | grep ‘PLAYING’; then catt -d “your_device” volume 0 catt -d “your_device” stop catt -d “your_device” cast_site http://xxx fi

Thanks to: https://community.home-assistant.io/t/using-catt/130332/448

[dannymertens]

If you do the following then it will work again:

Add “catt -d “your_device” stop” to your reload script to stop the cast stream before reloading.

if ! catt -d “your_device” status | grep ‘PLAYING’; then catt -d “your_device” volume 0 catt -d “your_device” stop catt -d “your_device” cast_site http://xxx fi

Thanks to: https://community.home-assistant.io/t/using-catt/130332/448

Hi @Itzarthi,

I changed my script and the dashboard was loaded on my hub but still after a couple seconds is also killed again, am I'm missing something here?

`#!/bin/bash

if ! catt -d “192.168.1.86” status | grep ‘PLAYING’; then catt -d “192.168.1.86” volume 0 catt -d “192.168.1.86” stop catt -d “192.168.1.86” cast_site http://192.168.1.20:8123/dash-master-hub/ochtend fi`

@raulgbcr You mentioned in your reply to @Unlink that you got it working for 15 minutes is there a possibility that you can share this update with the community because now nothing works and 15 minutes is even better than the 10 minutes before so would everybody help a lot I think!?

Thanks!

@Unlink you need a custom sender with the fork that keeps an active connection with it, catt will just force the url and reload the page on the internal browser, but even with the custom sender keeping the connection it times out around 15 mins. I have ditched the fork since I have created a new receiver with the new CAF and still experimenting with it, but disableIdleTimeout doesn't seems to do what we want it to do 😢

[raulgbcr]

If you do the following then it will work again: Add “catt -d “your_device” stop” to your reload script to stop the cast stream before reloading. if ! catt -d “your_device” status | grep ‘PLAYING’; then catt -d “your_device” volume 0 catt -d “your_device” stop catt -d “your_device” cast_site http://xxx fi Thanks to: https://community.home-assistant.io/t/using-catt/130332/448

Hi @Itzarthi,

I changed my script and the dashboard was loaded on my hub but still after a couple seconds is also killed again, am I'm missing something here?

`#!/bin/bash

if ! catt -d “192.168.1.86” status | grep ‘PLAYING’; then catt -d “192.168.1.86” volume 0 catt -d “192.168.1.86” stop catt -d “192.168.1.86” cast_site http://192.168.1.20:8123/dash-master-hub/ochtend fi`

@raulgbcr You mentioned in your reply to @Unlink that you got it working for 15 minutes is there a possibility that you can share this update with the community because now nothing works and 15 minutes is even better than the 10 minutes before so would everybody help a lot I think!?

Thanks!

@Unlink you need a custom sender with the fork that keeps an active connection with it, catt will just force the url and reload the page on the internal browser, but even with the custom sender keeping the connection it times out around 15 mins. I have ditched the fork since I have created a new receiver with the new CAF and still experimenting with it, but disableIdleTimeout doesn't seems to do what we want it to do 😢

Hi, unfortunatelly I don't have that version anymore, got rid of all of that when I started to wrote my own from scratch. I have a working receiver that doesn't timeout and have been working for 2 weeks already without recasting, however, there are 2 problems with this receiver.

First, this is a completely new receiver wrote in CAF (Cast Application Framework), and due to the Google Cast Developer terms, I can't publish this without a public and valid sender, which I don't have (I just use a custom launch script with pychromecast) Due to work and life in general I don't have time to make a sender for this new receiver and publishing it right now.

Second, this receiver relies in a bug I found in CAF, that im 99% sure is gonna get patched the moment I release it, since it messes with what the cast player thinks its playing, and I doubt they will let something like that pass. I've tried to get in touch with someone on the Google cast team to discuss this, but have got no luck yet.

So, for those reasons I really can't release this with you yet, and I don't know if I will ever release it, since publishing this right now may cause my Cast Developer account to get terminated, and thats a no go.

Regards.

[dannymertens]

Second, this receiver relies in a bug I found in CAF, that im 99% sure is gonna get patched the moment I release it, since it messes with what the cast player thinks its playing, and I doubt they will let something like that pass. I've tried to get in touch with someone on the Google cast team to discuss this, but have got no luck yet.

So, for those reasons I really can't release this with you yet, and I don't know if I will ever release it, since publishing this right now may cause my Cast Developer account to get terminated, and thats a no go.

Regards.

Hi @raulgbcr,

Thanks for the update, thats off course completely understandable no way that I want to bring you in trouble, so we can close this route now and hope again that the team and/or @skorokithakis can find a work a round, fix for the problems?

Thanks!

[scooper1]

Is possible for some of that are are able to create our own cast developer account and test you code using that. ... I don't know if you have to pay a sub to get a account. It's a bit like how we currently have our own Google API accounts to do a pub sub from hassio to Google

[skorokithakis]

I think @theychx is working on a fix (we have our own custom controller we may be able to deploy), but I don't think we can rely on a bug, sadly.

[dannymertens]

I think @theychx is working on a fix (we have our own custom controller we may be able to deploy), but I don't think we can rely on a bug, sadly.

Thanks for the update @skorokithakis happy to hear that this still is worked on!!

[FlexxFR]

Hi, as I'm also suffering from the same issue I'm willing to test if any testing is required. Is there any reason why casting a site directly from Chrome does not stop after 30 seconds? (No interaction possible so no replacement for casting HA dashboards)

[CJA85]

My last nesthub just updated so now none of them work :/

[jtonk]

when casting a website, 'catt info' shows a lot of missing information.

current_time: 0 content_id: None content_type: None duration: None stream_type: UNKNOWN idle_reason: None media_session_id: None playback_rate: 1 player_state: UNKNOWN supported_media_commands: 0 volume_level: 0.0 volume_muted: False media_custom_data: {} media_metadata: {} subtitle_tracks: {} current_subtitle_tracks: [] last_updated: None is_active_input: False is_stand_by: True app_id: 84912283 display_name: DashCast namespaces: ['urn:x-cast:com.google.cast.debugoverlay', 'urn:x-cast:com.google.cast.cac', 'urn:x-cast:com.madmod.dashcast'] session_id: 4e8969c2-c564-44ad-b433-eb9bc810418b transport_id: 4e8969c2-c564-44ad-b433-eb9bc810418b status_text: Application ready icon_url: volume_control_type: master

Maybe it stops because of the missing parameters, is it something that can be provided with catt or dash-cast?

---- edit ---- I just noticed that the nest hub goes into 'clock' mode exactly 30 seconds after the player_state goes from PLAYING to IDLE when the video is finished.

[rocket59]

Any updates on this?

[FlexxFR]

I noticed something strange, I bought 2 new Google HUB's recently and these are still working with the 10 minute timeout. First I thought these devices were not updated to fuchsia yet but now i'm not sure.

Firmware 1.52.260996 should be Fuchsia, at least for Gen1. I have of of those running on this firmware. (At least 1.52)

But my two new HUB are running on 1.56.265669. Which is strange as according the Google.com info page the newest version for Gen2 is 1.54 ???

Anyway, no 30 sec timeout issues with these devices (so far....)

[jtonk]

I was tinkering with the device for a bit today. I tried casting a home assistant Lovelace dashboard with a web media player that comes with the browser_mod plugin. The funny thing is that it appears that the website and its content stays active in the background and the clock is merely an overlay over the dashboard, because when I send audio to the web media player on the dashboard it still plays. The browser_mod sensors also indicate that the browser is still active.

it appears that none of the browser_mod interactions can stop the clock timeout screensaver

[skorokithakis]

Everything I've seen points to this being a screensaver bug, seems that the screensaver doesn't realize it shouldn't be triggered. I don't know how we can work around it, though...

[raulgbcr]

Everything I've seen points to this being a screensaver bug, seems that the screensaver doesn't realize it shouldn't be triggered. I don't know how we can work around it, though...

I don't think it is a bug for what i have seen, if you trick the OS in thinking he is watching a livestream you can bypass that, can't tell you more but there are ways to do this with the new CAF

[jonaseymour]

There seems to be a fix for the same issue that impacted Home Assistant Cast here: https://github.com/home-assistant/core/issues/53882

Can a similar fix be applied to CATT?