I use videojs and videojs-contrib-hls to play video in my website.
When a video's m3u8 file is loaded successfully and the broswer failed to get one of the ts file, videojs will retry over and over again, with log like this:
GET https://[my ts file url] 404(Not Found)
VIDEOJS: WARN: Problem encountered with the current HLS playlist. Trying again since it is the final playlist.
I want to listen to the error event and limit the retry.
Which event(on the player or .tech().hls) should I listen to?
The videojs-http-streaming.js plugin (now included with videojs) has an undocumented event called "retryplaylist", you might try something like:
let retries = 0;
player.tech_.on('retryplaylist', () => {
retries++;
if (retries>=5)
// do something
});
Related
I'm working on an Expo project where users will take videos and upload them for organization and viewing them. I've been trying to upload videos taken using the expo-camera API to a storage bucket in AWS. I've been using the expo-file-system's upload in background functionality to upload videos, but I've come across an error that I don't have any idea how to handle. It generally happens the bigger the video is, and if it is over a minute, the app is likely to crash when I start to upload. Here is the FileSystem function call I make to upload the video:
FileSystem.uploadAsync(awsurl, localVideo, {
successActionStatus: 201,
sessionType: FileSystem.FileSystemSessionType.BACKGROUND,
httpMethod: 'POST',
fieldName: 'file',
mimeType: 'video/mov',
uploadType: FileSystem.FileSystemUploadType.MULTIPART,
parameters: awsparams
})
and here is the error that is occurring
Error: Unable to upload the file: 'Error Domain=NSURLErrorDomain Code=-997 "Lost connection to background transfer service" UserInfo={NSErrorFailingURLStringKey=https://s3.us-west-2.amazonaws.com/{{bucket}}, NSErrorFailingURLKey=https://s3.us-west-2.amazonaws.com/{{bucket}}, _NSURLErrorRelatedURLSessionTaskErrorKey=(
"BackgroundUploadTask <40D1EB30-0F5E-457B-8A19-18610D4A6C3A>.<1>"
), _NSURLErrorFailingURLSessionTaskErrorKey=BackgroundUploadTask <40D1EB30-0F5E-457B-8A19-18610D4A6C3A>.<1>, NSLocalizedDescription=Lost connection to background transfer service}'
I've tried multiple combinations of fieldName, mimeType and uploadType, but have had no success in getting large uploads to work. Any ideas how to fix this or effective ways to debug would be great! If anyone knows of a way in Expo to break videos into smaller chunks for uploads that would also be very helpful
Expo version is 43
Im a bit confused with the AWS SDK for JS in reference to its S3 utilization. The below is my code:
AWS.config.update({
accessKeyId: $rootScope.s3.akey,
secretAccessKey: $rootScope.s3.skey
});
s3=new AWS.S3({apiVersion: '2006-03-01'});
s3.listObjects({Bucket:$rootScope.s3.bucket}, function(err,data){
if(err) console.log(err);
else console.log(data);
})
This yields the error net::ERR_NAME_NOT_RESOLVED. The endpoint it is going to is similar to https://bucketName.undefined.us-east-1.amazonaws.com/
Obviously this wont resolve because of undefined being in the URL; however this doesn't even look like an s3 endpoint! It should follow a format like https://s3.amazonaws.com/bucketName/someFile.txt
Has anyone else been encountering issues similar to this or is there something elementary that I am doing wrong.
STR:
Download SDK for S3 from AWS
Use code posted above (its in angular, but pretty self explanatory)
View errors in console.
Any help please?
I've debugged this a bit in the browser and found that it appears to be an issue with endpointPrefix being undefined. This effects selecting the url template to use as well hence the strange url.
If we look in the debug version of the aws js sdk code there's an area where
regionConfig.rules
is used to find a match from derivedKeys (which is based on your service/region). In mine I get:
"eu-west-1/*", "eu-*/*", "*/*"
The asterisks after the / indicate an undefined endpoint prefix. However the rule that we want matched in regionConfig.rules is:
eu-west-1/s3: "s3dash"
s3dash equates to the following template:
"{service}-{region}.amazonaws.com"
Which would work if service was s3 as you'd get:
s3-eu-west-1.amazonaws.com
However because this rule is not found instead / matches to:
"{service}.{region}.amazonaws.com"
Because service endpointPrefix is undefined (which is why we ended on this rule in the first place) you get 'undefined.eu-west-1.amazonaws.com'
If the CDN works are we suggesting there's a bug in the custom download?
I have a file on AWS S3 that is public:
https://s3-eu-west-1.amazonaws.com/voxist-greetings/33631222504/33651291239_95113eed-386b-4264-a4cf-46182faae125COUCOU1.wav
Now when RVD try to play it I get:
INFO [org.mobicents.servlet.restcomm.interpreter.VoiceInterpreter] (RestComm-akka.actor.default-dispatcher-8586) MediaGroupResponse, succeeded: false jain.protocol.ip.mgcp.JainIPMgcpException: The IVR request failed with the following error code 312
I don't know why... The same file used to work with another name.
Thanks for any hint on how to debug this.
The problem seems to happen on Media Server side. More specifically, it seems the file cannot be opened for some reason.
Relevant code line can be found here.
Can you please take a tcpdump and share it, so we can see the MGCP Play request?
Hope this helps.
UPDATE:
Here is an example:
The 200 OK simply indicates that the MGCP transaction completed successfully. Now we need to dissect the notification (NTFY) sent from Media Server to RestComm, mainly the ObservedEvents parameter.
If you look at the picture, you will see the event triggered is an OperationFailed (of) with ReturnCode (rc) equal to 312, which is an error.
Relevant link to specs can be found here.
To summarise, Media Server receives the request to play the file (in this case a cached version of it) but if fails to open the URL for some reason.
Is the URL reachable from Media Server side?
My application servers .wav files, which are downloadable at certain URLs. I have to change the logic so that they will be streamed instead of being downloaded - so I will remove Content-Disposition header that was being explicitly set.
Piece of code:
// removed
//response.setHeader("Content-Disposition", "attachment;filename=" + fileName);
bis = new BufferedInputStream(inputStream);
bos = new BufferedOutputStream(sOutputStream);
byte[] buff = new byte[10000];
int bytesRead = 0;
while(-1 != (bytesRead = bis.read(buff))) {
bos.write(buff, 0, bytesRead);
}
bos.flush();
2nd or 3rd call to bos.write causes
ClientAbortException: java.net.SocketException: socket write error: Connection aborted by peer
at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:402)
at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:449)
at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:349)
at org.apache.catalina.connector.OutputBuffer.writeBytes(OutputBuffer.java:425)
at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:414)
at org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:89)
at java.io.BufferedOutputStream.write(BufferedOutputStream.java:105)
When I debug the code, at the time write method fails, the browser opens a player and another, identical request is being generated and succeeds.
When Content-Disposition is set eveything works fine. Any ideas?
It's because the client aborts the request after noticing that it's actually a media file and switches via client's media player to streaming mode via HTTP Range requests in order to improve buffering speed. The client will then fire multiple HTTP requests on different parts of the file (obviously, this works only efficiently if your servlet also really supports it ... a lot of homegrown file servlets don't and may eventually perform much worse).
As to those client abort exceptions in the server log, your best bet is to filter out and suppress them, or at least log with an DEBUG/INFO oneliner instead of with a whole stack trace.
See also:
How to stream audio/video files such as MP3, MP4, AVI, etc using a Servlet
ClientAbortException at application deployed at jboss with IE8 browser
I am wondering if it possible to configure the remote notify option to pass a URL.
I see there is a function for onErrorRemoteDisableDenial. I tried to modify it, but it seems to disables the app. Even if i put code to continue, the next call to the backend does not work.
But what we are looking for is giving the user the option to update via URL, or just continue with the app version they currently have.
Using Worklight 6.1
There is a way to customize both Remote Disable and Remote Notify, but the downloadLink (the link that you've set in Worklight Console) is available only when setting Remote Disable, not Remote Notify. Only the message (the text set in Worklight Console) will be available.
You can customize the Remote Notify flow by using the following in main.js (outside of any function):
wl_remoteDisableChallengeHandler.handleChallenge = function(message,downloadLink) {
WL.SimpleDialog.show(
"New Version",
message,
[
{text: "Download", handler: function() {
// Maybe use WL.App.openURL(downloadLink) to go to the app store
}},
{text: "Close", handler: function() {
// Continue with the app
}}
]);
};
wl_remoteDisableChallengeHandler.handleChallenge overrides the default Remote Notify code path. wl_remoteDisableChallengeHandler.handleFailure will override the default Remote Disable code path (and this is another way to customize Remote Disable).
Edit: per the findings in the comments, in order to get both the message and downloadLink, you will first need to temporary set Remote Disable and then change to Remote Notify, this is a workaround because Remote Notify by default is not meant to also pass the downloadLink to the default provided dialog.
Note: Remote Notify is meant to be displayed only once per a message's life cycle, so after it was displayed - it will not be displayed again until a the message is set again in the console.
A way to get the code to work on each application launch is to clear the application's HTML local storage (at some point while the app is running), where a "flag" is stored to tell the application not to display the message again (I forgot its name, but you could print the contents of the local storage and debug that).
Sounds like a nice feature request: https://developer.ibm.com/mobilefirstplatform/help