and please check the size of file:///opt/rooms.data/streams/7/rec_99_85007e70-36bc-4ab7-b769-8a614fc9faef.webm
from what I can see the recording was for 13seconds AFAIR on windows MM negotiation might take more time, so there might be no actual streaming (this is why it might be helpful to start sharing to check if the stream is flows) On Tue, 13 Oct 2020 at 09:47, Maxim Solodovnik <solomax...@gmail.com> wrote: > > Can you query your DB and share result with me > > `select * from recording_chunk where recording_id = 99` > > On Tue, 13 Oct 2020 at 02:33, Ali Alhaidary <ali.alhaid...@the5stars.org> > wrote: > > > > Hi Max, > > > > I went through your advice, however, I could not locate the reason why > > recording is terminated, attache log files of a fresh start of SQL, turn, > > media and om servers with only one login and directly to the room and > > started a recording which was unsuccessful. I do appreciate your help in > > that to reach a stable system. > > > > > > On 10/11/20 10:48 AM, Maxim Solodovnik wrote: > > > > Hello Ali, > > > > I see nothing suspicious > > I would try to find logs written at the time of error > > > > while testing I'm starting sharing with record then > > 1) enter the same room as user B > > 2) check if sharing displayed as expected > > 3) check if file was created on FS and growing > > > > if any of the above is not true: time to stop everything and check logs and > > permissions > > > > On Sun, 11 Oct 2020 at 06:09, Ali Alhaidary <ali.alhaid...@the5stars.org> > > wrote: > >> > >> Also the following WARs; > >> > >> 2020-10-10T22:51:27,997811 1492 0x00007f7584a87700 warning rtpsource > >> rtpsource.c:1147 update_receiver_stats() duplicate or reordered > >> packet (seqnr 29273, expected 29278) > >> > >> 2020-10-10T22:51:32,823234 1492 0x00007f7585288700 warning > >> recorderendpoint kmsrecorderendpoint.c:1275 > >> kms_recorder_endpoint_on_eos() <kmsrecorderendpoint37> Releasing pending > >> pads > >> > >> > >> On 10/11/20 2:07 AM, Ali Alhaidary wrote: > >> > >> Hi Max, > >> > >> I can find the following in the media server log: > >> > >> 2020-10-10T22:51:13,421433 1492 0x00007f7585a89700 fixme default > >> gstutils.c:3766 gst_pad_create_stream_id_internal() > >> <videoSrc:src> Creating random stream-id, consider implementing a > >> deterministic way of creating a stream-id > >> 2020-10-10T22:51:13,421843 1492 0x00007f7584286700 fixme basesink > >> gstbasesink.c:3125 gst_base_sink_default_event() <filesink38> > >> stream-start event without group-id. Consider implementing group-id > >> handling in the upstream elements > >> > >> has it to do anything with the connection fail issue? > >> > >> > >> On 10/9/20 4:57 AM, Maxim Solodovnik wrote: > >> > >> The only thing I can see here: the stream from screen-sharing is not found > >> on the HDD when the recording file is created > >> > >> All room streams are dumped to the FS while recording is active, > >> Later on "movie" is created out of these recorded streams > >> > >> Most usual situations for this: > >> 1) FS permission issue > >> 2) something wrong with screen-sharing on the client > >> > >> so you have to check all folders in DATA_DIR are owned by correct user > >> check KMS logs (due to streams are saved to FS by KMS) > >> > >> On Thu, 8 Oct 2020 at 23:37, Ali Alhaidary <ali.alhaid...@the5stars.org> > >> wrote: > >>> > >>> Thank you Max, but recordings are not ok whenever this error is there, it > >>> shoes a red movie icon with a triangle next to it, but in each time, > >>> connection to media server is not established after choosing to record. > >>> There is no other 'ERROR' in openmeeting.log or catalina.out > >>> > >>> However, this seems to be random (up to my observation) there is no > >>> pattern I can see when recordings are good, and when they are not. > >>> > >>> We have spent some good time contributing to make this software stable > >>> and usable in three languages, and we are very serious in putting it as > >>> our standard online lecturing software, but it is obvious that we are > >>> missing something :-( > >>> > >>> > >>> On 10/6/20 6:29 AM, Maxim Solodovnik wrote: > >>> > >>> Well > >>> It can be ignored in case recording is OK .... ;) > >>> > >>> from mobile (sorry for typos ;) > >>> > >>> > >>> On Tue, Oct 6, 2020, 09:44 Ali Alhaidary <ali.alhaid...@the5stars.org> > >>> wrote: > >>>> > >>>> Thank you Max, it has the magic word "ignored"... :-) > >>>> > >>>> Ali > >>>> > >>>> On 10/6/20 4:21 AM, Maxim Solodovnik wrote: > >>>> > >>>> this one is usually reported when recording stream (of camera/microphone > >>>> or screen-sharing) > >>>> was not found on the file system > >>>> > >>>> it might be ignored if it is some small chunk created while devices were > >>>> switched on/off > >>>> > >>>> > >>>> On Tue, 6 Oct 2020 at 03:01, Ali Alhaidary <ali.alhaid...@the5stars.org> > >>>> wrote: > >>>>> > >>>>> ERROR 10-04 21:40:50.684 o.a.o.c.c.RecordingConverter:100 > >>>>> [taskExecutor-1] - [startConversion] > >>>>> org.apache.openmeetings.core.converter.ConversionException: > >>>>> screenMetaData is Null recordingId 59 > >>>>> at > >>>>> org.apache.openmeetings.core.converter.RecordingConverter.startConversion(RecordingConverter.java:58) > >>>>> at > >>>>> org.apache.openmeetings.core.remote.StreamProcessor.lambda$startConvertion$10(StreamProcessor.java:481) > >>>>> at > >>>>> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > >>>>> at > >>>>> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > >>>>> at java.base/java.lang.Thread.run(Thread.java:834) > >>>>> > >>>>> Can anyone help please? > >>>>> > >>>> > >>>> > >>>> -- > >>>> Best regards, > >>>> Maxim > >> > >> > >> > >> -- > >> Best regards, > >> Maxim > > > > > > > > -- > > Best regards, > > Maxim > > > > -- > Best regards, > Maxim -- Best regards, Maxim
