Chromecast API - Statusupdatelistener callback delay issue.

[GoogleCodeExporter]

I'm working on chromecast apps and observed below issues while debugging the 
sender app:

If I schedule an event at specific time, the event is applied with some delay 
in chromecast and also it was notifying to statusupdate listener about 600 
milliseconds late.

Let me explain with an example:

    1.Suppose we have an event at ’00:21:33:400’ (hh:mm:ss:ms), when we trigger the event exactly at specific given time we observed that it is applied late in Chromecast (approximately 600 milliseconds) that is the reason we are triggering event signals 600 milliseconds before the exact event time.

    2.And also observed that sometimes chromecast device is notifying the media status updates very late (i.e.. not triggering the ‘StatusUpdate’ callback) when event applied. Due to this app may not schedule the successive event if chromecast is updated with the streaming position which is greater than the next event start time. That is if next event is there at ’00:21:34:100’ time and if chromecast is notified with the streaming position ‘00:21:34:300’, in this case app will ignore the event and schedule/find the next successive event which is greater than the ‘00:21:34:300’ streaming position.

Actually I'm using default receiver application to play the video (using 
CastMediaControlIntent.DEFAULT_MEDIA_RECEIVER_APPLICATION_ID). 

For (1) My main intention is to apply mute/un-mute events at specific given 
time codes. Sender application will send mute/un-mute messages to chromecast 
device but they are applying very late. 

For (2) When any event (mute/un-mute) executed in chromecast device my sender 
app should be notified to StatusUpdateListener immediately where in which I'm 
scheduling the next event to be applied. But StatusUpdateListener is calling 
very late after the event executed.

My sender application should be notified as soon as any mute/un-mute event is 
executed in 'default receiver' app running in chromecast. Actually I'm getting 
this delay only when sender app is in background whereas it is working fine in 
foreground, I tried to acquire WifiLock and WakeLock but still no use. 

I have tried a lot to fix this issue, Can you please help me out on this.

Logs:

# scheduleTaskToApplyEvent # timeDifference:00:00:36.049 # seconds:36 # 
milliSec:49
# >>>>>### Scheduled 'Mute' event to execute exactly at 00:00:48.395 time frame 
 # currentStreamPos:00:00:12.346 # Time difference: 00:00:36.049
applyMute # (~500):00:00:48.395 # SysTime: 1420453033539
>>>>>### Applied MUTE
StatusUpdate # MUTE event applied:00:01:00.644 # SysTime: 1420453033873
===========================================================
Current Position of Video 60644 ms 00:01:00.644
>>>>> Player is in MUTE state
if notified after the un-mute event position
applyUnMute # :00:00:50.494 # SysTime: 1420453033880
>>>>>### Applied UN-Mute 
StatusUpdate # UN-MUTE event applied:00:01:00.644 # SysTime: 1420453034311
===========================================================
Current Position of Video 60644 ms 00:01:00.644
>>>>> Player is in UN-MUTE state

# >>>>>### Scheduled 'Mute' event to execute exactly at 00:01:10.226 time frame 
 # currentStreamPos:00:01:00.644 # Time difference: 00:00:09.582
applyMute # (~500):00:01:10.226 # SysTime: 1420453045451
>>>>>### Applied MUTE
StatusUpdate # MUTE event applied:00:01:12.823 # SysTime: 1420453048444
===========================================================

Original issue reported on code.google.com by venu7...@gmail.com on 8 Jan 2015 at 7:28

[GoogleCodeExporter]

Issue 480 has been merged into this issue.

Original comment by na...@google.com on 8 Jan 2015 at 6:05

[GoogleCodeExporter]

Can you use a Styled receiver instead of the default one?  That way, you can 
enable logging and figure out the timing of when the receiver gets the message 
from the sender and when the receiver sends the status update back to the 
sender.  Providing those logs would be helpful for us to find out where the 
issue lies.  You can find more information about the Styled receiver here: 
https://developers.google.com/cast/docs/styled_receiver

Original comment by jonathan...@google.com on 9 Jan 2015 at 9:42

• Changed state: NeedInfo

[GoogleCodeExporter]

I think its not required to code the Styled Receiver for our instance. Let me 
give you brief explanation about our sender app behavior:

Actually our sender app will join to the YouTube session that is running in the 
ChromeCast Device. For your information, user will cast videos using YouTube 
app and then user will start our sender application to join to the session 
which is already running in the chromecast (i.e. session started by YouTube 
app), used 
"Cast.CastApi.joinApplication(mApiClient).setResultCallback(connectionResultCall
back);" 

Inside the 'connectionResultCallback', sender app will fetch the 
currentStreamingPosition of the youtube video and from there on-wards sender 
app will schedule filter events(mute/un-mute) for the specific video. 

Please suggest...

Original comment by someswar...@gmail.com on 12 Jan 2015 at 11:11

[GoogleCodeExporter]

Is it possible to debug the 'Default Receiver' application as we do for 'Styled 
Receiver' apps? 

Original comment by someswar...@gmail.com on 12 Jan 2015 at 11:20

[GoogleCodeExporter]

You cannot debug a Default receiver. In this case, you are using YT receiver 
and unless you have your own receiver to be able to debug, we won't be able to 
provide you further assistance.

Original comment by anad...@google.com on 12 Jan 2015 at 3:53

• Changed state: Invalid

[GoogleCodeExporter]

Thanks for your response. 
Actually I haven't looked into receiver applications development area. I'm 
trying to code some simple receiver app to listen the events and sending the 
status of media player. Please suggest me any sample receiver app which will do 
the same.

Please clarify and suggest me on below things, it would be very helpful for me 
to investigate this issue: 
1) As my sender app receiving StatusUpdate callbacks very late, will it depends 
on wi-fi adapter speed OR do we have any other areas which will cause this 
delay issue? 

2) Is it required to set the WakeLock mode for sender app in-order to attain 
the CPU attention when app in background? And I did not find any method to set 
WakeLock for RemoteMediaPlayer object as we do for android MediaPlayer object. 

3) I observed that sometimes I'm getting inappropriate media streaming position 
from the receiver app even I kept sender app in foreground.

Original comment by someswar...@gmail.com on 16 Jan 2015 at 10:20

[GoogleCodeExporter]

Hi All, 

Finally I resolved my issue.
I verified the above issue by debugging the logs in styled receiver and 
observed that there is no delay. 

Rather in sender application I used different method to get the current media 
streaming position. 

i.e. 'mRemoteMediaPlayer.getApproximateStreamPosition()' - It was giving me the 
exact streaming position both in foreground and background. 

whereas previsously I used 'mediaStatus.getStreamPosition()' method but 
sometimes its giving me the inaccurate streaming position.

Original comment by chromeca...@gmail.com on 30 Jan 2015 at 1:39