I noticed that the web server serving the range requests for the video content does not get a close socket event, even though the video tag requesting it has been removed from the DOM.

Possibly related: https://bugs.chromium.org/p/chromium/issues/detail?id=162627#c36
https://bugs.chromium.org/p/chromium/issues/detail?id=162627
https://bugs.chromium.org/p/chromium/issues/detail?id=560477

I think it's worth noting that using media source extensions will effectively bypass this problem.

These will auto-release when they can if you use preload=metadata, or won't be created at all if you use preload=none. You must always clear src="" when trying to dispose of a tag or it will keep loading (per spec).

Just tested with preload=none and the issue still persisted. However, setting src='' before removing the video element did work. In my tests, the video will hang forever... shouldn't it at least eventually load the video presumably once one of the removed videos finished loading? Having to set src='' before removing is pretty inconvenient and I would imagine could affect many applications that aren't aware. I guess it's really only an issue because of chrome's socket limit of 6 as other browsers don't have this problem.

^ By other browsers I meant firefox. I assume IE might also have this issue since AFAIK the connection limit is 2.

Just updated chrome to 52.0.2743.116 (OSX) and the issue is definitely less apparent. Eventually I will still get a video that will hang but its not consistently on the 7th one now.  

We only load what's needed, so loading may never finish since internal buffers are full. 52 brings workarounds for that where we'll automatically deallocate internal resources on idle players if possible.

Not setting src='' on other browsers will leak memory and other resources last time I checked too. It may not hit the network cap (which is also spec), but there are other issues unfortunately with not clearing your old tags.

Thanks for the additional information. Since updating to 52 and with the suggested workaround the issue seems to be more or less resolved so feel free to close as you see fit. To clarify the workarounds in case anyone else comes across this:

1. setting src='' before removing the element (most likely easiest and avoids possible memory leaks in other browsers)
2. Reusing the same video element (not always possible but also avoids hitting the awaiting sockets issue)
3. Using Media source API. Didn't try this one but I'm guessing this will avoid the issue because you would be manually fetching the resource using XMLHttpRequest and piping to the video element. You would still need to make sure you aren't firing off more than 6 requests at a time due to Chrome's socket limit. (https://developer.mozilla.org/en-US/docs/Web/API/MediaSource, http://html5-demos.appspot.com/static/media-source.html)
4. Using websockets and media source api you should be able to display more than 6 videos at a time since AFAIK web sockets aren't subject to the tcp socket limitation. Also didn't try this one yet either.

Working as intended.