The "Google Play Services" library contains an integrated fallback system in case of lost packets?
Here is the problem. I have a app that works like this:
The player A sends a reliable message to the player B
The player A can not send another message as long as the player B has not returned a callback via a reliable message.
If the callback takes too long or is negative, the game is disconnected.
Thereby I ensure that the game always remains synchronized.
The problem is that sometimes, when the connection is poor, the player B's game get suddenly a few steps back (usually 3 to 5).
The interesting thing is that this application has no methods to get back this way, and that it remains connected after this, although it's out of sync.
I have found nothing in the official documentation.
Did one of you already experienced this issue?
Related
I have integrated the latest cast SDK within my Android application. It does play media correctly and I'm able to control the playback via on-screen controls as well as via the status bar notification and lock-screen.
I have received, though, reports from some users saying that after a while listening to the media via cast, when their devices went to sleep/got locked, they were not in sync with the receiver anymore as well as losing the possibility of controlling the playback.
I was not able to consistently reproduce the issue (since forcefully locking the device keeps the connection for a while), but I could see it happening a number of times and was able to catch logs for one of them.
At first, I was suspecting that the receiver's messages were not arriving to the sender (android app), but the Google Home application works flawlessly and updates the metadata and playback controls correctly. So, the pain point must be in my application.
I did notice that, while in that "inconsistent state", I am still able to read logs after a track finishes (so, change of state) as follows:
02-05 00:02:08.958 16642-27384/? W/CastDeviceController: [controller-0335 API] Ignoring message. Namespace 'urn:x-cast:com.google.cast.media' has not been registered.
Do I need to register that protocol within my application? (I do use a custom protocol to send messages - and if I'm not mistaken, the "unregistered protocol" is the default one - shouldn't it be automatically registered?). If so, how can I perform that registration?
Any help will be appreciated.
I have an Android app using the CastCompanionLibrary v2.9.1, modified to use play-services-cast:10.0.1 (just a simple change to the gradle dependencies).
Short version: The app is attempting to automatically connect to the ChromeCast device, without user interaction.
Long version:
Since updating the CCL library to use play services 10.0.1, I've had several users mention that the app is automatically connecting/casting to ChromeCast without user interaction.
Some users have said they're not using the app, then they connect to WiFi, and the app automatically attempts to cast. Others have said they are using the app, they don't press the ChromeCast button, and the app begins casting.
--
I'm having trouble figuring out where to look for potential changes to the ChromeCast APIs which might explain what's going on. I'm also not sure whether this issue is only occurring for my app, or for many other ChromeCast enabled apps. Lastly, I'm not able to reproduce this issue on my own ChromeCast device.
Any help would be appreciated.
I had not seen or heard this before, so here are some pointers for you to do further investigation to see what can be the cause. CCL has a (sticky) service called ReconnectionService that is responsible to perform reconnection attempts when you lose wifi and later gain it back. The wifi scenario you had mentioned resembles this so I would suggest to start from there. In order to only reconnect when it makes sense, it gets the time length of the content that is playing and only makes such attempts for that period of time; i.e. if you start playing a content that is for 1 hr and then you leave your phone on the table and pick it up after 2 hrs, it notices that the last movie before it fell sleep was for 1 hr so it won't make any attempt to reconnect (see handleTermination() in that same class). For live-stream that doesn't have a clear content duration, CCL uses a default of 2hrs but allows apps to modify that by calling VideoCastManager.setLiveStreamDuration(duration_in_seconds) method. Finally, the whole reconnection relies on a few factors: it saves the route-id of the last connection, along with the session ID. So if needed, you can clear any of these and then it won't try to reconnect for that particular session (in case you want to keep reconnection for some and disable on some other). Hope these help to troubleshoot the issue.
So it turns out there's a bug in Android Support Library 25.1.0 which was causing this issue.
https://code.google.com/p/google-cast-sdk/issues/detail?id=1105
Which is now marked as 'fixed internally'.
Also related:
https://code.google.com/p/android/issues/detail?id=232326
I am writing a multiplayer game and if I start the app from a desktop icon and another player takes a turn then the game updates correctly via the UpdateMatchResult callback. However, if I don't have the app open and get a notification that a turn has been taken by Google Play Games, then if I respond to that notification and use Google Play Games to take me to the match in my app, then if I take a turn and await an update after another player takes a turn, I continue to get notifications, even though I am actually in the app.
What could be causing this? Ideally, I'd like to see the update in the game, as I do when I go in via the normal icon.
This was a simple coding issue. I have solved this now.
I previously developed an android sender app with the preview SDK and found that when a Chromecast was turned on or off, the app very quickly discovered this and changed the state of the media route button.
However with the new SDK, if a Chromecast is unplugged while the app isn't connected to it, MediaRouter.Callback.onRouteUnselected() is never called and the Cast icon remains visible. In some cases even if the app is closed and opened again, onRouteAdded is called on startup with the details of the previously connected Chromecast, even though it's not plugged in anymore and hence not on the network, which suggests that there's some kind of cache somewhere.
I'm noticing this both with my own app (which uses the companion library) and the example CastVideos-android app on github. This sets up the callback like so:
mMediaRouter = MediaRouter.getInstance(context);
mMediaRouteSelector = new MediaRouteSelector.Builder().addControlCategory(
CastMediaControlIntent.categoryForCast(mApplicationId)).build();
mMediaRouterCallback = new CastMediaRouterCallback(this, context);
mMediaRouter.addCallback(mMediaRouteSelector, mMediaRouterCallback,
MediaRouter.CALLBACK_FLAG_PERFORM_ACTIVE_SCAN);
This results in a pretty rough user experience - is there any way I can improve it? Perhaps some flag that I can pass that'll perform an even more active scan than CALLBACK_FLAG_PERFORM_ACTIVE_SCAN, hence detecting Chromecasts that are no longer on the network? Or perhaps some method that I can hit at intervals to scan again and make sure the chromecast is still there? I've had a look through the API but I can't see anything.
EDIT: Worse still, I've also noticed that if a Chromecast is unplugged then you attempt to cast to it, it will disconnect (good) but won't detect the Chromecast when it's plugged back in. This is true even if you get out of the app and start it up again.
The behavior you have outlined is caused by a bug in the SDK that is going to be addressed in the next release of the Google Play services.
I have a video app (client a) that streams and receives audio via flash media server. It also does constant server side polling to maintain an engagement via an adobe air desktop app (client b) which does the same. The problem I'm having is that:
- 90% of the times when client b ends the engagement the app in client a force closes.
- 5% I have seen the app force close from when client a ends the engagement.
- works fine in gingerbread. Doesn't in honeycomb+
Debug doesn't throw anything, logcat throws an error that consumer closed the input...
I have isolated the problem to my flash media server class, however I am not doing anything different than any other connection class.
Has anyone ever experienced this issue? Like I said itworks fine in gingerbread...
Any pointers would be great.been banging my head against the wall for 2 weeks now and counting
Took a while to find the issue but in the end it was an issue in the fms server.
I was running a function at an interval to check for user timestamps among other things, however when the engagement was being finished by client b, the timestamp was stillt rying to run and disconnect a user, even though the connection was already closed.
Once I got that sorted the issue went away.
It is still weird how this issue wasnt affecting android 2.x devices...
This is probably not going to be very helpful to many people, however if you do see your app force closing, and one of the last messages your app receives is down to the fms, have a check for something your doing in the .asc file in your fms.
Unfortunately learnt this the hard way, spent 3 weeks looking at my code, thinking it was something it was doing or some kind of bug...
Glad I was wrong!