hopefully fixed, would appreciate if you can test latest nightly build
#250+ from here:
https://builds.apache.org/view/M-R/view/OpenMeetings/job/OpenMeetings%204.0.x/

On Thu, Mar 8, 2018 at 10:07 AM, Maxim Solodovnik <solomax...@gmail.com> wrote:
> Hello David,
>
> really sorry for delay
> finally found some time to try this
>
> I can confirm the issue is reproducible, Audio only stream is not being 
> recorder
> One of other users has created JIRA:
> https://issues.apache.org/jira/browse/OPENMEETINGS-1837
> Will try to fix it ASAP
>
> Thanks a lot for your detailed report and patience
>
> On Tue, Mar 6, 2018 at 4:32 AM, David Jentz <jen...@gmail.com> wrote:
>> Very interesting result on the demo server.
>>
>> Went in an interview room. Was getting vox indicators indicating mix was
>> working just as before.
>>
>> After stopping recording and exiting room, went to recordings. File is named
>> “interview 2018.03.05 22:22:35”
>>
>> Did get the “script” icon to show up indicating an error, but this only
>> happened for the interview recording not the others ( conference room via
>> desktop sharer )
>>
>> The two segments that had error codes ( exit code 1 ) were
>> stripAudioFromFLVs
>> And
>> checkFlvPod_1
>>
>> As for the server and client, we are trying to use centos 6.9 on both.
>>
>> Thanks for your help!
>> Dave
>>
>> On Sat, Mar 3, 2018 at 6:26 PM Maxim Solodovnik <solomax...@gmail.com>
>> wrote:
>>>
>>> I'll try to perform recording on demo
>>> Using cam "Disabled" and real mic
>>>
>>> Let's try to simplify the configuration:
>>> Could you test if recording works for you in interview room on demo
>>> server?
>>> And send the recording name, so I can check the logs
>>>
>>> In this case there will be no screen-sharing app, and I wonder if
>>> anything will change
>>>
>>> As far as I understand you server is CentOS, what are using as client
>>> machine, also CentOS?
>>>
>>> On Sun, Mar 4, 2018 at 7:39 AM, David Jentz <jen...@gmail.com> wrote:
>>> > No camera connected.
>>> >
>>> > In my last email I talked about using a fake camera, but that is not
>>> > really
>>> > an option for me. Would need to be using mic with no camera.
>>> >
>>> > -Dave
>>> >
>>> > On Sat, Mar 3, 2018 at 9:33 AM Maxim Solodovnik <solomax...@gmail.com>
>>> > wrote:
>>> >>
>>> >> hmm, flv file size from your camera is 186 bytes only
>>> >> seems to be no data at all :(((
>>> >> What camera are you using? what resolution?
>>> >>
>>> >> On Sun, Mar 4, 2018 at 12:22 AM, David Jentz <jen...@gmail.com> wrote:
>>> >> > Recording 2018.03.02 22:50:47
>>> >> >
>>> >> > Recording 2018.03.02 22:57:32
>>> >> >
>>> >> > Thank you.
>>> >> > -Dave
>>> >> >
>>> >> > On Fri, Mar 2, 2018 at 11:49 PM, Maxim Solodovnik
>>> >> > <solomax...@gmail.com>
>>> >> > wrote:
>>> >> >> Hello David,
>>> >> >>
>>> >> >> could you please provide the complete name of your recording on demo
>>> >> >> server?
>>> >> >> I'll check raw data, conversion logs and resulting file
>>> >> >>
>>> >> >> On Sat, Mar 3, 2018 at 8:16 AM, David Jentz <jen...@gmail.com>
>>> >> >> wrote:
>>> >> >>> 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
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> --
>>> >> >> WBR
>>> >> >> Maxim aka solomax
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> WBR
>>> >> Maxim aka solomax
>>>
>>>
>>>
>>> --
>>> WBR
>>> Maxim aka solomax
>
>
>
> --
> WBR
> Maxim aka solomax



-- 
WBR
Maxim aka solomax

Reply via email to