search

jhooda / google-cast-sdk

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

SeekRequest will Seeking changes playerState to PAUSED #532

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Send a seek request
2. Before seek request finishes, send another seek request
3. MediaManager's customized status callback is called with playerState of 
"PAUSED"

What is the expected output? What do you see instead?
I would expect either no message or a new playerState introduced named 
"SEEKING." 

Once the seek resolves and playback resumes, or pauses (due to SeekResumeState 
being PAUSED). I would expect the the customized status call back's to be 
called with the appropriate playerState.

What version of the product are you using? On what operating system?
Cast Receiver 2.0.0, MPL 1.0.0

Original issue reported on code.google.com by tuc...@willowtreeapps.com on 16 Mar 2015 at 11:19

GoogleCodeExporter commented 9 years ago 
Please be specific about what is the appropriate playerState here? Do you want 
the playback to resume or pause after seek?

Original comment by na...@google.com on 17 Mar 2015 at 2:48

GoogleCodeExporter commented 9 years ago 
The overall functioning of seeking is fine, as it ultimately resolves itself. 
However, there's an extraneous broadcast of paused in the case of two seeks. 

If the first seek as a ResumeState of Playing, and the interrupting seek a 
ResumeState of Playing I would not expect as PAUSED playerState at all in the 
interim.

Original comment by tuc...@willowtreeapps.com on 17 Mar 2015 at 3:12

GoogleCodeExporter commented 9 years ago 
We can not reproduce the issue. Customized callback is not called with 
playerState of PAUSED in our tests. 
Please make sure your compilation is in sync with the updated reference 
example. You can find it here: 
https://github.com/googlecast/cast-custom-receiver. Also, make sure to use the 
latest version of receiver SDK and MPL.

Original comment by na...@google.com on 23 Mar 2015 at 8:44