Hi Timur,
I found and fixed the issue why "closeStream" was called twice.
The bug was that in the method "_stop" this._nc = null was missing to make
sure the stop method is not called twice.
Long description:
When the user hits the "re-start audio/video settings" icon on his own
video pod, the choose-settings dialog will popup. But also a there is a
call on the icon to the method: resetStream,
this will call: this._chatvideoinner._videostream._stop();
_stop() does close the NetStream, on server side this event is catched,
and in ScopeApplicationAdapter:streamBroadcastClose() we listen for that
event and send a "closeStream" to all participants.
That is all good, the issue is, when the user re-starts the stream, in the
method "broadcast" there is an if-clause:
if (this._ns != null) {
this._stop();
}
And this fired a stop event for the second time because this._ns = null was
missing.
Should be all good, let me know if there are more issues with the stream
handling.
Thanks
Sebastian
2013/2/13 [email protected] <[email protected]>
> Hi Timur,
>
> yes thanks, I could duplicate the closeStream bug.
> I seem to receive a closeStream Event too much and with another
> (Room)Client object set.
> That is strange, I will need some more time to debug that.
>
> Sebastian
>
>
> 2013/2/13 Тимур Тлеукенов <[email protected]>
>
>> Hello Sebastian!
>>
>> This issue happens without SIP integration. You can see it with laslo
>> debuger.
>> After somebody click "(Re) start audio/video" button, other clients
>> receive newStream twice.
>>
>> Here part of log from laszlo debuger:
>> **** closeStream: «Object#935| {allowRecording: true, avsettings: 'av',
>> broadCastID: 5, ...
>> sendVarsToMessageWithClient : «Array(0)#937| []» «Array(3)#938|
>> ['avsettings', '0', 'av']» avsettings
>> newStream: «Object#939| {allowRecording: true, avsettings: 'av',
>> broadCastID: 6, ...
>> **** closeStream: «Object#942| {allowRecording: true, avsettings: 'av',
>> broadCastID: 6, ...
>> newStream: «Object#944| {allowRecording: true, avsettings: 'av',
>> broadCastID: 6, ...
>>
>> Sometimes i see that client receive second closeStream before newStream
>> and stream is duplicated.
>>
>> I checked log when SIP user connects:
>> newStream: «Object#975| {allowRecording: true, ..., broadCastID: 10,
>> canDraw: false, ...
>> addNewUser: «Object#977| {allowRecording: true, avsettings: 'av',
>> broadCastID: 10, ...
>> ### initializeStreams addClientItem: «Date#978| Wed Feb 13 13:01:03
>> GMT+0700 2013» false 11 2 null
>> participantList addItem: «Object#977| {allowRecording: true, avsettings:
>> 'av', broadCastID: 10, ...
>> object.isSuperModerator false
>> updateByMod, false 2
>> onmicMutedStatusChangedItem :3: b8d379ff26758fd4ff0ebe8de3921e54 false
>> newStream: «Object#980| {allowRecording: true, avsettings: 'av',
>> broadCastID: 10, ...
>>
>> Actually newStream called twice in this case. So setSipTransport should
>> be fixed.
>>
>>
>> 2013/2/13 [email protected] <[email protected]>
>>
>> I actually don't understand:
>>> ((IServiceCapableConnection) conn).invoke("newStream", new
>>> Object[]{currentClient}, this);
>>> in the method setSipTransport
>>>
>>> Actually _every_ stream that starts broadcasting will trigger an Event in
>>> OpenMeetings.
>>> We catch those "stream start events" in the method:
>>> @Override
>>> public synchronized void streamPublishStart(IBroadcastStream stream)
>>>
>>> In the ScopeApplicationAdapter.
>>>
>>> Where this stream is coming from, if its screensharing or audio/video, it
>>> does not matter.
>>> I would expect that if a SIP user connects via red5SIP, this method will
>>> be
>>> still invoked, as it is just a "yet another stream" from the view of the
>>> red5 server.
>>> So why does "setSipTransport" call this method actively?
>>> "streamPublishStart" (and through that "newStream") should be called
>>> automatically as soon as the SIP user starts to stream audio to red5.
>>>
>>> You just need to make sure that the Client (former RoomClient) has the
>>> right flags set _before_ you start to stream. Cause the method
>>> "streamPublishStart" will send a client object to all users. And you
>>> can't
>>> pass any variables to "streamPublishStart" as this is a method/event
>>> listener of Red5.
>>>
>>> Calling "addNewUser" from "setSipTransport" makes sense for me, as this
>>> logic is the same like in "setRoomValues". But calling "newStream" from
>>> "setSipTransport" makes no sense to me. From my point of view you would
>>> get
>>> a duplicated "newStream" method call everytime a SIP user connects:
>>> 1) When setSipTransport is invoked
>>> 2) When the actual stream starts
>>>
>>> Can you check with that with Timur?
>>>
>>> Sebastian
>>>
>>>
>>> 2013/2/13 [email protected] <[email protected]>
>>>
>>> > Is this a problem that only happens with SIP integration or also
>>> > standalone?
>>> >
>>> > I will have to test that first. It sounds a bit weird, but I can't
>>> test it
>>> > as I don have 5-7 pc's.
>>> > And using a single pc makes no sense when testing audio/video.
>>> >
>>> > We have two rtmp connection per stream, but that would still not
>>> explain
>>> > your issues with the id.
>>> > Which Id are your refering to exactly? broadCastId or streamId ?
>>> > broadcastId would be the name of the stream under which the user
>>> publishs
>>> > (aka NetStream) streamId is the rtmp connection (aka NetConnection),
>>> > you connect to: rtmp://blabla:1935/openmeetings/
>>> > And each client will publish his webcam+micro in one stream, with the
>>> name
>>> > of the "broadCastId".
>>> >
>>> > The StreamId can stay the same, for example if you re-publish your
>>> > settings, the NetConnection will always stay, but each time your
>>> webcam is
>>> > published a new "broadCastId" is requested from the server. (See
>>> > ScopeApplicationAdapter::getBroadCastId()). It is better to use a fresh
>>> > broadCastId each time you make a new NetStream.
>>> >
>>> > "setSipTransport" and "streamPublishStart" are new only methods that
>>> > invoke "newStream" as event in the client.
>>> >
>>> > Sebastian
>>> >
>>> >
>>> > 2013/2/13 Maxim Solodovnik <[email protected]>
>>> >
>>> >> Hello Sebastian,
>>> >>
>>> >> sorry for double post, but I would like to gain your attention at the
>>> >> following problem:
>>> >>
>>> >>
>>> >> if there is lot of users lots of users in the room (5-7) some of them
>>> >> can't hear some others until "reload" of streams on the client.
>>> >> Timur told me that according to the log of red5sip there is weird
>>> queue
>>> >> of method calls: newStream gets called twice. Additionally if user has
>>> >> stream with id 24 and select "reload" the following methods are gets
>>> called:
>>> >> closeStream(25) // NOTE 25 not 24
>>> >> then
>>> >> newStream(25)
>>> >>
>>> >> Maybe you can say what is wrong?
>>> >>
>>> >> --
>>> >> WBR
>>> >> Maxim aka solomax
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Sebastian Wagner
>>> > https://twitter.com/#!/dead_lock
>>> > http://www.webbase-design.de
>>> > http://www.wagner-sebastian.com
>>> > [email protected]
>>> >
>>>
>>>
>>>
>>> --
>>> Sebastian Wagner
>>> https://twitter.com/#!/dead_lock
>>> http://www.webbase-design.de
>>> http://www.wagner-sebastian.com
>>> [email protected]
>>>
>>
>>
>>
>> --
>> Timur Tleukenov
>
>
>
>
> --
> Sebastian Wagner
> https://twitter.com/#!/dead_lock
> http://www.webbase-design.de
> http://www.wagner-sebastian.com
> [email protected]
>
--
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
[email protected]
