Recently we started receiving next warning:
[cast.framework.media.ShakaPlayer]
autoResumeNumberOfSegments is not supported for Shakaplayer.
Its value will be ignored
this caused regression in live stream loading time
Was this setting changed to something else?
How we can adjust buffering level now?
ok, it was never supported and documentation of playback config is wrong
Related
We use EventStore 5.0.0 and we faced with the following situation:
when we store event, sometimes, C# client receives response with error. Error from log:
EventStore.ClientAPI.Exceptions.WrongExpectedVersionException: Append failed due to WrongExpectedVersin. Stream: QWE.Api.SomeClassifier.Actors.ProductInfoActors.ProductActor-q5839583-5r82-5k30-sl13-1t485329g395, Expected version: 13, CurrentVersion:14
Disregard this response with error, event is stored with version 14.
What could it be the reason of this error message, while event was really stored?
We think the problem is in slow ssd, or high load.
This is the database built-in optimistic concurrency check. You can find more about it here: https://developers.eventstore.com/clients/grpc/appending-events/#handling-concurrency
I have a very tremendous issue in my app. App is using webrtc to create video connection between two people.
Currently the app it's in the test phase.
Everything is working fine on Chrome, but on Firefox there is a strange issue.
When the second Peer connects I receive this error:
Error adding ice candidate for pcInvalidStateError: setRemoteDescription needs to called before addIceCandidate
I know that the error message seems to be clear, but how it's possible that on Chrome this error does not exist?
I mean, maybe there is a bigger issue, not completely depending on this error message.
Do you have any ideas or solutions to this?
A part from WebRTC doc: (See Deprecated Exception section)
Deprecated exceptions
When using the deprecated callback-based version of
setRemoteDescription(), the following exceptions may occur:
InvalidStateError The connection's signalingState is "closed",
indicating that the connection is not currently open, so negotiation
cannot take place.
You should check you are not using deprecated callback version of this function. Also you should keep an eye on signalingState of the peer connection.
Hope it helps!
I've tried many samples, the only one which works is from
https://code.google.com/p/android-rtmp-client/source/browse/trunk/example/com/ryong21/example/publisher/PublishClient.java
But it doesn't compatible with latest server side code.
This sample use a org.red5.server.stream.provider.FileProvider to read a local video file whose constructor has changed from FileProvider(File file) to FileProvider(IScope scope,File file). I'm not quite sure how to make the scope argument, neither null nor "new GlobalScope" works.
And another issue, even with the working example, it only works with red5 server but not with
youtube rtmp server. Any ideas?
Edit:
I finally get it worked by making scope like this
http://pastebin.com/jnwv1ewd
But it still doesn't work with youtube, the error msg is
"1418 INFO o.r.server.net.rtmp.RTMPHandshake - Processing server response for encryption
1420 WARN o.r.server.net.rtmp.RTMPHandshake - Type 0 digest comparison failed, trying type 1 algorithm"
Handshake failed?
That message means that one of the two handshake validation routines failed; not that the whole thing failed. YouTube RTMP has special requirements and you must meet or exceed a given number of subscribers before you are allowed to access it.
As stated I get R14 errors on Heroku recently. This happens even setting max heap to e.g. 300M.
FYI: On my local machine the process never exceedes 400M, the heap is - even under load testing - never bigger then 250M. I use Scalate as templating engine.
Any ideas why this happens and how to solve it?
play 2.2.0 had an issue with the case sensitivity of JAVA_OPTS, that's why your memory configuration wasn't honored. see this thread https://github.com/playframework/playframework/pull/1928
it was fixed in play 2.2.2, so I guess this is no longer an issue
A customer is reporting a connection failure with a strange profile: it apparently only fails for the very first URL request via CFNetwork since the app has launched.
The error code apparently being returned by CFNetwork is domain CFStreamErrorHTTP, but with error code -4, which does not correspond to any publicly defined error code for this domain.
In CFHTTPStream.h, the publicly defined error codes for CFStreamErrorHTTP end auspiciously at -3, strongly hinting that -4 may be an error code that Apple is using but which has not yet been publicly documented.
Any idea what's going on here? Has anybody else seen this error code and found rhyme or reason for it?
Probably not the final answer and this may have changed since they closed sourced CFNetwork, but I did find the following online which indicates that -4 is a connection lost error.
http://www.opensource.apple.com/source/CFNetwork/CFNetwork-129.9/HTTP/CFHTTPConnection.c
I guess you'll have to show some of the code that's failing, but a few questions spring to mind. First, can you trace this issue yourself, can you reproduce it? In particular, it would be interesting to see on which thread this happens, and what's the current runLoop mode. It could be indicative of a stream or connection that fails scheduling on the internal CF runloops.
Other than this (and it's a shame CFNetwork is no longer publicly updated), it could be a zillion things, but you'll need to log as much information as you can if you can't directly debug the failure (hint hint -- https://github.com/fpillet/NSLogger can help you remotely log the info from the client).
Finally, ask the question on Mac Dev Forums (or iOS Dev Forums if your code runs on iOS). Ping Quinn, He Knows It All. Once he can't publicly answer the question, open a DTS incident and send him the ticket #. He's the guy you want to look into your problem :-)