Hi all,

i've a problem understanding the behaviour of multiple 'play' calls on a NetStream and the resulting events logged in the fmis access protocol:

The scenario is as follows:
A player is connecting to our server's VOD application (the adobe vod app). It call's the 'play' method with the content name to be played out. The server is streaming the content as expected. The event is logged in the accees log with the status code 200

If the player call's the 'play' method a second time, with the same content name and without calling 'stop' in between, this results into 'Failed to play <content name>; stream not found' on the client side. And on the server side this play event is logged with the status code 404.

It's no problem to call the 'play' method for an other content, without calling 'stop' for a previous 'play'.

Has anybody an idea, why the server acts like that?

Hi,
When you call the second play what are you setting for "reset" param? More over are you trying to initiate the second play before the first play finishes?
Which version of FMS are you using?

Regards,
Janaki L

Our servers are running FMIS 3.5.2

The player is carried by our customer. So the player itself and its code is a black box to us.

But yes, the second play method is called before the first play has finished.

Based on our question, what's the best practice for the painted scenario of calling the play method twice for the same content?

Do you have an idea, why the vod application is dropping the 404 errors?

Thanks for your answer.

Martin

Hi,
oh! We got to know how they are calling the second play, only then we can nail down the issue. If you can get the client side code, it will be great to investigate.

Regards,
Janaki L

Hi Janaki,

many thanks for your support and excuse the time shift, i'm working in CET :)
It's not easy to get access to the player code. Our customer keeps it under wraps. But i'll keep trying.

Our first post was already helpful. None of our other customers has these problems with the vod application. So in this case it is obvious to suppose a player-side problem.

Best regards,

Martin