I've got an application that is downloading several large binary files and saving them to disk. On some machines it works fine and on some other machines every once in a while a download will proceed to 99.9% complete and the URLStream object will not fire Event.COMPLETE
This is almost identical to the issue that appears here:
Why does URLStream complete event get dispatched when the file is not finished loading?
I've tried using the 'Cache Bust' method described in one of the answers but still no dice.
Any help would be appreciated.
Here is some sample code to help illustrate what I am trying to do:
var contentURL:String = "http://some-large-binary-file-in-amazon-s3.tar";
var stream:URLStream = new URLStream();
stream.addEventListener(Event.COMPLETE, function(e:Event):void{
//This should fire when the file is done downloading
//On some systems this fails to fire once in a while
//On other systems it never fails to fire
});
stream.addEventListener(ProgressEvent.PROGRESS, function(pe:ProgressEvent):void{
//Write the bytes available in the stream and save them to disk
//Note that a download will reach 100% complete in terms of total progress but the 'complete' event might still not fire.
});
var urlRequest:URLRequest = new URLRequest(contentURL);
//Here we might add some headers to the URL Request for resuming a file
//but they don't matter, the 'Event.COMPLETE' will fail to fire with our without
//these headers
addCustomHeaders( urlRequest );
stream.load( urlRequest );
Imo this is a code meant to fail where you purposely give up any control on whatever is going on and just assume that everything would work by itself and go well. I never had any problems whatsoever with the URLStream class but here's basically what I never do:
I never not register all the different error event available (you don't register any).
I never use anonymous listeners. Even though they are supposed to not be GC until the download is complete this is imo an unnecessary unsafe bet especially since it's not rare for the URLStream to idle a little while loading the last bits. I would not be surprised if removing those anonymous listeners would actually fix the problem.
Related
I am working with MediaSource and SourceBuffer to play html5 video. I am sequentially fetching DASH fragments to continue uninterrupted video play. But sometimes, due to network conditions, SourceBuffer runs out of data to continue play. When that data arrives play resumes. But between this period, video looks stalled. I want to add some visual indication over media element, that it is paused as its buffering required data.
I tried binding 'waiting' and 'stalled' events on video, but none of the events get fired.
var vid = $('video')[0];
vid.addEventListener('stalled', function(e) { console.log('Media stalled...');})
Is there any other way to know whether media has been stalled and when it resumes back?
Thanks.
Using the stalled event is correct, but unfortunately, it does not always work as expected.
You could use Media Source Extension which gives you full control of the buffer and allow you to detect stalls manually. However, a solution using that is a bit out of scope here IMO.
You could possible get around using the timeupdate event as well.
Have a setTimeout() running with a time-out value
Inside the timeupdate event, clear this timer and set a new
If the timer isn't reset, it means there is no time progress and if not paused or ended, assume stalling
Example (untested):
...
var timerID = null, isStalling = false;
vid.addEventListener("timeupdate", function() {
clearTimeout(timerID);
isStalling = false;
// remove stalling indicator if any ...
timerID = setTimeout(reportStalling, 2000); // 2 sec timeout
});
// integrate with stalled event in some way -
vid.addEventListener("stalled", function() {isStalling = true})
function reportStalling() {
if ((!vid.paused && !vid.ended) || isStalling) { ... possible stalling ... }
}
...
You may have to do some additional checks to eliminate other possibilities and so forth, but this is only to give you the general idea, and in addition to using the stalling event.
A different approach could be to monitor the loaded buffer segments using the buffered object (see this answer here for example on usage).
These can be used to see if you have any progress, then use currentTime compared with the ranges to see if the time is at the end of a range and/or if the ranges are changing at all.
In any case, hope this give some input.
Here is the reference http://www.w3schools.com/tags/ref_av_dom.asp
I think you are looking for the event suspend: fires when the browser is intentionally not getting media data
My Facebook app is a flash game. I want the game swf to save its latest state to the server when the window unloads. Since I embed the swf with swfobject, I use its embed handler to add a onbeforeunload listener to window:
function embedHandler(event)
{
shell=event.ref;
window.onbeforeunload=function(event)
{
shell.message("save", null);
//delay the unloading a bit so flash has time to contact server
var now = new Date().getTime();
var later=now+50;
while (now < later)
{
now = new Date().getTime();
}
}
}
Here's the problem. This works every time when the swf is loaded directly from the app (a rails app). It never works when the swf is loaded from Amazon.
All the cross-domain issues are worked out between the swf and the app--the rails app accepts calls from Amazon swf, and the Amazon swf loads data from the rails app.
ExternalInterface also works for both outgoing and ingoing calls. But I suspect this is nonetheless a browser security issue, since the inward-going ExternalInterface call only fails when:
it is called from inside the window.onbeforeunload handler
the swf originates from Amazon.
What is the problem? How does one unobtrusively save game state when the game is from a CDN and the save is triggered by onbeforeunload in Javascript? Or is there a better way to accomplish this same thing?
Testing in Firefox.
ExternalInterface also works for both outgoing and ingoing calls. But
I suspect this is nonetheless a browser security issue, since the
inward-going ExternalInterface call only fails when:
it is called from inside the window.onbeforeunload handler
the swf originates from Amazon.
From the sounds of it you worked out all the security issues.
It is more likely a lack of understanding on your part on what is going on behind the scene when onbeforeunload is triggered.
This is a function that will not wait for your "game.swf" to finish the call back via ExternalInterface.This is why you added a stalling mechanism to delay that process. However, I will assume here that this works from the rails app because that is a local server and you are not subject to the lag monster.
Now you might be thinking well I put in a delay it should work. Well that delay is on 50 milliseconds. Try increasing to to 5000(5 seconds) and you should see it start to work on the cdn.
The saving of data should be controlled via the flash app and not triggered by an outside source.
In the game itself you should have milestones that should trigger a save event.
In closing I do want to add that is by far the worst method you could use to save information up to a server. onbeforeunload is unreliable and is subject to cross browser issues let alone putting a lag loop in the JavaScript is just a bad idea and in the end just annoy your users to the point that they won't return.
My application requires that I am able to abort/close a URLLoader instance at any point in the post-connect stage; that is, regardless if I have connected and the file transfer has already begun, or whether I have connected, and the file transfer has yet to commence (the server has not begun sending the file yet).
Here is my code:
var myTextLoader:URLLoader = new URLLoader();
myTextLoader.load(new URLRequest("myText.txt"));
This is what I have noticed:
When I connect to a server, and the server starts sending the file immediately, DURING the actual file transfer, if I invoke myTextLoader.close(), it aborts immediately. This is expected. I can monitor this by executing the SWF in Firefox,and noticing that when I issue the close(), the network connecion goes from Pending to aborted.
However, if I connect to the server, and the file transfer has not actually begun yet (I have confirmed the connect event has fired, and the server has simply not begun sending the file), then myTextLoader.close() has no effect. Only AFTER the first bytes start being transferred from the server, will .close() have any effect. I can verify the connection is stuck in Pending in Firebug.. .close() has no effect until the transfer has started.
Any ideas how to work around this issue? I need to be able to invoke .close() and have the connection torn down regardless of the connection stage.
First thing I would think of, is create a bool "aborted" that is set to true where the close() method is invoked.
Like :
function abort():void {
_aborted = true;
myTextLoader.close();
}
Then check for its value anywhere in the onProgress event or any similar event, to actually call the URLLoader close() method again whenever its value is true...
function onProgress(evt:ProgressEvent):void {
if (_aborted) {
myTextLoader.close();
}
}
Its not a pretty thing and is an ugly workaround, but this could work, since when the first bits are actually received, you'll know if you already wanted to close it or not.
Did you find any bug report on that anywhere ?... I doubt it could be an intended behavior...
3rd party AS3 HTTPClient (https://github.com/gabriel/as3httpclient) appears to not exhibit this issue with close().
I have an AS3 application that loads various SWFs at runtime. The loading animation that is being used has a fairly long in and out animation that I don't want to show if the target SWF is in the browser cache.
So at the moment each SWF is loaded in as required using Greensock's SWFLoader in a basic manner:
var context:LoaderContext = new LoaderContext();
context.applicationDomain = ApplicationDomain.currentDomain;
loader = new SWFLoader("mySWF.swf", {name:"sectionLoader",context:context,auditSize:true,onOpen:onLoadInit,onProgress:onLoadProgress, onComplete:onCompleteLoadHandler, onError:onLoadErrorHandler});
loader.load();
My goal is to do something before calling loader.load(); to determine if the load operation will require the request to go beyond the browser cache, but before I get into R&Ding something I thought I'd ask if anyone has already done something similar.
A few more thoughts I've had so far:
Just keeping track of what has been loaded in AS3 isn't good enough because if the user clears their cache they might be left loading a large SWF on a slow connection with no indicator.
Might a combination of LoaderItem.httpStatus and LoaderItem.auditSize() be worth investigating?
Is there a better loading framework for AS3 that I should be looking into instead of the Greensock classes?
Ideally I would prefer to also have some kind of version detection to span sessions that could be months apart, but one step at a time.
when you are doing any HTTP request, the responce comes up with HTTPStatus property. In AS3 you just need to chek if
HttpStatusEvent.status == 304
And for httpStatus in greensock library.
Basically 304 code means that no chages has been made on server side to the resource which user has requested. Which eventually leads to conclution that the resource is in the cache.
UPDATE
If this will not fit your needs try storing some variable for should you play the animation or not in Cookies or in Session variables.
I have a swf that I would like to cookie to control the frame the user see's depending on whether it is a first time site visit or returned visit. My code is below - it works, it doesn't bring back any out messages however when I load the swf into my site that uses this technique the page becomes extremely slow and unresponsive - can anyone help out with any reasons why this may occur?
var my_so:SharedObject = SharedObject.getLocal("visited", "/");
if (my_so.data.newVisitor != undefined) {
//object exists: return user
this.gotoAndPlay(2);
} else {
//object doesn't exist: new user
my_so.data.newVisitor = "no";
this.gotoAndStop(1);
}
Many thanks in advance
Rachel
SharedObjects in general are extremely slow in Flash. That being said, there is no reason why it should be slowing down your entire site after it has been used.
When writing to a SO, you have to use flush() to tell Flash to actually write the data.
my_so.data.newVisitor = "no";
// Write the data to disk
my_so.flush();
Another thing to try would be to actively close the connection after you are done with it. So after the else statement you would add:
// Close the connection
my_so.close();
// Clear pointer for GC
my_so = null;
If that doesn't work, the next steps would be to put trace statements in and around the SOs and make sure they aren't being accessed while the program is running.