Google Cast自定义接收器超时 [英] Google Cast custom receiver timing out
问题描述
使用 Google CAF接收器SDK ，我们如何防止接收器超时并在不使用接收器播放器时自动终止投射会话?
Using the Google CAF Receiver SDK, how do we prevent the receiver from timing out and automatically killing the cast session when we're not using the receiver player?
标准的Google Cast用例是将媒体从设备发送到演员接收器，并让接收器使用播放器渲染媒体. CAF接收器SDK 以精美，简单的方式
The standard Google Cast use case is to send media from a device to the cast receiver and have the receiver render the media using a player. The CAF receiver SDK provides this functionality in a beautiful, simple way using the element cast-media-player.
但是对于那些我们想从设备投射并渲染与使用cast-media-player不相关的内容(例如HTML仪表板)的实例，我们如何使接收器保持活动状态?
But for those instances when we want to cast from a device and render content where it's not relevant to use the cast-media-player (e.g. an HTML dashboard), how do we keep the receiver alive?
例如，以下自定义接收方(为简便起见，使用HAML)导致转换会话在5分钟后自动终止...
The following custom receiver for example (HAML for brevity), results in the cast session automatically terminating after 5 minutes...
!!! 5
%html
%head
:css
cast-media-player {
display: none;
}
= javascript_include_tag 'https://www.gstatic.com/cast/sdk/libs/caf_receiver/v3/cast_receiver_framework.js'
%body
%cast-media-player
:javascript
const context = cast.framework.CastReceiverContext.getInstance();
const player = context.getPlayerManager();
player.setMessageInterceptor(cast.framework.messages.MessageType.LOAD, loadRequestData => {
...[load custom view]...
return false;
});
context.start();
接收器日志显示行cast.framework.common.IdleTimeoutManager] timer expired，然后关闭.示例接收器日志在此处显示.
The receiver log shows the line cast.framework.common.IdleTimeoutManager] timer expired and then shuts down. Example receiver log shown here.
我尝试过:
- 增加 cast.framework.CastReceiverOptions#maxInactivity 数量很大
- 定期从发件人加载新数据
- 定期从接收方向发送方发送自定义消息
- 定期从发送方向接收方发送自定义消息
- Increasing cast.framework.CastReceiverOptions#maxInactivity to a very large number
- Periodically loading new data from the sender
- Periodically sending custom messages from the receiver to the sender
- Periodically sending custom messages from the sender to the receiver
非常感谢您的帮助！
推荐答案
我想出了另一种阻止此问题的方法，该方法比定期发送无声剪辑更有效，但感觉很脏.基本上，由于没有媒体，我们必须停止Chromecast的setTimeout触发并关闭连接.最快的解决方案是在加载Chromecast接收器脚本之前，将setTimeout简单地重新声明为虚拟无操作功能.在这种情况下，似乎并没有破坏任何与Chromecast相关的内容，因为Chromecast的超时似乎都与视频相关，而与该用例无关.
I figured out an alternative way to stop this which is more efficient than periodically sending a silent clip, but it feels dirty. Basically we have to stop Chromecast's setTimeout from firing and closing the connection due to no media. The quickest solution is to simply re-declare setTimeout as a dummy no-op function before loading the Chromecast receiver script. It does not seem to break anything Chromecast-related in this scenario because it looks like Chromecast's timeouts are all related to video which aren't relevant to this use case.
window._setTimeout = window.setTimeout;
window.setTimeout = function(a, b) {
// disable setTimeout so chromecast won't kill us after 5 minutes...
};
然后在我们自己的应用程序中，如果我们需要使用超时，则改为调用_setTimeout.
Then in our own app if we need to use a timeout we call _setTimeout instead.
除了有人手动托管cast_receiver_framework.js并注释掉有问题的行(位于Wn(a, b)函数内部)或每隔几分钟发送一个无声剪辑外，我是否会感兴趣，如果有人发现了一种更好的方法来实现这一目标.但是Google不建议您自托管.
I would be interested if anyone has discovered a better way to achieve this, aside from manually hosting cast_receiver_framework.js with the offending line commented out (which is inside the Wn(a, b) function) or sending a silent clip every few minutes. But self-hosting isn't recommended by Google.
更好的解决方案可能是深入研究缩小的代码以弄清如何调用Xn(a)，因为该方法会在播放媒体时禁用超时，然后找到一种在Chromecast应用中调用该方法的方法.
A better solution may be to dig deep in the minified code to work out how Xn(a) is called as that disables the timeout whenever media is playing, and then find a way to call that from within the Chromecast app.
这篇关于Google Cast自定义接收器超时的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
