A bit of follow up:

Concerned that chromium was the problem, I tried launching it with
these two arguments:

--use-file-for-fake-video-capture=blabla.y4m --use-fake-device-for-media-stream
found here
https://bugs.chromium.org/p/chromium/issues/detail?id=318797

While this does seem to solve the issue with chromium requiring a
video device /camera (and having the camera with red X otherwise),
desktop sharer is still not recording audio.
This technique does not solve the problem anyhow, because while it
does fake out video, it also fakes out audio..and precludes mic from
functioning without camera.

Even with the faked audio, still seems as if its not being recorded by
my client. Also with the faked audio, vox indicators still working
correctly. Not sure the chrome/camera issue was a real issue to begin
with.

-Dave

On Fri, Mar 2, 2018 at 2:24 PM, David Jentz <jen...@gmail.com> wrote:
> 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
> microphone.
>
> 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
>                                                               2
> 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!
>
> -Dave
>
> 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
>>> 6.9)
>>> client browser is chromium-browser 64.0.3282.119-1.el6_9.x86_64
>>> with
>>> chromium-pepper-flash-28.0.0126-1.x86_64
>>>
>>> java is java-1.8.0-openjdk-1.8.0.161-3.b14.el6_9.x86_64
>>>
>>> believe desktop sharer is using
>>> icedtea-web-1.6.2-1.el6.x86_64
>>>
>>> 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).
>>>
>>>
>>> -Dave
>>>
>>>
>>>
>>> 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.
>>>>
>>>> Thanks,
>>>> Vasiliy
>>>>
>>>> 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
>>>>
>>>
>>
>>
>>
>> --
>> WBR
>> Maxim aka solomax

Reply via email to