When trying to stream audio/video on a chromecast device in 50% of cases I get mediaControlChannel:requestDidFailWithID:error: method called about 100 times for the same BEChromeCastMediaItem before it actually starts streaming just fine.
Error Domain=com.google.GCKError Code=4 "The operation couldn’t be completed. (com.google.GCKError error 4.)
(Actually it looks like the whole time I see a "blue progress line" in TV I keep receiving callbacks with this error in the client)
What should we do in such cases? Normally when you get notified about an error, you should handle it (i.e. let user know that something failed) and it's up to you to decide if you want to retry or not, but it looks like chrome cast decides it for you and retries automatically until it succeeds. So what is expected of the iOS client? Should we just ignore these calls?
Update: Error codes seem to change (I also got 1, 93) but they are a always the same for one media item. Anybody knows where to look up error codes? Class chrome.cast.Error does not have any info on this.
There are some descriptions here:
https://developers.google.com/cast/docs/reference/ios/g_c_k_error_8h#aea7a716be62f301015e255e1ba63a9cc
Error code 4 you mentioned looks like it means that an invalid request was made.
If you happen to be programming for iOS, in the GCKError.h file, I found there are some additional error codes:
typedef NS_ENUM(NSInteger, GCKErrorCode) {
/**
* Error code indicating a network I/O error.
*/
GCKErrorCodeNetworkError = 1,
/**
* Error code indicating that an operation has timed out.
*/
GCKErrorCodeTimeout = 2,
/**
* Error code indicating an authentication error.
*/
GCKErrorCodeDeviceAuthenticationFailure = 3,
/**
* Error code indicating that an invalid request was made.
*/
GCKErrorCodeInvalidRequest = 4,
/**
* Error code indicating that an in-progress request has been cancelled, most likely because
* another action has preempted it.
*/
GCKErrorCodeCancelled = 5,
/**
* Error code indicating that the request was disallowed and could not be completed.
*/
GCKErrorCodeNotAllowed = 6,
/**
* Error code indicating that a requested application could not be found.
*/
GCKErrorCodeApplicationNotFound = 7,
/**
* Error code indicating that a requested application is not currently running.
*/
GCKErrorCodeApplicationNotRunning = 8,
/**
* Error code indicating the app entered the background.
*/
GCKErrorCodeAppDidEnterBackground = 91,
/**
* Error code indicating a disconnection occurred during the request.
*/
GCKErrorCodeDisconnected = 92,
/**
* Error code indicating that a request could not be made because the same type of request is
* still in process.
*/
GCKErrorCodeDuplicateRequest = 93,
/**
* Error code indicating that a media load failed on the receiver side.
*/
GCKErrorCodeMediaLoadFailed = 94,
/**
* Error code indicating that a media media command failed because of the media player state.
*/
GCKErrorCodeInvalidMediaPlayerState = 95,
/**
* Error code indicating that the application session ID was not valid.
*/
GCKErrorCodeInvalidApplicationSessionID = 96,
/**
* Error code indicating that an unknown, unexpected error has occurred.
*/
GCKErrorCodeUnknown = 99,
};
Related
I am running computer vision algorithms on a video feed I'm getting in real time. I'm running these operations/algorithms using DispatchQueue asynchronously. However, I am getting the following error, which I cannot interpret:
[MTLDebugComputeCommandEncoder dispatchThreadgroups:threadsPerThreadgroup:]:949: failed assertion (threadgroupsPerGrid.width(0) * threadgroupsPerGrid.y(12) * threadgroupsPerGrid.depth(1))(0) must not be 0.'
What is this error?
This message is stating that there was an assertion failure caused by an assertion in [MTLDebugComputeCommandEncoder dispatchThreadgroups:threadsPerThreadgroup:].
As far as I understand it, it was asserted that this expression:
threadgroupsPerGrid.width * threadgroupsPerGrid.y * threadgroupsPerGrid.depth
should not be 0, but it was 0, causing this assertion failure. Additionally, they've annotated the values of these variables:
threadgroupsPerGrid.width was 0
threadgroupsPerGrid.y was 12
threadgroupsPerGrid.depth was 1
threadgroupsPerGrid.width * threadgroupsPerGrid.y * threadgroupsPerGrid.depth evaluated to 0
This invalid state is likely a result of you passing invalid arguments to [MTLDebugComputeCommandEncoder dispatchThreadgroups:threadsPerThreadgroup:]. If I had to guess, the issue is probably that threadgroupsPerGrid.width was 0.
I had zero warnings, then I updated to Firebase 4.0 now I have two warnings within GeoFire that won't go away.
Warnings
.../Pods/GeoFire/GeoFire/API/GeoFire.h:108:11: Empty paragraph passed to '#return' command
.../Pods/GeoFire/GeoFire/API/GeoFire.h:108:5: '#return' command used in a comment that is attached to a method returning void
GeoFire Code
- (void)removeKey:(NSString *)key withCompletionBlock:(GFCompletionBlock)block;
/**
* Gets the current location for a key in GeoFire and calls the callback with the location or nil if there is no
* location for the key in GeoFire. If an error occurred, the callback will be called with the error and location
* will be nil.
*
* #param key The key to observe the location for
* #param callback The callback that is called for the current location
* #return <- WARNINGS GIVEN ON THIS LINE
*/
Does anyone have any information about this or at least how to silence safely. On attempt to remove comment it says GeoFire is locked for editing.
In the <GCKDeviceManagerDelegate> Protocol I see two very similar methods:
/**
* Called when the connection to the device has been terminated. It is safe to release the
* GCKDeviceManager object from within this callback.
*
* #param deviceManager The device manager.
* #param error The error that caused the disconnection; nil if there was no error (e.g. intentional
* disconnection).
*/
- (void)deviceManager:(GCKDeviceManager *)deviceManager
didDisconnectWithError:(NSError *)error;
and
/**
* Called when disconnected from the current application.
*
* #param deviceManager The device manager.
* #param error The error that caused the disconnect, or <code>nil</code> if this was a normal
* disconnect.
*/
- (void)deviceManager:(GCKDeviceManager *)deviceManager
didDisconnectFromApplicationWithError:(NSError *)error;
Is deviceManager:didDisconnectWithError: called if the Chromecast receiver is disconnected or loses connection to the application, and deviceManager:didDisconnectFromApplicationWithError: called when the application tries to disconnect from the Chromecast receiver?
What are the use-cases when each delegate method would be called?
A sender application can connect to a cast device and upon successful connection can launch a receiver application on the cast device. So "connecting to a device" and "running an application" are two separate actions, so are "stopping the receiver application" and "disconnecting" from the cast device. As such, there are those two separate methods.
Hi i need to get current signal handler that was set with this method:
signal(SIGSEGV, handler);
How to do that?
Unfortunately, the C standard does not foresee reading the current value of the handler.
But fortunately signal() returns the previous value when you change the handler. Hence with a slight risk you could do:
typedef void (*sighandler_t)(int); /* for convenience */
sighandler_t current_handler;
current_handler = signal(SIGSEGV, SIG_IGN); /* (1) */
signal (SIGSERV, current_handler); /* (2) */
There are two risks:
There could be a (very unliklely) error causing signal() to return SIG_ERR. You would then lose the current handler for good! According to iOS man page above, and based on the signal value you're interested in, the conditions for errors are not met.
If a SIGSEGV would be raised between (1) and (2) you would not intercept it. However, looking at the two statements, they are unlikely to trigger a segmentation violation (SIGSEGV)
In my application I connect to a server using
- (void)connectToServerUsingCFStream:(NSString *) urlStr portNo: (uint) portNo
This function is called by another method
- (void)connectToServer:(NSString *)serverName onPort:(int)portNo
{
[self connectToServerUsingCFStream:serverName portNo:portNo];
while (!((iStream.streamStatus == 2) || (oStream.streamStatus == 2))) {
continue;
}
NSLog(#"Streams connected");
[self sendLoginRequest];
}
Now I want to know wether there is an easy possibility to check if my connection request is timed out (maybe with a certain time value?). Is there a way to handle this in my while loop or should I use something different?
Thanks in advance,
Bautzi
I have no idea how you exactly implement the connection, but here I have some connection codes from the XMPPFramework , as the code comments:
/**
* XMPPReconnect handles automatically reconnecting to the xmpp server due to accidental disconnections.
* That is, a disconnection that is not the result of calling disconnect on the xmpp stream.
*
* Accidental disconnections may happen for a variety of reasons.
* The most common are general connectivity issues such as disconnection from a WiFi access point.
*
* However, there are several of issues that occasionaly occur.
* There are some routers on the market that disconnect TCP streams after a period of inactivity.
* In addition to this, there have been iPhone revisions where the OS networking stack would pull the same crap.
* These issue have been largely overcome due to the keepalive implementation in XMPPStream.
*
* Regardless of how the disconnect happens, the XMPPReconnect class can help to automatically re-establish
* the xmpp stream so as to have minimum impact on the user (and hopefully they don't even notice).
*
* Once a stream has been opened and authenticated, this class will detect any accidental disconnections.
* If one occurs, an attempt will be made to automatically reconnect after a short delay.
* This delay is configurable via the reconnectDelay property.
* At the same time the class will begin monitoring the network for reachability changes.
* When the reachability of the xmpp host has changed, a reconnect may be tried again.
* In addition to all this, a timer may optionally be used to attempt a reconnect periodically.
* The timer is started if the initial reconnect fails.
* This reconnect timer is fully configurable (may be enabled/disabled, and it's timeout may be changed).
*
* In all cases, prior to attempting a reconnect,
* this class will invoke the shouldAttemptAutoReconnect delegate method.
* The delegate may use this opportunity to optionally decline the auto reconnect attempt.
*
* Auto reconnect may be disabled at any time via the autoReconnect property.
*
* Note that auto reconnect will only occur for a stream that has been opened and authenticated.
* So it will do nothing, for example, if there is no internet connectivity when your application
* first launches, and the xmpp stream is unable to connect to the host.
* In cases such as this it may be desireable to start monitoring the network for reachability changes.
* This way when internet connectivity is restored, one can immediately connect the xmpp stream.
* This is possible via the manualStart method,
* which will trigger the class into action just as if an accidental disconnect occurred.
**/
I don't know if this XMPPReconect class meets your demand.