I don't mean to have a conversation with myself but I know which stop  
is causing the issue. Inside PlaylistSubscriberStream.java around  
line 659 is this piece of code:

                                 case 1:^M
                                         msgIn = vodInput;^M
                                         msgIn.subscribe(this, null);^M
                                         if (item.getLength() >= 0) {^M
                                                 playLengthJob =  
schedulingService.addScheduledOnceJob(^M
                                                                  
item.getLength(), this);^M
                                         }^M
                                         break;^M

Does anyone know why the stop job would be scheduled here in this  
fashion when it is scheduled in pullAndPush as well in what seems  
like a much more efficient manner? The same sort of things seems to  
be in the resume function. Sorry if this is a stupid question since I  
have only covered a small portion of the red5 source and am quite  
uninformed in it's inner workings.

Thanks,

--Dan--


On Nov 15, 2006, at 1:37 PM, Daniel Daley wrote:

> Hi,
>
> I'm trying to track down some problems with the FLVPlayback component
> and want to see if someone might have some quick insight into this.
> The component sends the command play(streamName, 0, 0) followed
> immediately by play(streamName, 0 -1). On the server I see the first
> play start, then a stop command, and then nothing. The second play
> command never gets executed and the player just sits there. Now, if I
> increase the time between commands so that the stop is scheduled
> slightly later, the second play command does get executed. My thought
> is that the server is getting stuck somewhere while reading the FLV
> since the stop is called so quickly after the play. The server also
> does not close the connection when I close my player, nor does it
> accept any other commands until I create a new connection. That
> original connection remains and is unresponse to IClient#disconnect()
> as well. Something else that makes me think it's a race condition, is
> if I enable caching and allow the server to hang on that first
> connection but fill the cache with the file, it then works every now
> and then with future connections probably due to it being served from
> cache faster.
>
> Thanks,
>
> --Dan--
>
> _______________________________________________
> Red5 mailing list
> [email protected]
> http://osflash.org/mailman/listinfo/red5_osflash.org


_______________________________________________
Red5 mailing list
[email protected]
http://osflash.org/mailman/listinfo/red5_osflash.org

Reply via email to