The online player drops the connection back to the server after only playing several minutes of video. The video never continues playing unless the video is re-selected from the title page.
OS: Windows XP Home or Professional, Windows Vista, or MAC OSX Leopard
Processors: AMD, Intel, single and dual-core, low and full powered - it doesnt matter
Browsers: Safari, Firefox, Opera, Internet Explorer - all current versions
FLASH: Latest updated versions
Internet Provider: AT&T / Bellsouth
Type: DSL 8Mbps down / 784K up
LOL, it’s been a month… seems like I am not the only one with the problem… quite frankly the TAN player has gotten a LOT worse since the last time I posted.
Anyways - to answer the other question - wired and/or wireless, always connected - single path, multi-path, ganged, loose - doesnt matter. Were you waiting the past month for me to answer that question?
In other words - nothing makes a difference, so the issues have to reside in everything external - in other words, the network that serves the video is the whole problem with everything.
Bad routers, bad servers, bad memory, crashing computer, bad ethernet cards, etc. etc. etc. Something along those lines.
I reminded them of this thread today, so perhaps they’ll have more information for you soon.
The new problem happening has to do with the latest flash version that was released recently - which a lot of us are now experiencing odd problems. Your situation is unique and one they haven’t been able to replicate. You were having trouble even when a lot of us were having no problems at all. It’s not always easy to isolate some of the problems if in other test cases there are none exhibited. I am sure they are looking into it still though.
Come to South Florida and use an AT&T DSL connection.
The real problem is a matter of networked router hot circuits. (Any router technician will know what I am talking about.) The hot circuit going back to the video server collapses after about 7 to 12 seconds of inactivity and becomes a cold circuit. If at any point in time nothing happens for 7 to 12 seconds, the route going back to the server becomes invalid, the software hangs up, and a new route has to be opened and established. This of course causes the player to stop prematurely.
This happens on all commercial networks that use Live On Demand network management - meaning if a routed connection becomes silent, drop the connection and wait for it to start up again, and then re-make the connection. Which of course breaks secure connections and connections that should be always on. These items are programmed into the commercial routers that handle the network traffic.
The solution to the issue is to never let your connection be silent. Or have a secondary connection going back to the server on another port. Something slow that sends a signal FROM THE COMPUTER back to the server once every 2 to 5 seconds works great. Many high-end commercial software suites solve this issue by having a separate Java application that pings the video server once every 2 or 3 seconds. Others open or establish a TELNET session back to the video server, sending a small block of characters out every few seconds.
Anyways, that’s the underlying issue in a nutshell. This also solves 99% of the video stuttering problem as well. The video stuttering is happening because the video circuit is about to collapse fully, but has only partially collapsed - so the route back to the server is being rebuilt. That causes a delay in receipt of the video server’s information, and being time-shifted too far out, the player then re-requests the data, but starting from a time just previous to that instance, a LAST KNOWN GOOD spot. When that data comes in and plays back, since the player itself did not stop, and instead re-winds a fraction of the second, it looks like the player is stuttering. The other issue of the video stuttering is that the playback software does not know how to re-synch the audio and video after having an information delay and re-request sequence like that. Stuttering will virtually disappear once the circuit back to the video server is kept hot, but it will not go away until the underlying issue in the software is resolved (larger buffer, allow longer response times, etc.)