the problem seems only when you work in HTTP CDN caching nodes. When the flashplayer connects to an big .f4v DRM protected file, it tries to read the DRM licenses out of the header. After some seconds the flash player disconnects the connection between the client and the HTTP caching node.
It seems when a http caching node takes to long btw. has too high latency then the flashplayer cant process the hole DRM license out of the header. I dont know this exactly and i dont know if there is maybe a too small timeout in the flashplayer.
To fix this, it might be usefull when you work with the DRM metadata instead of the hole .f4v. When you work with the .metadata, you have complete control over the loading state of the metadata DRM file. You can use an URLLoader for loading the .metadata and parse the result in a bytearray and from the bytearray the DRM Manager of the flashplayer to authenticate. It works quite well.
On the other side, i like this method from the point of security much better then the flashplayer is connecting to the hole .f4v / connect / disconnect.
You can store the metadata on server1, and the real .f4v on server XX / caching nodes. After sucess full authentication of the metadata drm file, you can then check in your database user,pass and geoIP and then transmitt the real URL of the original .f4v over an SSL connection.
The issue doesnt exists when you work in a RTMP CDN bye the way.
Hope this is usefull for some other flash access developer.
yes..thats also right, and not changeable cause the http caching nodes has fixed mine-types.
anyway..it was very easy to fix...everything works well now..i prefer the .metadata method instead of reading the DRM license from the .f4v header.