我一直在为Chromecast开发接收器和网络发送器（Chrome）应用程序一段时间，自从新API（昨天公开发布）以来，我在执行loadMedia后无法接收任何媒体状态更新请求。
刷新页面后，我能够按预期接收更新，但两个通道都以完全相同的方式接收媒体会话对象，并在其上执行完全相同的方法（addUpdateListener）
我们正在接收方使用HLS流，但我可以看到发送给发件人的更新（显然它们是重载，允许网络发送者接收它们）。此外，在发送方，我可以在执行播放/暂停/音量/静音和搜索请求等操作时看到更新，但每次操作后只能进行一次更新。
TL; DR ：看不到任何常规媒体状态更新，例如loading-＆gt; buffering-＆gt;播放，我甚至看不到播放/暂停/来自连接到会话的其他发件人的卷/ etc更新。
以下是我在发送任何状态更新之前从发件人那里得到的全部内容：
[chrome.cast.ApiImpl]从扩展程序获取消息： { “类型”： “v2_message”， “消息”：{ “类型”： “MEDIA_STATUS”， “状态”：[{ “mediaSessionId”：1， “playbackRate”：1， “playerState”： “缓冲”，“currentTime的“：500，” supportedMediaCommands “：15，” 体积 “：{” 电平 “：1，” 静音 “：假}，” 媒体 “：{除去}”， “流类型”：“缓冲”， “的contentType”： “的contentType”， “元数据”：NULL， “持续时间”：1450.1558329999993 “的CustomData”：NULL} “的sessionId”： “FD5AA3F0-F93C-050A-4900-7C6D916525BA”}]， “的requestId” ：92278937}， “SEQNUM”： “a14772002”， “的clientId”：空， “appOrigin”：空} [chrome.cast.ApiImpl]创建新的Media对象： FD5AA3F0-F93C-050A-4900-7C6D916525BA：1 cast_sender.js：3428新媒体 会话ID：1（loadMedia）
但是我可以告诉接收器仍然通过查看调试控制台发送更新，其中有一些是关闭的：
[245.485s] [cast.receiver.IpcChannel]发送的IPC消息： { “命名空间”： “瓮：X-铸：com.google.cast.media”， “senderId”： “：”， “数据”： “{\” 类型\ “：\” MEDIA_STATUS \”，\ “状态\” ...已删除 [247.495s] [cast.receiver.MediaManager]发送广播状态消息
我还注意到，当我在loadMedia回调之前收到消息时，它们都处于BUFFERING状态，从不播放
答案 0 :(得分：2)
此错误已得到确认，并且已于2月10日更新Cast扩展程序时修复。
旧的解决方法：
目前针对此类问题有一种解决方法，即接收方应用的状态更新会路由到Chrome Cast扩展程序，但不会路由到Chrome发送方应用。
现在看到来自接收器应用程序的传入状态更新的技巧是打开至少2个运行相同发件人应用程序的选项卡。您从其中一个选项卡启动会话，然后从另一个选项卡加入该会话。现在，来自接收器应用程序的任何状态更新消息都不会被Cast扩展程序拦截。
答案 1 :(得分：1)
我看到这个bug已经在2月10日更新时修复了，但是我没有看到currentTime事件。来自文档 -
对以下属性的更改将触发侦听器： currentTime ，音量，元数据，playbackRate，playerState，customData。
我们是否希望在时间变化时获得更新？