Jump to content


  • Posts

  • Joined

  • Last visited

About clutch16b

  • Birthday 09/15/1988

Profile Information

  • Gender

clutch16b's Achievements


Newbie (1/14)



  1. You're right. It's tricky for sure. For now I'm thinking of determining that the load has failed to propperly complete, and manually triger a BUFFER_EMPTY, just to let the user know that it can't load anymore. Don't know if unloading and loading again is practical for me, since my video files are 100MB in avarage, and I'm almost sure that the playback will start over, right? I think is better to 'trick' the user that the file can't load and he'll do this job for me, by reopening the player.
  2. I'm beginning to think that this is hopeless. I can't seem to get any NetStatusEvent.info.code to show that some error has happened when the connection is lost and the bytesTotal get messed up. I'm getting a 'NetStream.Buffer.Flush' when the playhead almost reaches the end of what is loaded. That's expected. Also, calling load() after it "completed" loading doesn't do much either. I guess that the bytesTotal don't go back to what they should be, even if the connection is restored. Everything is surrounding bytesTotal. First there is a loadComplete event dispatched, which lets the entire VideoLoader think that the file is shorter than expected an call a VIDEO_COMPLETE when it reaches the last loaded byte, instead of BUFFER_EMPTY as it should to, right? Anyway, thaks for the ideea with NetStatusEvents, I guess it helped prove my 'bug'.
  3. Good point with the NetStatusEvent. I'll give that a try. One question though... If I do something like this... function loadComplete(event:LoaderEvent):void { if (currentVideo.bytesLoaded < videoBytes) { TweenMax.delayedCall(3, currentVideo.load); } } 'videoBytes' is a var set to the value of totalBytes on currentVideo.init What I'm trying to do is have the load() function continue from where it left off, not reset. Will it get the propper value for bytesTotal and perform this way? Thanks in advance
  4. OK, since VideoLoader is based upon NetStream, I tried to trace bytesLoaded and bytesTotal directly from the netStream and it seams my problem can be found there too. Maybe I'm wrong here, but it just seems strange to set bytesTotal to bytesLoaded on a load fail. That's how I would call my 'test' described in the first post. So, is there an event that I should look for to get a load error before theso totalBytes get all messy?
  5. Hi, I seem to have found a bug... I'm currently working on a custom video player based on VideoLoader, and up till today everything was OK. I understand the limitations of progressive loading and all that, but... I thought I'd do a 'connection lost' test while the video file was still loading (disable/enable the ethernet connection on my PC). What I was hopping to see was the loading progress bar stop when I disable, and resume when I enable the connection, or at least get some king of a load error (fail, error, cancel, ioError). But that wasn't the case. In fact, atfer some digging around, I found that the bytesTotal were set to bytesLoaded when connection was lost (not the other way around, it's not a typo), which in my case were a lot less, thus giving me a progress of 1 and a completly full loading progress bar. Also, a loadComplete event was dispatched. So, when the playProgress reached that last loaded frame, instead of staying there and showing me that the videoBuffer was empty, it just triggerd a VIDEO_COMPLETE event. I can't seem to figure out any work around this, since the bytesTotal is read-only, right? Also, as mentioned before, no events are dispatched other then LoaderEvent.COMPLETE.