I need help with a strange issue:
I have a FMS 3.5 running a VOD service (on-line training based on videos) on what I call a "streaming server".
The client loads the Player from a secure (separate) domain, and the Player then requests the SMIL files from the webroot of the Apache server (part of the FMS installation. The Player then starts the video which is streamed dynamically.
In order for the Player to get the SMIL files, it is making a crossdomain.xml request to the Streaming Server. When it get the response, it continues the process.
PROBLEM: Sometimes, the crossdomail.xml response from the Streaming Server is SEVERELY delayed, with perhaps 5 minutes. So the end user experience is that it does not work.
I improved the situation by opening up more ports on the Windows Firewall of the Stremaing Server (now open for 1935,80,443,8134) and it works say 90%+ of the times. But there are still occations when there is no response.
I have not specified a crossdomain.xml file, so the response is the default "*" from the application.
Any ideas???? Appreciate any tips.
This sounds like a packet capture is in order from the FMS side. I'll wajor that the session to get the Crossdomain.xml isn't trying the proper port for starters and is eventually migrating to one that works only after timing out and failing. The best way to determine this is, if you have it happening, use a tool like Wireshark to trace out the network activity. Let us know what you find, if FMS is getting the request, but not responding in a timely manner - then it sounds like a bug. If however, it's not getting there on time like I presume it bears network investigation.
I have done some further investigations and I have so far concluded that:
- in the cases where the service does NOT work, the following is happening:
I watch a video (video 1), then close the window. I start a new window with a new video (video 2). However, despite closing a window and opening a new window, the TCP session for video 1 remains open. So when I start video 2, the crossdomain.xml request is sent on the old TCP session.
Instead of getting an "OK" reply, I simply get an "ACK" reply and the process is halted.
- in the cases where the service does work, the following is happening:
I watch a video (video 1), then close the window. I start a new window with a new video (video 2). For each window, a new TCP session is set up/ synchronised, and the crossdomain.xml request receices an "ACK".
- it seems that the failure scenario happens when there are no files in the cache.
Any ideas of what this could be?
Interesting, this could be a bug in how FMS handles crossdomain requests on an existing HTTP socket that's already been handling session data. Is it possible that you can share one of these demonstratable packet captures with us here at Adobe so that we have something to work on the problem for? You can contact me directly at firstname.lastname@example.org.
We have stumbled upoon the same problem, using FMS(interactive edition) 4.5.1(latest version as i believe), new installation(clean windows 2008R2 install), and absolutely the same issue - after a person who was watching the live broadcast in flash media player refreshses a webpage - no crossdomain.xml is served. It can easily be seen using httpwatch or other similar tool.
Is there any solution for that problem?
I have the same issue with olafnew. I would like to play vod with http dynamic streaming feature on my Flex Application. I opened an iframe with embeded StrobeMediaPlayback. The movie plays well at the first time. If user closes the iframe and opens another movie, the player does not work any more. I look into Fiddler and the request for crossdomain.xml to my streaming server is never returned.
Europe, Middle East and Africa