Good to know :)
Hopefully will be released soon :))
On Sun, Jan 14, 2018 at 2:46 AM, David Jentz wrote:
> 4.0.2 snapshot appears to be working! No issues on recording w/ audio.
> Thank you!
>
> Will be installing on our lab server for further test next week.
>
> -Dave
>
> On Sat, Jan 13, 2018 at
4.0.2 snapshot appears to be working! No issues on recording w/ audio.
Thank you!
Will be installing on our lab server for further test next week.
-Dave
On Sat, Jan 13, 2018 at 1:04 AM, Maxim Solodovnik wrote:
> Sure here you are :)
> https://builds.apache.org/view/M-R/view/OpenMeetings/job/Ope
Sure here you are :)
https://builds.apache.org/view/M-R/view/OpenMeetings/job/OpenMeetings%204.0.x/
On Sat, Jan 13, 2018 at 9:27 AM, David Jentz wrote:
> Very sorry, cannot seem to find 402 snapshot src tarball.
>
> Looked for some time. I tried using git but it turns out that is 5.0.0
>
> Any he
Very sorry, cannot seem to find 402 snapshot src tarball.
Looked for some time. I tried using git but it turns out that is 5.0.0
Any help please?
On Fri, Jan 12, 2018 at 5:44 PM, David Jentz wrote:
> I did try screen share. It works perfectly. Similarly
> screenshare/stopscreenshare/start scree
I did try screen share. It works perfectly. Similarly
screenshare/stopscreenshare/start screenshare causes laggy/crashy
behavior, but only in the screenshare app. Openmeetings is fine.
Closing the screenshare app/relaunching seems to work just fine as a
mitigation.
Also I did see some user (not me
start-stop-start recording works for me
Will try to double-check
On Fri, Jan 12, 2018 at 3:22 PM, David Jentz wrote:
> maybe for dead lock issue we can make a jira bug for later? I think
> this is also related to having desktop sharer not being able to work
> multiple times, IE click stop recordi
maybe for dead lock issue we can make a jira bug for later? I think
this is also related to having desktop sharer not being able to work
multiple times, IE click stop recording/start recording/stop
recording... gets really buggy after the first use. Workaround is very
trivial just close desktop sha
".IllegalStateException: DEAD LOCK" is known screen-sharing app issue,
it seems to affect nothing, and I have no free time right now to fix
it :(((
On Fri, Jan 12, 2018 at 7:46 AM, Maxim Solodovnik wrote:
> recorded flv with uppercase UUID in name == stream from your camera/mic
> recorded flv wit
recorded flv with uppercase UUID in name == stream from your camera/mic
recorded flv with lowercase UUID in name == stream form screen-sharing
application (video only)
Can you open one more browser and ensure camera AV stream is being
send to the room correctly?
Can you also check if the issue is
One more note, not sure if this is relevant.
>From the command line where I am launching the desktop sharer, I am
getting the following stack trace as soon as I push the stop recording
button:
java.lang.IllegalStateException: DEAD LOCK: IoFuture.await() was
invoked from an I/O processor thread. Pl
Looks like the file is only there during processing..after the Stop
recording button is pushed, but before the hourglass on the recording goes
away under my recordings.
for me the .ser file has size 0
the .flv file has size 186 bytes, so probably not valid size. I can do od
on this file, it seems
could you please manually check this file:
/var/opt/jcdx/red5/webapps/openmeetings/streams/7/rec_1_stream_A41BE6FE-4D8F-1A51-C32E-E1871A46045B_2018_01_10_19_25_14.flv
Does it have valid size?
Is it playable using VNC?
sometimes *.flv has size == 0, BUT there is file *.flv.ser with
correct size, is
I am having an issue with the desktop sharer recordings. I swear this
was working a week ago or so with no software change on OM 4.0.1...but
now this is consistently happening 100% on multiple OM servers.
I am very amatuer at reading this trace. Basically a note appears
along side each video recor
13 matches
Mail list logo
