1
votes

I've been experimenting with Chromecast. I'm running into playback issues.

For the first 5-6 minutes or so, it's all right. It's all a bunch of PROGRESS, TIME_UPDATE, SEGMENT_DOWNLOADED.

player.html?cache=500:102 aj {type: "PROGRESS", currentMediaTime: 398.742094}

player.html?cache=500:102 jj {type: "SEGMENT_DOWNLOADED", downloadTime: 175, size: 33646}

player.html?cache=500:102 aj {type: "TIME_UPDATE", currentMediaTime: 398.9985}

[Violation] 'setInterval' handler took 229ms

player.html?cache=500:102 aj {type: "PROGRESS", currentMediaTime: 401.334166} `

player.html?cache=500:102 aj {type: "TIME_UPDATE", currentMediaTime: 401.510657}

cast_receiver_framework.js:48 [Violation] 'timeupdate' handler took 455ms

[Violation] 'setTimeout' handler took 1131ms

cast_receiver_framework.js:66 [440.120s] [cast.receiver.MediaManager] Time drifted: -4588.799999999999

cast_receiver_framework.js:66 [440.800s] [cast.receiver.MediaManager] Sending broadcast status message

cast_receiver_framework.js:66 [440.954s] [cast.receiver.IpcChannel] IPC message sent: {"namespace":"urn:x-cast:com.google.cast.media","senderId":":","data":"{\"type\":\"MEDIA_STATUS\",\"status\":[{\"mediaSessionId\":1,\"playbackRate\":1,\"playerState\":\"PLAYING\",\"currentTime\":408.382866,\"supportedMediaCommands\":15,\"volume\":{\"level\":1,\"muted\":false},\"activeTrackIds\":[],\"currentItemId\":1,\"repeatMode\":\"REPEAT_OFF\"}],\"requestId\":0}"}

[Violation] 'setTimeout' handler took 1043ms

[Violation] 'updateend' handler took 177ms

Most of the time, the "time drift" message matches the moment the player stops, and it's never able to recover, so I guess it's somehow related to the problem.

Then, the server will typically take more and more time to respond to chunk requests (20-60 seconds), and the playback will never resume. I'm not sure how the server part is related to the issue. It's puzzling me.

Any word of advice on how to debug this will be appreciated.

1
You should provide a sample stream and file an issue against the Cast SDK: issuetracker.google.com/…Leon Nicholls

1 Answers

0
votes

For the sake of helping others. Turns out that after a lot of testing we found that the issue described was only encountered while debugging. If a debugger is attached to the receiver, it eventually crashes. Which is inconvenient but at least we can now work our way around the issue and the customers won't be impacted.