I noticed a bug. Don't know if it's RTMFP related. When a
publisher is publishing, a subscriber listens. After a while, the
subscriber stops viewing the stream by invoking .play(false) on the
stream, which stops the streams (invokes the NetStream.Play.Stop on
the publisher side (first maybe odd thing). Then, the publisher
stops publishing by invoking the .close() method on his stream. The
publisher then decides to republish the same stream and does so.
The subscriber then suddenly has the stream playing without really
being in the state of asking it. Also, the .time property of the
subscriber is in the 4079999.001 or so values.. which really isn't
true. It's been on for about 485 seconds. Seems like the .time
property gets substracted by about 2 000 000 ms or so.
Don't know how many bugs are in this description, but the
.time weirdness seems the most visible and unexpected/manageable
(except to close the subscriber stream and restart it). The fact
that the stream starts by itself after invoking the .play(false) on
it, seems also a bit odd.
PS: I need to use the .play(false) method, because it doesn't
leave spawned NetStreams on the publisher stream when it starts
republishing. Vs using .close() everytime the subscriber wants to
stop receiving the stream at a given time. I also decided to not
use the .pause() method because it doesn't seem to pause properly
the data stream/bandwidth on the publisher.info side.