When you specify that the StreamType is LIVE, we assume that it's a live stream (which can't be paused or seeked). If your stream isn't truly live, try using the StreamType.RECORDED (or StreamType.LIVE_OR_RECORDED).
This sounds familar as we had a similar bug filed while ago, which indicates this has to do with Wowza. https://bugs.adobe.com/jira/browse/FM-935 then the related bug has been moved to SMP https://bugs.adobe.com/jira/browse/ST-136
Can you try with non Wowza streaming to see if you can still reproduce? Either way, if still seeing this even with Brian's recommendatation, please file this with your the content url available to us. https://bugs.adobe.com/jira/browse/FM
Here's one of the comments in the bug FM-935, specific to Wowza,
Dragos uses Wowza with edge servers and we did some tests with his stream and another live one (origin) we have here, both in his player and in Strobe.SWF.
1. rtmp://live.crestin.tv:80/live/ + Strobe.SWF
We're following the next sequence :
- Play : play starts
- Pause : stream paused
- Play: stream doesn't resume playback
Expected behavior : should resume/restart playback
2. rtmp://lolek.corp.adobe.com/dvrcast/rmsarea + Dragos's player
We're following the next sequence:
- Play : play starts
- Pause: stream paused
- Play : stream restarts playback
Expected behavior: as expected playback is resumed after pause
It remains for Dragos to see if there's a Wowza/edge/OSMF combination that might be the culprit.
It also seems that when played in JW rtmp://live.crestin.tv:80/live/ plays correctly.
Thanks for your reply,
If i use StreamType.LIVE_OR_RECORDED it works fine (Start, Pause, Resume and seek) so what is the difference between each properties LIVE, RECORDED, LIVE_OR_RECORDE, in my case it's a VOD...
LIVE and RECORDED should be fairly obvious: playback will only work if the stream is of the given type (live vs. VOD). When you specify a StreamType of LIVE_OR_RECORDED, the player first attempts to connect as a live stream, then (if no live stream exists) as a recorded stream. If neither is found, then it opens (i.e. waits for) a live stream. Hence, LIVE_OR_RECORDED is extremely flexible, but it is unlikely to fail (since it will assume that a bad stream name is actually a not-yet-published live stream).
These three values map to the values that are passed to the "start" parameter of NetStream.play(), you can read the documentation for that method to get more detail.