arabenseifer / google-cast-sdk

Automatically exported from code.google.com/p/google-cast-sdk
0 stars 0 forks source link

resumeState is missing in onSeek event #184

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. make SeekRequest with chrome sender
2. check MediaManager onSeek callback arguments in receiver

What is the expected output? What do you see instead?
event.data.resumeState is missing

Please provide any additional information below.
the property is documented in the custom receiver example app:
https://github.com/googlecast/cast-custom-receiver/blob/09c5a3edde69dba0394a164d
504736136c5ec4a0/sample_media_receiver.html#L469-L487

also the link to cast.receiver.media.SeekResumeState on this page is broken:
https://developers.google.com/cast/docs/reference/receiver/cast.receiver.MediaMa
nager.SeekRequestData
(there is a "#" in the middle of the url, I've found a couple of this in the 
documentation)

when I correct the url, the page is missing information about the different 
constants:
https://developers.google.com/cast/docs/reference/receiver/cast.receiver.media.S
eekResumeState

Why I need the resumeState property:
when the seeking is done ("seeked" event on the media element is triggered), I 
need to know if the player was paused or not before seeking

Original issue reported on code.google.com by p...@zattoo.com on 4 Mar 2014 at 10:59

GoogleCodeExporter commented 9 years ago
any news on this?

this issue is causing the bug that when you pause the stream first and then do 
a seek, the player doesn't know the player is paused and just keeps displaying 
"seeking" even when the seeking is already done. but when I listen to the html5 
seeked event, I don't know if I should show the pause screen because of the 
missing information

Original comment by p...@zattoo.com on 18 Mar 2014 at 9:43

GoogleCodeExporter commented 9 years ago
First of all: event.data.resumeState is missing

This is not typically set in our samples but when you create a seek request, 
you can specify this field as follows.

  var request = new chrome.cast.media.SeekRequest();
  request.currentTime = pos * currentMediaSession.media.duration / 100;
  request.resumeState = chrome.cast.media.PlayerState.PAUSED;  
  currentMediaSession.seek(request,
    onSeekSuccess.bind(this, 'media seek done'),
    onError);

"the bug that when you pause the stream first and then do a seek, the player 
doesn't know the player is paused and just keeps displaying "seeking" even when 
the seeking is already done. but when I listen to the html5 seeked event, I 
don't know if I should show the pause screen because of the missing information"

I verified that when seeking is initiated from sender, the following happens on 
receiver:

 - window.mediaManager.onSeek
 - window.mediaElement.addEventListener('seeking',
 - window.mediaElement.addEventListener('seeked',

If sender paused video before seeking, after seeked event, receiver stays 
paused.  If sender is playing video, receiver continues to play video after 
seeked event.  Everything looks good.  

If you think there's an issue, please provide more info.

Original comment by shawns...@google.com on 20 Mar 2014 at 7:01

GoogleCodeExporter commented 9 years ago
oh I didn't understand that I can/must set resumeState myself. I thought this 
property just represents the previous state out of the box.

ok then this is what I wanted:
seekRequest.resumeState = media.playerState;
this works good.

one last problem:
on the receiver side, cast.receiver.media.SeekResumeState.PLAYBACK_START and 
cast.receiver.media.SeekResumeState.PLAYBACK_PAUSE are undefined which I guess 
is a bug.
as a workaround I will use cast.receiver.media.PlayerState.PLAYING and 
cast.receiver.media.PlayerState.PAUSED for checking the resumeState which is 
working fine

Original comment by p...@zattoo.com on 21 Mar 2014 at 9:53

GoogleCodeExporter commented 9 years ago
any news about the constants bug?

Original comment by p...@zattoo.com on 4 Apr 2014 at 11:42

GoogleCodeExporter commented 9 years ago
Found out that they have been defined but need to be exposed.  Meanwhile you 
may use the following workaround:

if (!cast.receiver.media.SeekResumeState.PLAYBACK_START) {
  cast.receiver.media.SeekResumeState.PLAYBACK_START = 'PLAYBACK_START';
}

if (!cast.receiver.media.SeekResumeState.PLAYBACK_PAUSE) {
  cast.receiver.media.SeekResumeState.PLAYBACK_PAUSE = 'PLAYBACK_PAUSE';
}

Original comment by shawns...@google.com on 4 Apr 2014 at 5:39

GoogleCodeExporter commented 9 years ago
is this fixed?

Original comment by p...@zattoo.com on 6 May 2014 at 7:02

GoogleCodeExporter commented 9 years ago
This has been fixed in previous updates.

Original comment by and...@google.com on 11 Nov 2014 at 10:57