I tested using the same client computer/browser against the
openmeetings demo server and had the same result.
I guess this is saying its my client software?
I did notice something new that I hadn't notice before..come to find
out it was also on my local server as well (just did not notice): in
the top right hand corner of the URL bar there is a camera with a red
X in its bottom right corner. This is despite the fact that chromiums
setting for the site already permits access to both camera and
Hover over the camera with red X, it says: Camera blocked This page
has been blocked from accessing your camera
And then gives me 2 option radio buttons, 1 to Always allow <URL>
access to your camera and microphone
continue blocking camera and microphone access
And option 2 is on by default.
Thought I already fixed this via the site settings?
When I click option 1, and reload the page (openmeetings room), I get
a white box that says microhpone is on (but no image because I have no
camera). For about 1 second the camera icon in the URL bar has no red
X, maybe indicating it is working?
But then after about 1 second the openmeetings inset switches to a
head and sholders with ? on the head, presumably because I have no
camera. At this time the redX on the camera icon in the URL comes back
- appearing like my setting of granting access is not working.
My new guess is that microphone settings are not working in
openmeetings recordings because there is no camera. It is strange
though, Still getting the microphone is on text, still getting correct
vox indicators, and other users can still hear me. Only thing that
appears to be affected is the recordings, but unfortunately this is
important to us!
On Thu, Mar 1, 2018 at 10:06 PM, Maxim Solodovnik <solomax...@gmail.com> wrote:
> Is this issue reproducible for you on our demo server
> https://om.alteametasoft.com/openmeetings (latest 4.0.2 release) ?
> On Fri, Mar 2, 2018 at 1:04 PM, David Jentz <jen...@gmail.com> wrote:
>> Certainly, I will do anything I can do to help debug this.
>> Openmeetings is the recent 4.0.2 release.
>> The server and client are on same OS, red hat 6.9 ( close cousin to centos
>> client browser is chromium-browser 64.0.3282.119-1.el6_9.x86_64
>> java is java-1.8.0-openjdk-22.214.171.124-3.b14.el6_9.x86_64
>> believe desktop sharer is using
>> I think I would be able to provide any logs
>> I think I would be able to provide recorded videos/wav files
>> I think providing a login to our openmeetings instance might be problematic,
>> or remote access to our server (ie ssh/vnc)
>> Again, seems like audio is working just fine in the room (other users can
>> hear, mic VOX indicators working perfectly).
>> Video recorded via desktop sharer working perfectly
>> Just audio in the downloaded mp4 from the desktop sharer recorded video is
>> completely silent..(but audio track appears to be present).
>> On Thu, Mar 1, 2018 at 8:22 PM Vasiliy Degtyarev <va...@unipro.ru> wrote:
>>> Hello, Dave!
>>> I have checked recording on demo server, audio works as expected.
>>> Please explain more details: sharing PC OS, browser, java version.
>>> 01.03.2018 8:08, David Jentz пишет:
>>> > Testing in openmeetings 4.0.2 on linux (centos 6.9) server
>>> > Desktop sharer appears to make a mp4 just fine. Video playback is 100%
>>> > fine. Mp4 has audio embedded (playback in VLC indicates 200 blocks
>>> > decoded, 200 buffers played 0 buffers lost).
>>> > The sound being spoken into the microphone is not being recorded,
>>> > however. Instead the audio track appears to be completely silent.
>>> > Microphone in openmeetings appears to work OK. Other users in the same
>>> > openmeetings room can hear just fine.
>>> > Circle audio indicator in the openmeetings room user list appears to
>>> > be flashing when words spoken - even recorded in video created by
>>> > desktop sharer. All good.
>>> > Volume level bar in the users camera inset are also correctly
>>> > indicated when words spoken into microphone. This is also recorded in
>>> > the mp4 created by desktop sharer.
>>> > Think this may have been an issue for us in 4.0.1 also.
>>> > This was last known to work in 3.2.1
>>> > Found some files in the webapps/openmeetings/stream directories with
>>> > matching timestamps to the recordings.
>>> > The flv files played back with 0 audio buffers in vlc
>>> > The .wav file played back with 558 blocks, 558 buffers played, 0
>>> > buffers dropped, but also completely silent.
>>> > -Dave
> Maxim aka solomax