To replicate the problem:
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.)