Hello All,

I have tested all cases and not found any errors.

I have found that name of the restricted room is not displayed when user enter to this room.
It is expected behavior or not?

Vasiliy


On 15.03.2013 16:45, seba.wag...@gmail.com wrote:
Hm,

I can confirm that the client does not crash no more.
I can't really test all use cases.

Examples:
  - User has no camera device at all
=> I think I was able to test that
  - User has configured the auto-checkbox "remember settings" that will auto
close the dialog and choose the settings
=> Have you test that ?
  - User does not want to share audio and video at all
  - User has misconfigured his settings and the default cam crashes his
Flash Player (like Irina had... in fact what you have done now would in
Irina's case lead tothat the Browser crashes even before she pushes the
button "start conference")
=> But at least we know whats going on now
  - User now has always two popups at the same time: Device settings and the
Flash Player security access. For somebody that does not even like to share
his cam/mic this might be rather disturbing?
=> They might simply choose the restricted room then where the device
settings won't pop up by default

After some re-thinking I think its a good default behaviour as it is now.
Just a little bit more testing would be fine. Maybe Irina or somebody else
can confirm on it too.
Btw: The recording button now (magically) works to stop the recording and
correctly produced a recording under OSX including audio and video enabled.
The screensharing client looks a bit ugly under OSX but I don't think that
is a blocker.

Sebastian


2013/3/15 Maxim Solodovnik <solomax...@gmail.com>

Unfortunately I can confirm test setup is broken in the release flash

I should recall this RC

@Sebastian thanks for pointing this out. Can you please check if revision
1456794 works as expected for you?


On Fri, Mar 15, 2013 at 1:36 PM, Maxim Solodovnik <solomax...@gmail.com
wrote:
Hello Sebastian,

The idea of that refactoring was to show user picture from the camera
selected.
Users are confusing by this "black box"
http://markmail.org/message/ibr5j6ytdw3cfrgp
All other applications (Skype, jitsi, linphone etc.) displays video from
the camera to the user

My fault I have checked it in debug only (and currently it works in
debug,
but somehow fails in release ...)
I'll doublecheck with cleaning up all caches and will write back




On Fri, Mar 15, 2013 at 1:11 PM, seba.wag...@gmail.com <
seba.wag...@gmail.com> wrote:

the issue is the refactored method:
<handler name="onselect">
             parent.attachCamera();
         </handler>
and "attachCamera".


The effect of this onselect handler is that, even when you simply open
up
this dialog, the
"onselect" handler will be executed, cause the combobox will do a
default
selection.
And by doing that it will run the method attachCamera

Actually I don't understand the flow of this re-factoring at all.

Why should the method "attachCamera" be executed upon every time a user
select a different item in this combobox ?

Actually it should only be executed when the user hits the "start
conference" button (or when the 5 second test recording is started).

What is the purpose of the refactored code ?

Sebastian




2013/3/15 seba.wag...@gmail.com <seba.wag...@gmail.com>

Sorry but there is a blocker.
When you enter the room type "conference room", the device settings
popup
does no more pop up.
And re-starting the device settings has no effect.
So you can't share audio/video at all.

And if you start the application using the debug URL, it pops up, but
it
tries to access the cam even _before_ you hit "start conference" ...
which
is also wrong.

I can see some:
ERROR @video/editRecordStreamSWF10.lzx≈512: TypeError: Error #1010

In the Debug window of the AS3 code (right hand). The effect in AS3 is
that all script after this error is never executed (and the error will
be
shown only the first time, the second, third, ... times it won't show
the
error and just not silently stop working.

This issue needs further investigation. But it definitly is not
possible
to release it like that. However it might be just a minor glitch that
is
easy to repair.

Sebastian


2013/3/15 "Ирина Архипец" <ia...@unipro.ru>

+1

Dear OpenMeetings Community,

I would like to start a vote about releasing Apache OpenMeetings
2.1.0
RC2
RC1 has multiple negative votes:

- [OPENMEETINGS-552] [OPENMEETINGS-561] [OPENMEETINGS-563] - issues
were
filed

- Release notes and documentation was incomplete

- RC1 performance and stability was not tested enough


Main changes are covered in the
Readme:
http://svn.apache.org/repos/asf/openmeetings/tags/2.1RC2/README
Full
Changelog:
http://svn.apache.org/repos/asf/openmeetings/tags/2.1RC2/CHANGELOG
Release
artefacts:
https://dist.apache.org/repos/dist/dev/openmeetings/2.1/rc2/
Tag:http://svn.apache.org/repos/asf/openmeetings/tags/2.1RC2/

PGP release keys (signed using C467526E):
https://dist.apache.org/repos/dist/dev/openmeetings/2.1/rc2/KEYS

Vote will be open for 72 hours.

[ ] +1  approve
[ ] +0  no opinion
[ ] -1  disapprove (and reason why)

My vote is +1.


--
WBR
Maxim aka solomax




--
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wag...@gmail.com



--
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wag...@gmail.com



--
WBR
Maxim aka solomax



--
WBR
Maxim aka solomax




Reply via email to