Answer by Jason Hilton · Nov 02, 2011 at 12:40 PM
Answer by Charlie Good · Nov 04, 2011 at 03:08 AM
My concern here is rather the behavior of the mediacaster that it does not shutdown/reset an instance in case the stream played is not explicitly closed from the client IN SPITE OF the FCSubscribe call in advance.
Could you please check if this occurs in your environment, and if this is an intended behavior of the mediacaster (I do not think so...).
Your support is appreciated.
Not sure what you mean by this. Please explain in more detail.
Answer by Richard Lanham · Nov 03, 2011 at 01:24 PM
Answer by Richard Lanham · Nov 04, 2011 at 12:38 PM
Answer by Guillermo Revuelta · May 28, 2012 at 03:28 PM
Thank you so much for your advice and continued support indeed.
Regarding the MediaStreamNameGroups (smil+StreamManager):
I have already tested it and confirmed that the problem does not occur in this case because all the streams are being pulled (by the edge) all the time and the behavior of the mediacaster (start/shutdown/etc.) is not affected by the activity of the client (play/close/etc.).
(Actually, what I wanted to say by '3. this does not happen if all the streams are being pulled all the time (by using the StartupStreams.xml or stream manager) regardless of the activities of the client.' in my first post is this. sorry for confusing.)
However, what I would like to achieve is the dynamic streaming with origin/edge configuration WITHOUT using the StreamManager/StartupStreams.xml/MediaCasterAPI.
Yes, actually Application.xml of my origin always has this property set to true.
But the stream switching does not work (step 11) if an instance of the mediacaster sticks (step 8 and 9) and is left for a few hours.
> Can you package up and send something that we can run and replicate this, including a set of files and your player. Send to email@example.com.
Thank you so much.
I will send the information (Applicaiton.xml, configuration of FMLE/jwplayer).