0 Replies Latest reply on Feb 13, 2009 9:35 AM by Fredvb

    Particular .time bug

    Fredvb Level 1
      Hi,

      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.

      Regards
      Fredz