Galicaster 2.1 records only 1 sec

[Stefanos Georgopoulos]

Hi community,

This is the second time this week (1st semester week in 2 different
locations) where Galicaster stops scheduled recording (for 1h 40m) after
1 sec

log
galicaster 2018-04-12 12:11:59,600 INFO opencast/client Sending
state idle
galicaster 2018-04-12 12:11:59,600 INFO scheduler/scheduler
Start time for recording 4684877148068430848, duration 0 ms
galicaster 2018-04-12 12:11:59,608 INFO plugins/screensaver
Simulate user activity
galicaster 2018-04-12 12:11:59,617 INFO plugins/screensaver
Deactivated screensaver
galicaster 2018-04-12 12:11:59,618 INFO recorder/service
Recording (current status: preview)
galicaster 2018-04-12 12:11:59,618 INFO recorder/service
Recording to MP 4684877148068430848
galicaster 2018-04-12 12:11:59,618 INFO plugins/forcedurationrec
Timer initialized to stop a record in 240 minutes
galicaster 2018-04-12 12:11:59,643 INFO mediapackage/repository
Temporary data saved to /home/galicaster/Repository/rectemp/info.json
galicaster 2018-04-12 12:11:59,644 INFO scheduler/scheduler
End time for recording 4684877148068430848
galicaster 2018-04-12 12:11:59,644 INFO recorder/service
Stopping the capture
galicaster 2018-04-12 12:11:59,644 DEBUG recorder/recorder
Stopping recorder, sending EOS event to sources

Opencast server version 3.5

Does anyone else have similar Problems? I didn't change anything in the
config files.

Any help will be appreciated!!

Regards
Stefanos
--
Dipl.- Inf. (FH) Stefanos Georgopoulos
Multimedia & E-Learning https://www.fau.tv
Friedrich-Alexander-Universität Erlangen-Nürnberg
Regionales RechenZentrum Erlangen (RRZE)
Martensstraße 1, 91058 Erlangen, Germany
Tel. +49 9131 85-20190, Fax +49 9131 302941
stefanos.g...@fau.de
www.rrze.fau.de

Jubiläumsjahr 2018 - IT in Bewegung
Das RRZE - der IT-Dienstleister der FAU
www.50-jahre.rrze.fau.de

[Andrew Wilson]

Check what forcedurationrec is doing. We dont use this plugin, but just glancing at the log output you sent, it makes me suspicious

I could be totally wrong

-andy

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to community+...@galicaster.org.
To post to this group, send email to comm...@galicaster.org.

[Stefanos Georgopoulos]

Hi Andrew,

Thanks for the hint.

I will deactivate force duration plugin in all CAs except one and I
will monitoring the behaviour. Although I had it with 2.0.x enabled
without any problem.

-Stefanos

[Paul Pettit]

Hi,

i don't think the forced duration plugin is the culprit:

galicaster      2018-04-12 12:11:59,600 INFO    scheduler/scheduler Start time for recording 4684877148068430848, duration 0 ms

looks like the scheduler thinks the recording should be 0 secs long.

i guess the first thing to check is that the opencast schedule is correct and that the ical feed makes sense?

Paul.

>> email to community+unsubscribe@galicaster.org.

>> To post to this group, send email to comm...@galicaster.org.
>>
>

--
Dipl.- Inf. (FH) Stefanos Georgopoulos
Multimedia & E-Learning https://www.fau.tv
Friedrich-Alexander-Universität Erlangen-Nürnberg
Regionales RechenZentrum Erlangen (RRZE)
Martensstraße 1, 91058 Erlangen, Germany
Tel. +49 9131 85-20190, Fax +49 9131 302941
stefanos.g...@fau.de
www.rrze.fau.de

Jubiläumsjahr 2018 - IT in Bewegung
Das RRZE - der IT-Dienstleister der FAU
www.50-jahre.rrze.fau.de

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+unsubscribe@galicaster.org.

[Stefanos Georgopoulos]

Hi Paul,

On 04/12/2018 01:32 PM, Paul Pettit wrote:
> Hi,
>
> i don't think the forced duration plugin is the culprit:
>
> galicaster 2018-04-12 12:11:59,600 INFO scheduler/scheduler Start
>> time for recording 4684877148068430848, duration 0 ms
>
>
> looks like the scheduler thinks the recording should be 0 secs long.
>
> i guess the first thing to check is that the opencast schedule is correct

> and that the ical feed makes sense?You have right. Both problems occurred when I had to change the events
timestamps from opencast server. Due to lack of timetabling system I
have to do all the job manually. So,if a series from Opencast is
programmed every Mo and Th at 10:12 but the lecture starts at on
Thursday at 12:15 as today I have to change the timestamp from admin
ui. The same situation was on Tuesday.

I have another one, today in 2 hours. I set a repeated event every Mon
and Thur start time 10:12 for 1h and 40m -> change all Thursday events
from admin ui to start on 16:12 local time

BEGIN:VCALENDAR
PRODID:Opencast Matterhorn Calendar File 0.5
VERSION:2.0
CALSCALE:GREGORIAN
BEGIN:VEVENT
DTSTAMP:20180412T050146Z
DTSTART:20180412T141200Z
DTEND:20180412T155200Z
SUMMARY:Theorie der Programmierung 02
UID:2839044881814800384
ORGANIZER;CN=Prof. Dr. Lutz
Schröder:mailto:Prof.%20Dr.%20Lutz%20Schröd...@matterhorn.opencast
LOCATION:H9

The ical in galicaster seems fine. So this is a lack of sync between
gali and oc admin node?

-Stefanos

>>>> email to community+...@galicaster.org.

>>>> To post to this group, send email to comm...@galicaster.org.
>>>>
>>>
>>
>> --
>> Dipl.- Inf. (FH) Stefanos Georgopoulos
>> Multimedia & E-Learning https://www.fau.tv
>> Friedrich-Alexander-Universität Erlangen-Nürnberg
>> Regionales RechenZentrum Erlangen (RRZE)
>> Martensstraße 1, 91058 Erlangen, Germany
>> Tel. +49 9131 85-20190, Fax +49 9131 302941
>> stefanos.g...@fau.de
>> www.rrze.fau.de
>>
>> Jubiläumsjahr 2018 - IT in Bewegung
>> Das RRZE - der IT-Dienstleister der FAU
>> www.50-jahre.rrze.fau.de
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Galicaster-Community" group.
>> To unsubscribe from this group and stop receiving emails from it, send an

>> email to community+...@galicaster.org.

[Hans Erasmus]

Hi All

 

Anyone find a solution for this?

 

I have the same issue now.  Ical seems fine, but the recording basically failed, and the logs show:

galicaster 2018-07-24 10:59:09,434 DEBUG scheduler/heartbeat galicaster-notify-short in 10
galicaster 2018-07-24 10:59:09,434 INFO opencast/service Set status idle to server
galicaster 2018-07-24 10:59:09,434 INFO opencast/client Sending state idle
galicaster 2018-07-24 10:59:19,434 DEBUG scheduler/heartbeat galicaster-notify-short in 10
galicaster 2018-07-24 10:59:19,434 INFO opencast/service Set status idle to server
galicaster 2018-07-24 10:59:19,434 INFO opencast/client Sending state idle
galicaster 2018-07-24 10:59:29,434 DEBUG scheduler/heartbeat galicaster-notify-short in 10
galicaster 2018-07-24 10:59:29,435 INFO opencast/service Set status idle to server
galicaster 2018-07-24 10:59:29,435 INFO opencast/client Sending state idle
galicaster 2018-07-24 10:59:39,435 DEBUG scheduler/heartbeat galicaster-notify-short in 10
galicaster 2018-07-24 10:59:39,435 INFO opencast/service Set status idle to server
galicaster 2018-07-24 10:59:39,435 INFO opencast/client Sending state idle
galicaster 2018-07-24 10:59:49,435 DEBUG scheduler/heartbeat galicaster-notify-short in 10
galicaster 2018-07-24 10:59:49,435 INFO opencast/service Set status idle to server
galicaster 2018-07-24 10:59:49,435 DEBUG scheduler/heartbeat galicaster-notify-long in 60
galicaster 2018-07-24 10:59:49,435 INFO opencast/client Sending state idle
galicaster 2018-07-24 10:59:49,446 INFO opencast/service Process ical
galicaster 2018-07-24 10:59:49,455 INFO opencast/client iCal Not modified
galicaster 2018-07-24 10:59:49,480 INFO opencast/service Updating series from server
galicaster 2018-07-24 10:59:49,832 INFO opencast/service Setting CA configuration to server
galicaster 2018-07-24 10:59:59,435 DEBUG scheduler/heartbeat galicaster-notify-short in 10
galicaster 2018-07-24 10:59:59,435 INFO opencast/service Set status idle to server
galicaster 2018-07-24 10:59:59,435 INFO scheduler/scheduler Start time for recording 8902994272283085824, duration 0 ms
galicaster 2018-07-24 10:59:59,435 INFO opencast/client Sending state idle
galicaster 2018-07-24 10:59:59,435 INFO recorder/service Recording (current status: preview)
galicaster 2018-07-24 10:59:59,436 INFO recorder/service Recording to MP 8902994272283085824
galicaster 2018-07-24 10:59:59,445 INFO mediapackage/repository Temporary data saved to /home/galicaster/Repository/rectemp/info.json
galicaster 2018-07-24 10:59:59,445 INFO scheduler/scheduler End time for recording 8902994272283085824
galicaster 2018-07-24 10:59:59,445 INFO recorder/service Stopping the capture
galicaster 2018-07-24 10:59:59,445 DEBUG recorder/recorder Stopping recorder, sending EOS event to sources
galicaster 2018-07-24 10:59:59,446 INFO opencast/service Sending state capturing for the scheduled MP (u'8902994272283085824', u'SKILLS OF THERAPEUTIC DIALOGUE - 2', datetime.datetime(2018, 7, 24, 8, 59, 59))
galicaster 2018-07-24 10:59:59,541 DEBUG recorder/recorder EOS message successfully received
galicaster 2018-07-24 10:59:59,653 INFO recorder/service Adding new mediapackage (8902994272283085824) to the repository
galicaster 2018-07-24 10:59:59,666 INFO mediapackage/repository Repository temporary files removed
galicaster 2018-07-24 10:59:59,668 INFO opencast/service Sending state capture_finished for the scheduled MP (u'8902994272283085824', u'SKILLS OF THERAPEUTIC DIALOGUE - 2', datetime.datetime(2018, 7, 24, 8, 59, 59))
galicaster 2018-07-24 10:59:59,694 INFO core/worker Creating Ingest Job for MP 8902994272283085824
galicaster 2018-07-24 10:59:59,701 INFO core/worker Executing Ingest for MP 8902994272283085824
galicaster 2018-07-24 10:59:59,701 INFO recorder/service Starting recording service in the preview status
galicaster 2018-07-24 10:59:59,702 INFO recorder/service Using profile with name IPCam+DP+2Line and path /etc/galicaster/profiles/IPCam+DP+2Line.ini
galicaster 2018-07-24 10:59:59,703 DEBUG recorder/recorder Init bin MegaPixel IPCam galicaster.recorder.bins.rtp
galicaster 2018-07-24 10:59:59,705 DEBUG recorder/utils Video sink: sink-MegaPixelIPCam -> xvimagesink
galicaster 2018-07-24 10:59:59,705 DEBUG recorder/utils Audio sink: sink-audio-MegaPixelIPCam -> alsasink
galicaster 2018-07-24 10:59:59,713 INFO core/worker Zipping MP 8902994272283085824 to /tmp/tmpgpQTGv
galicaster 2018-07-24 10:59:59,713 DEBUG recorder/recorder Init bin Datapath galicaster.recorder.bins.v4l2
galicaster 2018-07-24 10:59:59,713 DEBUG mediapackage/serializer Using System Zip
galicaster 2018-07-24 10:59:59,715 DEBUG recorder/utils Video sink: sink-Datapath -> xvimagesink
galicaster 2018-07-24 10:59:59,748 INFO opencast/client Ingesting MP 8902994272283085824 to Server OUR_Server

galicaster 2018-07-24 10:59:59,769 DEBUG recorder/recorder Init bin Line In galicaster.recorder.bins.pulse
galicaster 2018-07-24 10:59:59,770 DEBUG recorder/utils Audio sink: sink-LineIn -> alsasink
galicaster 2018-07-24 10:59:59,772 DEBUG recorder/recorder Init bin Translator Line In galicaster.recorder.bins.pulse
galicaster 2018-07-24 10:59:59,772 DEBUG recorder/utils Audio sink: sink-TranslatorLineIn -> alsasink
galicaster 2018-07-24 10:59:59,777 DEBUG recorder/recorder recorder preview
galicaster 2018-07-24 11:00:00,069 INFO core/worker Finalized Ingest for MP 8902994272283085824
galicaster 2018-07-24 11:00:09,435 DEBUG scheduler/heartbeat galicaster-notify-short in 10
galicaster 2018-07-24 11:00:09,436 INFO opencast/service Set status idle to server
galicaster 2018-07-24 11:00:09,436 INFO opencast/client Sending state idle
galicaster 2018-07-24 11:00:19,434 DEBUG scheduler/heartbeat galicaster-notify-short in 10
galicaster 2018-07-24 11:00:19,434 INFO opencast/service Set status idle to server
galicaster 2018-07-24 11:00:19,435 INFO opencast/client Sending state idle
galicaster 2018-07-24 11:00:29,434 DEBUG scheduler/heartbeat galicaster-notify-short in 10
galicaster 2018-07-24 11:00:29,434 INFO opencast/service Set status idle to server
galicaster 2018-07-24 11:00:29,434 INFO opencast/client Sending state idle

Forceduration plugin is disabled. And although NTP sync not running, the time on the PC is within a few seconds of the server, so it should not make any difference (not in this case anyways).

 

Problem is our lecturers all schedule the videos themselves. So we have no way of knowing if and when they edit or change the schedule. 

 

Any ideas?

 

Thanks in advance

 

HE

 

Vrywaringsklousule / Disclaimer: http://www.nwu.ac.za/it/gov-man/disclaimer.html

>>> Stefanos Georgopoulos <stefanos.g...@fau.de> 4/12/2018 1:55 PM >>>

[Hans Erasmus]

One line making me supsicious, is the following one:

 

galicaster 2018-07-24 10:59:59,446 INFO opencast/service Sending state capturing for the scheduled MP (u'8902994272283085824', u'SKILLS OF THERAPEUTIC DIALOGUE - 2', datetime.datetime(2018, 7, 24, 8, 59, 59))

Is there a way I can set the date/time in Galicaster? Is this needed?

 

timedatectl status
      Local time: Tue 2018-07-24 11:37:26 SAST
  Universal time: Tue 2018-07-24 09:37:26 UTC
        RTC time: Tue 2018-07-24 09:37:27
       Time zone: Africa/Johannesburg (SAST, +0200)
 Network time on: yes
NTP synchronized: no
 RTC in local TZ: no

And also, if this was needed, why don't the recordings that are not edited, work correctly?

 

Output of failed recording's xml on GC Agent:

<?xml version="1.0" encoding="utf-8"?>
<dublincore xmlns="http://www.opencastproject.org/xsd/1.0/dublincore/" xmlns:dcterms="http://purl.org/dc/terms/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance/">
   <dcterms:rightsHolder>NWU</dcterms:rightsHolder>
   <dcterms:license>ALLRIGHTS</dcterms:license>
   <dcterms:created>2018-07-19T14:14:20Z</dcterms:created>
   <dcterms:temporal>start=2018-07-24T09:00:00Z; end=2018-07-24T10:30:00Z; scheme=W3C-DTF;</dcterms:temporal>
   <dcterms:spatial>CA</dcterms:spatial>
   <dcterms:isPartOf>90cf2f53-b62e-4e2a-802f-e9877efa1887</dcterms:isPartOf>
   <dcterms:title>SKILLS OF THERAPEUTIC DIALOGUE - 2</dcterms:title>
   <dcterms:identifier>8902994272283085824</dcterms:identifier>
   <dcterms:subject>SKILLS OF THERAPEUTIC DIALOGUE - 2</dcterms:subject>
</dublincore>
~                                                                                  

 

 

Vrywaringsklousule / Disclaimer: http://www.nwu.ac.za/it/gov-man/disclaimer.html

>>> "Hans Erasmus" <Hans.E...@nwu.ac.za> 7/24/2018 11:34 AM >>>

[Stefanos Georgopoulos]

Hi Hans,

very interesting. I though that this has to do with my setup. Which
version of opencast do you have in prod?

My "solution" was to delete and create again all the events. I found out
that changing the metadata (title, contributor) after the schedule then
this problem occurred.

We still have 2 remaining NCasts in prod but they started/stoped,
without any problem, in the scheduled duration.

-Stefanos

> ( http://openc-adm-lnx1.nwu.ac.za/) _Server

[Hans Erasmus]

Hi Stefanos

 

This is a combo of GC 2.1.0 and Opencast 2.3.0. It seems to me as well that the issue is not always there, so I will have to try and schedule a 5 minute recording, without editing it, and see what happens, then schedule a new one, where I edit the data, and see what happens, on the same machine. Will report back with logs.

 

Regards

 

HE

 

Vrywaringsklousule / Disclaimer: http://www.nwu.ac.za/it/gov-man/disclaimer.html

>>> Stefanos Georgopoulos <stefanos.g...@fau.de> 7/24/2018 11:44 AM >>>

[Hans Erasmus]

Quick update. Found multitude of changes made in the xml files of the mediapackages once you edit the event. But, we are looking into whether the problem is on our OC side or the GC side.  Will keep you posted Stefanos.

 

Regards

 

HE

 

Vrywaringsklousule / Disclaimer: http://www.nwu.ac.za/it/gov-man/disclaimer.html

>>> Stefanos Georgopoulos <stefanos.g...@fau.de> 7/24/2018 11:44 AM >>>

[Stefanos Georgopoulos]

Hi Hans,

this "bug" drove me nuts last semester. I tried a lot of things but
because I am responsible for scheduling the recordings, I decided to
re-schedule and change the metadata in the Opencast editor.

Best of luck!

-Stefanos

[Hans Erasmus]

Hi All

 

So after loads of tests, it boiled down to the following.

 

If you update the metadata of an upcoming event before the initial ical was received by the CA, the recording will still work properly. No issues.

However, if you update the metadata of the upcoming event AFTER the ical was initially received by the CA, some funky stuff happens. See below xml excerpts:

 

Upon initial schedule, the manifest.xml looks like this:

 

<?xml version="1.0" encoding="utf-8"?>

<mediapackage duration="2100000" id="4325643011955787776" start="2018-07-25T06:00:00" xmlns="http://mediapackage.opencastproject.org">
   <media/>
   <metadata>
      <catalog id="catalog-0" type="dublincore/episode">
         <mimetype>text/xml</mimetype>
         <url>episode.xml</url>
         <tags>
            <tag>engage</tag>
         </tags>
      </catalog>
      <catalog id="catalog-1" type="dublincore/series">
         <mimetype>text/xml</mimetype>
         <url>series.xml</url>
         <tags>
            <tag>engage</tag>
         </tags>
      </catalog>
   </metadata>
   <attachments>
      <attachment id="org.opencastproject.capture.agent.properties" ref="" type="">
         <mimetype>None</mimetype>
         <url>org.opencastproject.capture.agent.properties</url>
         <tags>
            <tag>engage</tag>
         </tags>
      </attachment>
   </attachments>
</mediapackage>

BUT, after the edit of the of any of the metadata:

 

<?xml version="1.0" encoding="utf-8"?>

<mediapackage id="4325643011955787776" start="2018-07-25T06:00:00" xmlns="http://mediapackage.opencastproject.org">
   <media/>
   <metadata>
      <catalog id="catalog-0" type="dublincore/episode">
         <mimetype>text/xml</mimetype>
         <url>episode.xml</url>
         <tags>
            <tag>engage</tag>
         </tags>
      </catalog>
      <catalog id="catalog-1" type="dublincore/series">
         <mimetype>text/xml</mimetype>
         <url>series.xml</url>
         <tags>
            <tag>engage</tag>
         </tags>
      </catalog>
   </metadata>
   <attachments>
      <attachment id="org.opencastproject.capture.agent.properties" ref="" type="">
         <mimetype>None</mimetype>
         <url>org.opencastproject.capture.agent.properties</url>
         <tags>
            <tag>engage</tag>
         </tags>
      </attachment>
   </attachments>
</mediapackage>

 

Notice, the duration is gone? So this seems to be the problem, at least one of them.  But, as I stated, if you edit the metadata on the opencast server before the MP is created on the CA, the recording works as expected.

 

Any idea how the hell I'm gonna fix this? Our users schedule themselves, and asking them "please don't edit metadata after initial scheduling" is not really an option!

 

Regards

 

HE

 

 

 

 

Vrywaringsklousule / Disclaimer: http://www.nwu.ac.za/it/gov-man/disclaimer.html

>>> Stefanos Georgopoulos <stefanos.g...@fau.de> 7/24/2018 3:36 PM >>>

[Paul Pettit]

hi Hans,

i'm looking at upgrading from OC 3->5 soon but not started testing with galicaster yet so i have yet to experience this (confirmed there is no problem on OC3 and GC2.0).

but looking at github there are a number of changes after 2.1 was released to the ical code, some of which explicitly says it is to support OC4.

have you tried the latest git version?

is anybody actually using galicaster with OC 4+ yet?

thanks,

paul.

[Ruth Lang]

Hi,

we are running OC 4.x since March and ran into the same problems at the beginning.

After a scheduled event was successfully recorded and uploaded, the next scheduled events were deleted.

After we have included the mentioned patch and deleted all schedules, it was quite stable since last Friday.

Once a week a schedule did not start. Normally we detected this problem and startet the recording manually. 

Now we have this problem again. No idea why.

Fortunately the semester has finished last Friday :-)

Ruth

_______________________________

Universität zu Köln

Regionales Rechenzentrum (RRZK)
Weyertal 121, Raum 4.08
D-50931 Köln
✆:  +49-221-470-89618
rrzk.uni-koeln.de
facebook.com/rrzkoeln

[Paul Pettit]

hi Ruth,

which patch are you referring to?

Thanks,

Paul.

[Hans Erasmus]

Hi Paul

No have not tried the latest git version. Will possibly have to and see where it leads. This is now in production, so I am screwed. We tested all other scenarios, like creating and deleting but never really in depth editing of the metadata before recording (it was always a non-issue). So it seems the list of tests just got a little longer. But this sucks atm. Will see if the ical code will make a difference, but seeing as we are on OC 2.3.0, not sure if the fixes will help us at all. Hopefully it does, but not holding my breath.

Regards

HE 

 

Vrywaringsklousule / Disclaimer: http://www.nwu.ac.za/it/gov-man/disclaimer.html

>>> Paul Pettit <p.pe...@keele.ac.uk> 07/24/18 5:12 PM >>>

[Paul Pettit]

Hi Hans,

in that case if it does not work with the latest git version i would go back to 2.0 if you can. i think this error is most likely on the galicaster side and if you are only using OC2.3 then GC2.0 should work fine.

good luck!

paul.

[Hans Erasmus]

Hi Paul

Thanks. Saw on github there was an issue raised https://github.com/teltek/Galicaster/issues/567. But from what I gather (and I am in no shape or form a coder myself, whatsoever, it seems that this bit of logic is implemented when creating a new mp, but NOT when one is updated. Hence the loss of the element "duration" in the regenerated manifest.xml. Was hoping someone on the list could see how the logic worked and advise on how difficult it would be to implement a fix/patch? Still wondering whether this behaviour will not present itself even on OC > 2/3/4. Seeing as GC recreates the manifest, with new parameters. So maybe the problem can be reproduced on newer OC installs as well. The important thing to note when trying to replicate this issue, is to check whether the initial ical has been received by the CA before updating the metadata on the OC admin server. As I stated, all is well if the ical has not been received yet, and therefore the MP has not been created yet. And looking at the code, even with my limited knowledge, it would seem to make sense regarding the differences in behaviour when editing the metadata before and after the ical has been received on the CA.

Just my 2c.  Was hoping not to have to revert back to GC2.0. 2.1 had fixes for other issues we had which is making my life more pleasurable atm. So will give it a day or so before deciding.

Regards

HE

Vrywaringsklousule / Disclaimer: http://www.nwu.ac.za/it/gov-man/disclaimer.html

>>> Paul Pettit <p.pe...@keele.ac.uk> 07/24/18 6:48 PM >>>

[Ruth Lang]

Hi Paul,

I used the branch https://github.com/teltek/Galicaster/tree/bugfix_oc4/galicaster 

and added the patch for routine ical.py.

This region caused definitely - may be not the only one  - our trouble.

Ruth

[Paul Pettit]

hi Ruth,

thanks, yeah that "ical events: Refactored ical logic" patch is merged to 2.1.x and master branches, but is after the 2.1 release so it is possible it fixes things for Hans.

i'll see if i can do some testing soon when i get the chance.

paul.

[Ruth Lang]

Hi Paul,

that would be great, because the problem never vanished completely.

Best

Ruth

[Paul Pettit]

hi Hans,

i've done some testing with OC3 and OC5 (the only 2 versions I have installations of) and can not replicate your issue either with GC 2.1 released version or the 2.1.x branch with the extra ical changes.

just to confirm, i tested by:

• creating a scheduled event
  
• waiting for galicaster to pick it up
  
• change various metadata
  
• wait for galicaster to pick up the changes
  
• check the duration is correct in the manifest.xml on galicaster
  
• check actual recording is the correct duration
  

this worked correctly (well almost, but that is another issue - it seems some metadata changes are not picked up by galicaster and so are overridden when the event is ingested back to OC) in all version combinations mentioned above.

i'm afraid that doesn't really help you very much :(

paul.

[Hans Erasmus]

Hi Paul

Thank you so much. Those steps are exactly what I follow. What bothers me, is the XML on the OC side changes the metadata I want it to change, but it is as if GC2.1 does not "rebuild" the manifest.xml correctly. But what you are saying is, if you make the changes on OC3 and 5, the duration parameter is kept in manifest.xml, and not deleted like in mine? I am wondering if there might be an end-point difference between the 2 operations then? One endpoint on OC for creating the event, and another if the event is updated, and that GC actually uses 2 different end-points for the two separate scenarios?

Crap.

Thanks Paul

Cheers

HE

 

Vrywaringsklousule / Disclaimer: http://www.nwu.ac.za/it/gov-man/disclaimer.html

>>> Paul Pettit <p.pe...@keele.ac.uk> 07/25/18 12:18 PM >>>

[Paul Pettit]

Hi Hans,

Yes, for me, following those steps the duration parameter is kept in the manifest.xml and the recording goes ahead with the correct duration.

As far as I can see, galicaster only uses the /recordings/calendars OC endpoint to get details of the upcoming recordings. this is the ical feed. I think the problem more likely comes in galicaster's logic for determining whether an event has been added/deleted/updated ad this code has change quite a bit recently, especially to take account of OC4+ separating the start/end/duration metadata from the actual start/end/duration which are now 2 separate things (for example the metadata could say "start at 10:00 and duration 1 hour" but the actual recording could be "start at 09:55 and record for 1:10"). I don't remember there being much of a change between OC2 and OC3 but it is a long time since I did that upgrade so I may be forgetting something!

As for the galicaster code, just from looking at it, the only difference between adding and updating an event is that if the event id exists in the repo it retrieves it and starts with that as the base, and if not it sets up a new blank Mediapackage object and uses that. all the rest (setting the start/duration etc) is done with exactly the same code as far as i can see.

So I am a bit lost as to what the difference could be without being able to replicate the problem :(

Sorry I've not been very helpful.

Paul.

[Hans Erasmus]

Hi Paul

Thank you!  And no, you have been VERY helpful.

One of the "workarounds I tried to implement this morning was to check for any manifest.xml file which did not contain the duration parameter, and removing the folder (mp) in the Repository directory. But it seems the checkrepo plugin only checks for the schedules upon boot, it is not something that is checked periodically. My idea was, although a bad and filthy one, to check for the files where the duration is not written, then delete the folders in order for GC to recreate the mp. As I am typing this I have another idea in mind, which might also work, but will have to see.

Will report back!  Thanks Paul

HE

 

Vrywaringsklousule / Disclaimer: http://www.nwu.ac.za/it/gov-man/disclaimer.html

>>> Paul Pettit <p.pe...@keele.ac.uk> 07/25/18 1:22 PM >>>

[Alfonso Rodriguez]

Hello everyone,

I'm taking a look at this issue as well, and so far I have failed to reproduce it. My current set-up is:

• Opencast 2.3.0 all-in-one docker.
• Galicaster 2.1.0 source tag
  
• Test profile + default configuration
  

I can't reproduce it with this setup. I followed the same steps as Paul Pettit:

• creating a scheduled event
  
• waiting for galicaster to pick it up
  
• change various metadata
  
• wait for galicaster to pick up the changes
  
• check the duration is correct in the manifest.xml on galicaster
  
• check actual recording is the correct duration

Just to make sure, is everyone having the same issue? I think Hans and Stefanos are, but Ruth seems to be talking about the issue with Opencast 4.x onwards sending unordered events to Galicaster, whose fix wasn't merged until after 2.1.0 was released.

Alfonso Rodríguez Pereira
TELTEK Video Research
http://teltek.es/


La información contenida en este mensaje y/o archivo(s) adjunto(s) es confidencial/privilegiada y está destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Si usted lee este mensaje y no es el destinatario señalado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicación por error, le informamos que está totalmente prohibida, y puede ser ilegal, cualquier divulgación, distribución o reproducción de esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la dirección arriba mencionada. Gracias.

The information contained in this message and/or attached file(s) is confidential/privileged and is intended to be read only by the person(s) to whom it is directed. If you are reading this message and you are not the indicated recipient, or the employee or agent responsible for delivering the message to the addressee, or you have received this communication by mistake, please be aware that any dissemination, distribution or reproduction of this communication is strictly prohibited and may be illegal. Please notify us immediately and return the original message to the aforementioned address. Thank you.

On 25 July 2018 at 14:02, Hans Erasmus <Hans.E...@nwu.ac.za> wrote:

Hi Paul

Thank you!  And no, you have been VERY helpful.

One of the "workarounds I tried to implement this morning was to check for any manifest.xml file which did not contain the duration parameter, and removing the folder (mp) in the Repository directory. But it seems the checkrepo plugin only checks for the schedules upon boot, it is not something that is checked periodically. My idea was, although a bad and filthy one, to check for the files where the duration is not written, then delete the folders in order for GC to recreate the mp. As I am typing this I have another idea in mind, which might also work, but will have to see.

Will report back!  Thanks Paul

HE

 

Vrywaringsklousule / Disclaimer: http://www.nwu.ac.za/it/gov-man/disclaimer.html

>>> Paul Pettit <p.pettit@keele.ac.uk> 07/25/18 1:22 PM >>>

Hi Hans,

Yes, for me, following those steps the duration parameter is kept in the manifest.xml and the recording goes ahead with the correct duration.

As far as I can see, galicaster only uses the /recordings/calendars OC endpoint to get details of the upcoming recordings. this is the ical feed. I think the problem more likely comes in galicaster's logic for determining whether an event has been added/deleted/updated ad this code has change quite a bit recently, especially to take account of OC4+ separating the start/end/duration metadata from the actual start/end/duration which are now 2 separate things (for example the metadata could say "start at 10:00 and duration 1 hour" but the actual recording could be "start at 09:55 and record for 1:10"). I don't remember there being much of a change between OC2 and OC3 but it is a long time since I did that upgrade so I may be forgetting something!

As for the galicaster code, just from looking at it, the only difference between adding and updating an event is that if the event id exists in the repo it retrieves it and starts with that as the base, and if not it sets up a new blank Mediapackage object and uses that. all the rest (setting the start/duration etc) is done with exactly the same code as far as i can see.

So I am a bit lost as to what the difference could be without being able to replicate the problem :(

Sorry I've not been very helpful.

Paul.

On Wed, 25 Jul 2018 at 11:25, Hans Erasmus <Hans.E...@nwu.ac.za> wrote:

Hi Paul

Thank you so much. Those steps are exactly what I follow. What bothers me, is the XML on the OC side changes the metadata I want it to change, but it is as if GC2.1 does not "rebuild" the manifest.xml correctly. But what you are saying is, if you make the changes on OC3 and 5, the duration parameter is kept in manifest.xml, and not deleted like in mine? I am wondering if there might be an end-point difference between the 2 operations then? One endpoint on OC for creating the event, and another if the event is updated, and that GC actually uses 2 different end-points for the two separate scenarios?

Crap.

Thanks Paul

Cheers

HE

 

Vrywaringsklousule / Disclaimer: http://www.nwu.ac.za/it/gov-man/disclaimer.html

>>> Paul Pettit <p.pettit@keele.ac.uk> 07/25/18 12:18 PM >>>

hi Hans,

i've done some testing with OC3 and OC5 (the only 2 versions I have installations of) and can not replicate your issue either with GC 2.1 released version or the 2.1.x branch with the extra ical changes.

just to confirm, i tested by:

• creating a scheduled event
  
• waiting for galicaster to pick it up
  
• change various metadata
  
• wait for galicaster to pick up the changes
  
• check the duration is correct in the manifest.xml on galicaster
  
• check actual recording is the correct duration
  

this worked correctly (well almost, but that is another issue - it seems some metadata changes are not picked up by galicaster and so are overridden when the event is ingested back to OC) in all version combinations mentioned above.

i'm afraid that doesn't really help you very much :(

paul.

On Tue, 24 Jul 2018 at 18:08, Hans Erasmus <Hans.E...@nwu.ac.za> wrote:

Hi Paul

Thanks. Saw on github there was an issue raised https://github.com/teltek/Galicaster/issues/567. But from what I gather (and I am in no shape or form a coder myself, whatsoever, it seems that this bit of logic is implemented when creating a new mp, but NOT when one is updated. Hence the loss of the element "duration" in the regenerated manifest.xml. Was hoping someone on the list could see how the logic worked and advise on how difficult it would be to implement a fix/patch? Still wondering whether this behaviour will not present itself even on OC > 2/3/4. Seeing as GC recreates the manifest, with new parameters. So maybe the problem can be reproduced on newer OC installs as well. The important thing to note when trying to replicate this issue, is to check whether the initial ical has been received by the CA before updating the metadata on the OC admin server. As I stated, all is well if the ical has not been received yet, and therefore the MP has not been created yet. And looking at the code, even with my limited knowledge, it would seem to make sense regarding the differences in behaviour when editing the metadata before and after the ical has been received on the CA.

Just my 2c.  Was hoping not to have to revert back to GC2.0. 2.1 had fixes for other issues we had which is making my life more pleasurable atm. So will give it a day or so before deciding.

Regards

HE

Vrywaringsklousule / Disclaimer: http://www.nwu.ac.za/it/gov-man/disclaimer.html

>>> Paul Pettit <p.pettit@keele.ac.uk> 07/24/18 6:48 PM >>>

Hi Hans,

in that case if it does not work with the latest git version i would go back to 2.0 if you can. i think this error is most likely on the galicaster side and if you are only using OC2.3 then GC2.0 should work fine.

good luck!

paul.

On Tue, 24 Jul 2018 at 17:41, Hans Erasmus <Hans.E...@nwu.ac.za> wrote:

Hi Paul

No have not tried the latest git version. Will possibly have to and see where it leads. This is now in production, so I am screwed. We tested all other scenarios, like creating and deleting but never really in depth editing of the metadata before recording (it was always a non-issue). So it seems the list of tests just got a little longer. But this sucks atm. Will see if the ical code will make a difference, but seeing as we are on OC 2.3.0, not sure if the fixes will help us at all. Hopefully it does, but not holding my breath.

Regards

HE 

 

Vrywaringsklousule / Disclaimer: http://www.nwu.ac.za/it/gov-man/disclaimer.html

>>> Paul Pettit <p.pettit@keele.ac.uk> 07/24/18 5:12 PM >>>

>> Schröder:mailto:Prof.%20Dr.%20Lutz%20Schröder@matterhorn.opencast

>>>>>> email to community+unsubscribe@galicaster.org.

>>>>>> To post to this group, send email to comm...@galicaster.org.
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Dipl.- Inf. (FH) Stefanos Georgopoulos
>>>> Multimedia & E-Learning https://www.fau.tv
>>>> Friedrich-Alexander-Universität Erlangen-Nürnberg
>>>> Regionales RechenZentrum Erlangen (RRZE)
>>>> Martensstraße 1, 91058 Erlangen, Germany
>>>> Tel. +49 9131 85-20190, Fax +49 9131 302941
>>>> stefanos.g...@fau.de
>>>> www.rrze.fau.de
>>>>
>>>> Jubiläumsjahr 2018 - IT in Bewegung
>>>> Das RRZE - der IT-Dienstleister der FAU
>>>> www.50-jahre.rrze.fau.de
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>> Groups
>>>> "Galicaster-Community" group.
>>>> To unsubscribe from this group and stop receiving emails from it,
>> send an

>>>> email to community+unsubscribe@galicaster.org.

>>>> To post to this group, send email to comm...@galicaster.org.
>>>>
>>>
>>
>

--
Dipl.- Inf. (FH) Stefanos Georgopoulos
Multimedia & E-Learning https://www.fau.tv
Friedrich-Alexander-Universität Erlangen-Nürnberg
Regionales RechenZentrum Erlangen (RRZE)
Martensstraße 1, 91058 Erlangen, Germany
Tel. +49 9131 85-20190, Fax +49 9131 302941
stefanos.g...@fau.de
www.rrze.fau.de

Jubiläumsjahr 2018 - IT in Bewegung
Das RRZE - der IT-Dienstleister der FAU
www.50-jahre.rrze.fau.de

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+unsubscribe@galicaster.org.

To post to this group, send email to comm...@galicaster.org.

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+unsubscribe@galicaster.org.

To post to this group, send email to comm...@galicaster.org.

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+unsubscribe@galicaster.org.

To post to this group, send email to comm...@galicaster.org.

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+unsubscribe@galicaster.org.

To post to this group, send email to comm...@galicaster.org.

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+unsubscribe@galicaster.org.

To post to this group, send email to comm...@galicaster.org.

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+unsubscribe@galicaster.org.

To post to this group, send email to comm...@galicaster.org.

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+unsubscribe@galicaster.org.

To post to this group, send email to comm...@galicaster.org.

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+unsubscribe@galicaster.org.

To post to this group, send email to comm...@galicaster.org.

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+unsubscribe@galicaster.org.

To post to this group, send email to comm...@galicaster.org.

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+unsubscribe@galicaster.org.

[Hans Erasmus]

Hi Alfonso

Thanks for coming back to us on this. I have tested today again, and still seeing issues, using the steps you listed here as well.

But, I have written a small, very fugly shell script to help with my problem. Testing my last scenario (making sure the script does nothing when an Ingest process is running), but till now all other tests have passed. So if the last test works, I will deploy this workaround until we can upgrade our OC or until GC 2.1.1 is released, and somehow the gremlins magically take a hike :-)

Anyways, very small, very ugly and by no means foolproof, but sharing anyway, maybe it can give someone else an idea for any problem they might have.

https://github.com/hanserasmus/gc2-workaround

Regards

HE

 

Vrywaringsklousule / Disclaimer: http://www.nwu.ac.za/it/gov-man/disclaimer.html

>>> Alfonso Rodriguez <arodr...@teltek.es> 07/26/18 9:30 AM >>>

>>> Paul Pettit <p.pe...@keele.ac.uk> 07/25/18 1:22 PM >>>

Hi Hans,

Yes, for me, following those steps the duration parameter is kept in the manifest.xml and the recording goes ahead with the correct duration.

As far as I can see, galicaster only uses the /recordings/calendars OC endpoint to get details of the upcoming recordings. this is the ical feed. I think the problem more likely comes in galicaster's logic for determining whether an event has been added/deleted/updated ad this code has change quite a bit recently, especially to take account of OC4+ separating the start/end/duration metadata from the actual start/end/duration which are now 2 separate things (for example the metadata could say "start at 10:00 and duration 1 hour" but the actual recording could be "start at 09:55 and record for 1:10"). I don't remember there being much of a change between OC2 and OC3 but it is a long time since I did that upgrade so I may be forgetting something!

As for the galicaster code, just from looking at it, the only difference between adding and updating an event is that if the event id exists in the repo it retrieves it and starts with that as the base, and if not it sets up a new blank Mediapackage object and uses that. all the rest (setting the start/duration etc) is done with exactly the same code as far as i can see.

So I am a bit lost as to what the difference could be without being able to replicate the problem :(

Sorry I've not been very helpful.

Paul.

On Wed, 25 Jul 2018 at 11:25, Hans Erasmus <Hans.E...@nwu.ac.za> wrote:

Hi Paul

Thank you so much. Those steps are exactly what I follow. What bothers me, is the XML on the OC side changes the metadata I want it to change, but it is as if GC2.1 does not "rebuild" the manifest.xml correctly. But what you are saying is, if you make the changes on OC3 and 5, the duration parameter is kept in manifest.xml, and not deleted like in mine? I am wondering if there might be an end-point difference between the 2 operations then? One endpoint on OC for creating the event, and another if the event is updated, and that GC actually uses 2 different end-points for the two separate scenarios?

Crap.

Thanks Paul

Cheers

HE

 

Vrywaringsklousule / Disclaimer: http://www.nwu.ac.za/it/gov-man/disclaimer.html

>>> Paul Pettit <p.pe...@keele.ac.uk> 07/25/18 12:18 PM >>>

hi Hans,

i've done some testing with OC3 and OC5 (the only 2 versions I have installations of) and can not replicate your issue either with GC 2.1 released version or the 2.1.x branch with the extra ical changes.

just to confirm, i tested by:

• creating a scheduled event
  
• waiting for galicaster to pick it up
  
• change various metadata
  
• wait for galicaster to pick up the changes
  
• check the duration is correct in the manifest.xml on galicaster
  
• check actual recording is the correct duration
  

this worked correctly (well almost, but that is another issue - it seems some metadata changes are not picked up by galicaster and so are overridden when the event is ingested back to OC) in all version combinations mentioned above.

i'm afraid that doesn't really help you very much :(

paul.

On Tue, 24 Jul 2018 at 18:08, Hans Erasmus <Hans.E...@nwu.ac.za> wrote:

Hi Paul

Thanks. Saw on github there was an issue raised https://github.com/teltek/Galicaster/issues/567. But from what I gather (and I am in no shape or form a coder myself, whatsoever, it seems that this bit of logic is implemented when creating a new mp, but NOT when one is updated. Hence the loss of the element "duration" in the regenerated manifest.xml. Was hoping someone on the list could see how the logic worked and advise on how difficult it would be to implement a fix/patch? Still wondering whether this behaviour will not present itself even on OC > 2/3/4. Seeing as GC recreates the manifest, with new parameters. So maybe the problem can be reproduced on newer OC installs as well. The important thing to note when trying to replicate this issue, is to check whether the initial ical has been received by the CA before updating the metadata on the OC admin server. As I stated, all is well if the ical has not been received yet, and therefore the MP has not been created yet. And looking at the code, even with my limited knowledge, it would seem to make sense regarding the differences in behaviour when editing the metadata before and after the ical has been received on the CA.

Just my 2c.  Was hoping not to have to revert back to GC2.0. 2.1 had fixes for other issues we had which is making my life more pleasurable atm. So will give it a day or so before deciding.

Regards

HE

Vrywaringsklousule / Disclaimer: http://www.nwu.ac.za/it/gov-man/disclaimer.html

>>> Paul Pettit <p.pe...@keele.ac.uk> 07/24/18 6:48 PM >>>

Hi Hans,

in that case if it does not work with the latest git version i would go back to 2.0 if you can. i think this error is most likely on the galicaster side and if you are only using OC2.3 then GC2.0 should work fine.

good luck!

paul.

On Tue, 24 Jul 2018 at 17:41, Hans Erasmus <Hans.E...@nwu.ac.za> wrote:

Hi Paul

No have not tried the latest git version. Will possibly have to and see where it leads. This is now in production, so I am screwed. We tested all other scenarios, like creating and deleting but never really in depth editing of the metadata before recording (it was always a non-issue). So it seems the list of tests just got a little longer. But this sucks atm. Will see if the ical code will make a difference, but seeing as we are on OC 2.3.0, not sure if the fixes will help us at all. Hopefully it does, but not holding my breath.

Regards

HE 

 

Vrywaringsklousule / Disclaimer: http://www.nwu.ac.za/it/gov-man/disclaimer.html

>>> Paul Pettit <p.pe...@keele.ac.uk> 07/24/18 5:12 PM >>>

>> Schröder:mailto:Prof.%20Dr.%20Lutz%20Schröd...@matterhorn.opencast

>>>>>> email to community+...@galicaster.org.

>>>>>> To post to this group, send email to comm...@galicaster.org.
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Dipl.- Inf. (FH) Stefanos Georgopoulos
>>>> Multimedia & E-Learning https://www.fau.tv
>>>> Friedrich-Alexander-Universität Erlangen-Nürnberg
>>>> Regionales RechenZentrum Erlangen (RRZE)
>>>> Martensstraße 1, 91058 Erlangen, Germany
>>>> Tel. +49 9131 85-20190, Fax +49 9131 302941
>>>> stefanos.g...@fau.de
>>>> www.rrze.fau.de
>>>>
>>>> Jubiläumsjahr 2018 - IT in Bewegung
>>>> Das RRZE - der IT-Dienstleister der FAU
>>>> www.50-jahre.rrze.fau.de
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>> Groups
>>>> "Galicaster-Community" group.
>>>> To unsubscribe from this group and stop receiving emails from it,
>> send an

>>>> email to community+...@galicaster.org.

>>>> To post to this group, send email to comm...@galicaster.org.
>>>>
>>>
>>
>

--
Dipl.- Inf. (FH) Stefanos Georgopoulos
Multimedia & E-Learning https://www.fau.tv
Friedrich-Alexander-Universität Erlangen-Nürnberg
Regionales RechenZentrum Erlangen (RRZE)
Martensstraße 1, 91058 Erlangen, Germany
Tel. +49 9131 85-20190, Fax +49 9131 302941
stefanos.g...@fau.de
www.rrze.fau.de

Jubiläumsjahr 2018 - IT in Bewegung
Das RRZE - der IT-Dienstleister der FAU
www.50-jahre.rrze.fau.de

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+...@galicaster.org.

To post to this group, send email to comm...@galicaster.org.

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+...@galicaster.org.

To post to this group, send email to comm...@galicaster.org.

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+...@galicaster.org.

To post to this group, send email to comm...@galicaster.org.

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+...@galicaster.org.

To post to this group, send email to comm...@galicaster.org.

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+...@galicaster.org.

To post to this group, send email to comm...@galicaster.org.

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+...@galicaster.org.

To post to this group, send email to comm...@galicaster.org.

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+...@galicaster.org.

To post to this group, send email to comm...@galicaster.org.

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+...@galicaster.org.

To post to this group, send email to comm...@galicaster.org.

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+...@galicaster.org.

To post to this group, send email to comm...@galicaster.org.

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+...@galicaster.org.

To post to this group, send email to comm...@galicaster.org.

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+...@galicaster.org.

[Alfonso Rodriguez]

Hi Hans,

Have you tried testing by cloning the repository? Can you try to reproduce the issue with the 2.1.x and 2.0.x branches? If you can confirm that this started happening after the 2.1 release we can pinpoint which change may be causing this.

Best Regards,

Alfonso Rodríguez Pereira
TELTEK Video Research
http://teltek.es/


La información contenida en este mensaje y/o archivo(s) adjunto(s) es confidencial/privilegiada y está destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Si usted lee este mensaje y no es el destinatario señalado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicación por error, le informamos que está totalmente prohibida, y puede ser ilegal, cualquier divulgación, distribución o reproducción de esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la dirección arriba mencionada. Gracias.

The information contained in this message and/or attached file(s) is confidential/privileged and is intended to be read only by the person(s) to whom it is directed. If you are reading this message and you are not the indicated recipient, or the employee or agent responsible for delivering the message to the addressee, or you have received this communication by mistake, please be aware that any dissemination, distribution or reproduction of this communication is strictly prohibited and may be illegal. Please notify us immediately and return the original message to the aforementioned address. Thank you.

On 26 July 2018 at 15:01, Hans Erasmus <Hans.E...@nwu.ac.za> wrote:

Hi Alfonso

Thanks for coming back to us on this. I have tested today again, and still seeing issues, using the steps you listed here as well.

But, I have written a small, very fugly shell script to help with my problem. Testing my last scenario (making sure the script does nothing when an Ingest process is running), but till now all other tests have passed. So if the last test works, I will deploy this workaround until we can upgrade our OC or until GC 2.1.1 is released, and somehow the gremlins magically take a hike :-)

Anyways, very small, very ugly and by no means foolproof, but sharing anyway, maybe it can give someone else an idea for any problem they might have.

https://github.com/hanserasmus/gc2-workaround

Regards

HE

 

Vrywaringsklousule / Disclaimer: http://www.nwu.ac.za/it/gov-man/disclaimer.html

>>> Alfonso Rodriguez <arodriguez@teltek.es> 07/26/18 9:30 AM >>>

>>> Paul Pettit <p.pettit@keele.ac.uk> 07/25/18 1:22 PM >>>

Hi Hans,

Yes, for me, following those steps the duration parameter is kept in the manifest.xml and the recording goes ahead with the correct duration.

As far as I can see, galicaster only uses the /recordings/calendars OC endpoint to get details of the upcoming recordings. this is the ical feed. I think the problem more likely comes in galicaster's logic for determining whether an event has been added/deleted/updated ad this code has change quite a bit recently, especially to take account of OC4+ separating the start/end/duration metadata from the actual start/end/duration which are now 2 separate things (for example the metadata could say "start at 10:00 and duration 1 hour" but the actual recording could be "start at 09:55 and record for 1:10"). I don't remember there being much of a change between OC2 and OC3 but it is a long time since I did that upgrade so I may be forgetting something!

As for the galicaster code, just from looking at it, the only difference between adding and updating an event is that if the event id exists in the repo it retrieves it and starts with that as the base, and if not it sets up a new blank Mediapackage object and uses that. all the rest (setting the start/duration etc) is done with exactly the same code as far as i can see.

So I am a bit lost as to what the difference could be without being able to replicate the problem :(

Sorry I've not been very helpful.

Paul.

On Wed, 25 Jul 2018 at 11:25, Hans Erasmus <Hans.E...@nwu.ac.za> wrote:

Hi Paul

Thank you so much. Those steps are exactly what I follow. What bothers me, is the XML on the OC side changes the metadata I want it to change, but it is as if GC2.1 does not "rebuild" the manifest.xml correctly. But what you are saying is, if you make the changes on OC3 and 5, the duration parameter is kept in manifest.xml, and not deleted like in mine? I am wondering if there might be an end-point difference between the 2 operations then? One endpoint on OC for creating the event, and another if the event is updated, and that GC actually uses 2 different end-points for the two separate scenarios?

Crap.

Thanks Paul

Cheers

HE

 

Vrywaringsklousule / Disclaimer: http://www.nwu.ac.za/it/gov-man/disclaimer.html

>>> Paul Pettit <p.pettit@keele.ac.uk> 07/25/18 12:18 PM >>>

hi Hans,

i've done some testing with OC3 and OC5 (the only 2 versions I have installations of) and can not replicate your issue either with GC 2.1 released version or the 2.1.x branch with the extra ical changes.

just to confirm, i tested by:

• creating a scheduled event
  
• waiting for galicaster to pick it up
  
• change various metadata
  
• wait for galicaster to pick up the changes
  
• check the duration is correct in the manifest.xml on galicaster
  
• check actual recording is the correct duration
  

this worked correctly (well almost, but that is another issue - it seems some metadata changes are not picked up by galicaster and so are overridden when the event is ingested back to OC) in all version combinations mentioned above.

i'm afraid that doesn't really help you very much :(

paul.

On Tue, 24 Jul 2018 at 18:08, Hans Erasmus <Hans.E...@nwu.ac.za> wrote:

Hi Paul

Thanks. Saw on github there was an issue raised https://github.com/teltek/Galicaster/issues/567. But from what I gather (and I am in no shape or form a coder myself, whatsoever, it seems that this bit of logic is implemented when creating a new mp, but NOT when one is updated. Hence the loss of the element "duration" in the regenerated manifest.xml. Was hoping someone on the list could see how the logic worked and advise on how difficult it would be to implement a fix/patch? Still wondering whether this behaviour will not present itself even on OC > 2/3/4. Seeing as GC recreates the manifest, with new parameters. So maybe the problem can be reproduced on newer OC installs as well. The important thing to note when trying to replicate this issue, is to check whether the initial ical has been received by the CA before updating the metadata on the OC admin server. As I stated, all is well if the ical has not been received yet, and therefore the MP has not been created yet. And looking at the code, even with my limited knowledge, it would seem to make sense regarding the differences in behaviour when editing the metadata before and after the ical has been received on the CA.

Just my 2c.  Was hoping not to have to revert back to GC2.0. 2.1 had fixes for other issues we had which is making my life more pleasurable atm. So will give it a day or so before deciding.

Regards

HE

Vrywaringsklousule / Disclaimer: http://www.nwu.ac.za/it/gov-man/disclaimer.html

>>> Paul Pettit <p.pettit@keele.ac.uk> 07/24/18 6:48 PM >>>

Hi Hans,

in that case if it does not work with the latest git version i would go back to 2.0 if you can. i think this error is most likely on the galicaster side and if you are only using OC2.3 then GC2.0 should work fine.

good luck!

paul.

On Tue, 24 Jul 2018 at 17:41, Hans Erasmus <Hans.E...@nwu.ac.za> wrote:

Hi Paul

No have not tried the latest git version. Will possibly have to and see where it leads. This is now in production, so I am screwed. We tested all other scenarios, like creating and deleting but never really in depth editing of the metadata before recording (it was always a non-issue). So it seems the list of tests just got a little longer. But this sucks atm. Will see if the ical code will make a difference, but seeing as we are on OC 2.3.0, not sure if the fixes will help us at all. Hopefully it does, but not holding my breath.

Regards

HE 

 

Vrywaringsklousule / Disclaimer: http://www.nwu.ac.za/it/gov-man/disclaimer.html

>>> Paul Pettit <p.pettit@keele.ac.uk> 07/24/18 5:12 PM >>>

>> Schröder:mailto:Prof.%20Dr.%20Lutz%20Schröder@matterhorn.opencast

>>>>>> email to community+unsubscribe@galicaster.org.

>>>>>> To post to this group, send email to comm...@galicaster.org.
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Dipl.- Inf. (FH) Stefanos Georgopoulos
>>>> Multimedia & E-Learning https://www.fau.tv
>>>> Friedrich-Alexander-Universität Erlangen-Nürnberg
>>>> Regionales RechenZentrum Erlangen (RRZE)
>>>> Martensstraße 1, 91058 Erlangen, Germany
>>>> Tel. +49 9131 85-20190, Fax +49 9131 302941
>>>> stefanos.g...@fau.de
>>>> www.rrze.fau.de
>>>>
>>>> Jubiläumsjahr 2018 - IT in Bewegung
>>>> Das RRZE - der IT-Dienstleister der FAU
>>>> www.50-jahre.rrze.fau.de
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>> Groups
>>>> "Galicaster-Community" group.
>>>> To unsubscribe from this group and stop receiving emails from it,
>> send an

>>>> email to community+unsubscribe@galicaster.org.

>>>> To post to this group, send email to comm...@galicaster.org.
>>>>
>>>
>>
>

--
Dipl.- Inf. (FH) Stefanos Georgopoulos
Multimedia & E-Learning https://www.fau.tv
Friedrich-Alexander-Universität Erlangen-Nürnberg
Regionales RechenZentrum Erlangen (RRZE)
Martensstraße 1, 91058 Erlangen, Germany
Tel. +49 9131 85-20190, Fax +49 9131 302941
stefanos.g...@fau.de
www.rrze.fau.de

Jubiläumsjahr 2018 - IT in Bewegung
Das RRZE - der IT-Dienstleister der FAU
www.50-jahre.rrze.fau.de

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+unsubscribe@galicaster.org.

To post to this group, send email to comm...@galicaster.org.

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+unsubscribe@galicaster.org.

To post to this group, send email to comm...@galicaster.org.

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+unsubscribe@galicaster.org.

To post to this group, send email to comm...@galicaster.org.

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+unsubscribe@galicaster.org.

To post to this group, send email to comm...@galicaster.org.

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+unsubscribe@galicaster.org.

To post to this group, send email to comm...@galicaster.org.

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+unsubscribe@galicaster.org.

To post to this group, send email to comm...@galicaster.org.

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+unsubscribe@galicaster.org.

To post to this group, send email to comm...@galicaster.org.

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+unsubscribe@galicaster.org.

To post to this group, send email to comm...@galicaster.org.

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+unsubscribe@galicaster.org.

To post to this group, send email to comm...@galicaster.org.

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+unsubscribe@galicaster.org.

To post to this group, send email to comm...@galicaster.org.

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+unsubscribe@galicaster.org.

To post to this group, send email to comm...@galicaster.org.

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+unsubscribe@galicaster.org.

[Hans Erasmus]

Hi Alfonso

Will clone that first thing tomorrow morning and see. I needed to get the workaround going first in order to deploy to all our production machines and ensure we do not lose any videos. I will deploy both 2.0 and 2.1.x and test on both from our OC. Maybe something in our OC code is crooked.

Regards

HE

 

Vrywaringsklousule / Disclaimer: http://www.nwu.ac.za/it/gov-man/disclaimer.html

>>> Alfonso Rodriguez <arodr...@teltek.es> 07/26/18 3:37 PM >>>

Hi Hans,

Have you tried testing by cloning the repository? Can you try to reproduce the issue with the 2.1.x and 2.0.x branches? If you can confirm that this started happening after the 2.1 release we can pinpoint which change may be causing this.

Best Regards,

Alfonso Rodríguez Pereira
TELTEK Video Research
http://teltek.es/


La información contenida en este mensaje y/o archivo(s) adjunto(s) es confidencial/privilegiada y está destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Si usted lee este mensaje y no es el destinatario señalado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicación por error, le informamos que está totalmente prohibida, y puede ser ilegal, cualquier divulgación, distribución o reproducción de esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la dirección arriba mencionada. Gracias.

The information contained in this message and/or attached file(s) is confidential/privileged and is intended to be read only by the person(s) to whom it is directed. If you are reading this message and you are not the indicated recipient, or the employee or agent responsible for delivering the message to the addressee, or you have received this communication by mistake, please be aware that any dissemination, distribution or reproduction of this communication is strictly prohibited and may be illegal. Please notify us immediately and return the original message to the aforementioned address. Thank you.

On 26 July 2018 at 15:01, Hans Erasmus <Hans.E...@nwu.ac.za> wrote:

Hi Alfonso

Thanks for coming back to us on this. I have tested today again, and still seeing issues, using the steps you listed here as well.

But, I have written a small, very fugly shell script to help with my problem. Testing my last scenario (making sure the script does nothing when an Ingest process is running), but till now all other tests have passed. So if the last test works, I will deploy this workaround until we can upgrade our OC or until GC 2.1.1 is released, and somehow the gremlins magically take a hike :-)

Anyways, very small, very ugly and by no means foolproof, but sharing anyway, maybe it can give someone else an idea for any problem they might have.

https://github.com/hanserasmus/gc2-workaround

Regards

HE

 

Vrywaringsklousule / Disclaimer: http://www.nwu.ac.za/it/gov-man/disclaimer.html

>>> Alfonso Rodriguez <arodr...@teltek.es> 07/26/18 9:30 AM >>>

>>> Paul Pettit <p.pe...@keele.ac.uk> 07/25/18 1:22 PM >>>

Hi Hans,

Yes, for me, following those steps the duration parameter is kept in the manifest.xml and the recording goes ahead with the correct duration.

As far as I can see, galicaster only uses the /recordings/calendars OC endpoint to get details of the upcoming recordings. this is the ical feed. I think the problem more likely comes in galicaster's logic for determining whether an event has been added/deleted/updated ad this code has change quite a bit recently, especially to take account of OC4+ separating the start/end/duration metadata from the actual start/end/duration which are now 2 separate things (for example the metadata could say "start at 10:00 and duration 1 hour" but the actual recording could be "start at 09:55 and record for 1:10"). I don't remember there being much of a change between OC2 and OC3 but it is a long time since I did that upgrade so I may be forgetting something!

As for the galicaster code, just from looking at it, the only difference between adding and updating an event is that if the event id exists in the repo it retrieves it and starts with that as the base, and if not it sets up a new blank Mediapackage object and uses that. all the rest (setting the start/duration etc) is done with exactly the same code as far as i can see.

So I am a bit lost as to what the difference could be without being able to replicate the problem :(

Sorry I've not been very helpful.

Paul.

On Wed, 25 Jul 2018 at 11:25, Hans Erasmus <Hans.E...@nwu.ac.za> wrote:

Hi Paul

Thank you so much. Those steps are exactly what I follow. What bothers me, is the XML on the OC side changes the metadata I want it to change, but it is as if GC2.1 does not "rebuild" the manifest.xml correctly. But what you are saying is, if you make the changes on OC3 and 5, the duration parameter is kept in manifest.xml, and not deleted like in mine? I am wondering if there might be an end-point difference between the 2 operations then? One endpoint on OC for creating the event, and another if the event is updated, and that GC actually uses 2 different end-points for the two separate scenarios?

Crap.

Thanks Paul

Cheers

HE

 

Vrywaringsklousule / Disclaimer: http://www.nwu.ac.za/it/gov-man/disclaimer.html

>>> Paul Pettit <p.pe...@keele.ac.uk> 07/25/18 12:18 PM >>>

hi Hans,

i've done some testing with OC3 and OC5 (the only 2 versions I have installations of) and can not replicate your issue either with GC 2.1 released version or the 2.1.x branch with the extra ical changes.

just to confirm, i tested by:

• creating a scheduled event
  
• waiting for galicaster to pick it up
  
• change various metadata
  
• wait for galicaster to pick up the changes
  
• check the duration is correct in the manifest.xml on galicaster
  
• check actual recording is the correct duration
  

this worked correctly (well almost, but that is another issue - it seems some metadata changes are not picked up by galicaster and so are overridden when the event is ingested back to OC) in all version combinations mentioned above.

i'm afraid that doesn't really help you very much :(

paul.

On Tue, 24 Jul 2018 at 18:08, Hans Erasmus <Hans.E...@nwu.ac.za> wrote:

Hi Paul

Thanks. Saw on github there was an issue raised https://github.com/teltek/Galicaster/issues/567. But from what I gather (and I am in no shape or form a coder myself, whatsoever, it seems that this bit of logic is implemented when creating a new mp, but NOT when one is updated. Hence the loss of the element "duration" in the regenerated manifest.xml. Was hoping someone on the list could see how the logic worked and advise on how difficult it would be to implement a fix/patch? Still wondering whether this behaviour will not present itself even on OC > 2/3/4. Seeing as GC recreates the manifest, with new parameters. So maybe the problem can be reproduced on newer OC installs as well. The important thing to note when trying to replicate this issue, is to check whether the initial ical has been received by the CA before updating the metadata on the OC admin server. As I stated, all is well if the ical has not been received yet, and therefore the MP has not been created yet. And looking at the code, even with my limited knowledge, it would seem to make sense regarding the differences in behaviour when editing the metadata before and after the ical has been received on the CA.

Just my 2c.  Was hoping not to have to revert back to GC2.0. 2.1 had fixes for other issues we had which is making my life more pleasurable atm. So will give it a day or so before deciding.

Regards

HE

Vrywaringsklousule / Disclaimer: http://www.nwu.ac.za/it/gov-man/disclaimer.html

>>> Paul Pettit <p.pe...@keele.ac.uk> 07/24/18 6:48 PM >>>

Hi Hans,

in that case if it does not work with the latest git version i would go back to 2.0 if you can. i think this error is most likely on the galicaster side and if you are only using OC2.3 then GC2.0 should work fine.

good luck!

paul.

On Tue, 24 Jul 2018 at 17:41, Hans Erasmus <Hans.E...@nwu.ac.za> wrote:

Hi Paul

No have not tried the latest git version. Will possibly have to and see where it leads. This is now in production, so I am screwed. We tested all other scenarios, like creating and deleting but never really in depth editing of the metadata before recording (it was always a non-issue). So it seems the list of tests just got a little longer. But this sucks atm. Will see if the ical code will make a difference, but seeing as we are on OC 2.3.0, not sure if the fixes will help us at all. Hopefully it does, but not holding my breath.

Regards

HE 

 

Vrywaringsklousule / Disclaimer: http://www.nwu.ac.za/it/gov-man/disclaimer.html

>>> Paul Pettit <p.pe...@keele.ac.uk> 07/24/18 5:12 PM >>>

>> Schröder:mailto:Prof.%20Dr.%20Lutz%20Schröd...@matterhorn.opencast

>>>>>> email to community+...@galicaster.org.

>>>>>> To post to this group, send email to comm...@galicaster.org.
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Dipl.- Inf. (FH) Stefanos Georgopoulos
>>>> Multimedia & E-Learning https://www.fau.tv
>>>> Friedrich-Alexander-Universität Erlangen-Nürnberg
>>>> Regionales RechenZentrum Erlangen (RRZE)
>>>> Martensstraße 1, 91058 Erlangen, Germany
>>>> Tel. +49 9131 85-20190, Fax +49 9131 302941
>>>> stefanos.g...@fau.de
>>>> www.rrze.fau.de
>>>>
>>>> Jubiläumsjahr 2018 - IT in Bewegung
>>>> Das RRZE - der IT-Dienstleister der FAU
>>>> www.50-jahre.rrze.fau.de
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>> Groups
>>>> "Galicaster-Community" group.
>>>> To unsubscribe from this group and stop receiving emails from it,
>> send an

>>>> email to community+...@galicaster.org.

>>>> To post to this group, send email to comm...@galicaster.org.
>>>>
>>>
>>
>

--
Dipl.- Inf. (FH) Stefanos Georgopoulos
Multimedia & E-Learning https://www.fau.tv
Friedrich-Alexander-Universität Erlangen-Nürnberg
Regionales RechenZentrum Erlangen (RRZE)
Martensstraße 1, 91058 Erlangen, Germany
Tel. +49 9131 85-20190, Fax +49 9131 302941
stefanos.g...@fau.de
www.rrze.fau.de

Jubiläumsjahr 2018 - IT in Bewegung
Das RRZE - der IT-Dienstleister der FAU
www.50-jahre.rrze.fau.de

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+...@galicaster.org.

To post to this group, send email to comm...@galicaster.org.

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+...@galicaster.org.

To post to this group, send email to comm...@galicaster.org.

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+...@galicaster.org.

To post to this group, send email to comm...@galicaster.org.

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+...@galicaster.org.

To post to this group, send email to comm...@galicaster.org.

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+...@galicaster.org.

To post to this group, send email to comm...@galicaster.org.

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+...@galicaster.org.

To post to this group, send email to comm...@galicaster.org.

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+...@galicaster.org.

To post to this group, send email to comm...@galicaster.org.

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+...@galicaster.org.

To post to this group, send email to comm...@galicaster.org.

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+...@galicaster.org.

To post to this group, send email to comm...@galicaster.org.

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+...@galicaster.org.

To post to this group, send email to comm...@galicaster.org.

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+...@galicaster.org.

To post to this group, send email to comm...@galicaster.org.

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+...@galicaster.org.

To post to this group, send email to comm...@galicaster.org.

--
You received this message because you are subscribed to the Google Groups "Galicaster-Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to community+...@galicaster.org.

[Stefanos Georgopoulos]

Hi Alfonso,

I am not sure if this is useful but in our case problem occurred last
semester using OC 3.5 and GC 2.1.

In winter semester 2017-2018 we had the same major realase from OC 3, I
think 3.3, and GC 2.0 without any problem at all (and I changed a lot
events after schedule).

Best regards,

Stefanos

On 07/26/2018 03:36 PM, Alfonso Rodriguez wrote:
> Hi Hans,
>
> Have you tried testing by cloning the repository? Can you try to reproduce
> the issue with the 2.1.x and 2.0.x branches? If you can confirm that this
> started happening after the 2.1 release we can pinpoint which change may be
> causing this.
>
> Best Regards,
>
>
>

> *Alfonso Rodríguez PereiraTELTEK Video Research*
> http://teltek.es/

[Alfonso Rodriguez]

Hi Stefanos,

Could you test GC 2.0 with the same Opencast 3.5 you are seeing the issue with right now?

Also, could you guys add the full ical file that galicaster reads before and after editing an event? (attach/calendar.ical)

Best Regards,

Alfonso Rodríguez Pereira
TELTEK Video Research
http://teltek.es/


La información contenida en este mensaje y/o archivo(s) adjunto(s) es confidencial/privilegiada y está destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Si usted lee este mensaje y no es el destinatario señalado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicación por error, le informamos que está totalmente prohibida, y puede ser ilegal, cualquier divulgación, distribución o reproducción de esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje original a la dirección arriba mencionada. Gracias.

The information contained in this message and/or attached file(s) is confidential/privileged and is intended to be read only by the person(s) to whom it is directed. If you are reading this message and you are not the indicated recipient, or the employee or agent responsible for delivering the message to the addressee, or you have received this communication by mistake, please be aware that any dissemination, distribution or reproduction of this communication is strictly prohibited and may be illegal. Please notify us immediately and return the original message to the aforementioned address. Thank you.

[Stefanos Georgopoulos]

Hi Alfonso

On 07/26/2018 04:08 PM, Alfonso Rodriguez wrote:
> Hi Stefanos,
>
> Could you test GC 2.0 with the same Opencast 3.5 you are seeing the issue
> with right now?

I will try it tomorrow. As I wrote to my initial posts to this thread
this "bug" ( I am still not sure if this is a galicaster bug or a CA
setup problem) bothered me a lot because it was very difficult to
reproduce. There wasn't any certain pattern or process that I could
follow to reproduce it.

I will try to explain how our problem started.

I programmed all lectures one week before semester started.

Because here in Bavaria we have in May many holidays I had to delete all
events for 4 days (01.05, 10.05, 21.05, 31.04). Days were one Monday,
and one Tuesday and 2 Thursdays IIRC. Then for these particular events I
changed the asceding number ( because I deleted some events) in the
title so for test01, test02 DELETED I changed test 03 to test 02.

Then problems started for this particular events. I had a situation with
a Gali with this Bug only occured on the series with deleted/changed
meta, while at the same time the same CA started normally for a series
occurred on Wednesday.

When I realised it I tried, always at the same CA, to do some test but
all of them just passed. I know this sounds crazy but I tried

Scheduling single events
Scheduling multiple events

and trying deleting events, renaming, change duration, scheduling short
or long events. In all cases galicaster started normally !!!

Just before going crazy, I deleted the attach/calendar and all
repository folders (!!) and re-schedule all 250 events without changing
anything in Opencast.

I will try to do the same again tomorrow and see what happens.

Thanks
Stefanos

>
> Also, could you guys add the full ical file that galicaster reads before
> and after editing an event? (attach/calendar.ical)
>
> Best Regards,
>
>
>

> *Alfonso Rodríguez PereiraTELTEK Video Research*
> http://teltek.es/
>
>
>
>

> *La información contenida en este mensaje y/o archivo(s) adjunto(s) es

> confidencial/privilegiada y está destinada a ser leída sólo por la(s)
> persona(s) a la(s) que va dirigida. Si usted lee este mensaje y no es el
> destinatario señalado, el empleado o el agente responsable de entregar el
> mensaje al destinatario, o ha recibido esta comunicación por error, le
> informamos que está totalmente prohibida, y puede ser ilegal, cualquier
> divulgación, distribución o reproducción de esta comunicación, y le
> rogamos que nos lo notifique inmediatamente y nos devuelva el mensaje

> original a la dirección arriba mencionada. Gracias.The **information

> contained in this message and/or attached file(s) is
> confidential/privileged and is intended to be read only by the person(s) to
> whom it is directed. If you are reading this message and you are not the
> indicated recipient, or the employee or agent responsible for delivering
> the message to the addressee, or you have received this communication by

> mistake, please be aware that **any dissemination, distribution or

> reproduction of this communication is strictly prohibited and may be
> illegal. Please notify us immediately and return the original message to

> the aforementioned address. Thank you.*

>> email to community+...@galicaster.org.

>> To post to this group, send email to comm...@galicaster.org.
>>
>

[Stefanos Georgopoulos]

Hi to all,

stranger things season 3. Now my GC not starting at all.

What I did:

schedule multiple events for 1min till Tuesday rename the first one ,
delete third and rename the fourth.

Recording one didn't started at all

galicaster 2018-07-27 09:27:59,523 INFO scheduler/scheduler
Start time for recording 2574216570677108736, duration None ms
galicaster 2018-07-27 09:28:07,523 INFO opencast/service

Set status idle to server

galicaster 2018-07-27 09:28:07,523 INFO opencast/client Sending
state idle

at in Opencast showed as scheduled (Picture 1secBug.png).

schedule multiple events for 1min tillTuesday after 5 min without
changing anything.

Recording started successfully and OC started to process it (Picture
1secBug.png).

I attached all icals.

@ Alfonso how can I downgrade? Should I build from source or is it
possible to do it through apt ?

Regards
Stefanos

On 07/26/2018 04:40 PM, Stefanos Georgopoulos wrote:
> initial posts to this thread
> this "bug" ( I am still not sure if this is a galicaster bug or a CA
> setup problem) bothered me a lot because it was very difficult to
> reproduce. There wasn't any certain pattern or process that I could
> follow to reproduce it.

[Hans Erasmus]

Hi All

So a vanilla install (Docker all-in-one) instance of Opencast 5.0, connecting to the same CA I have been using all this time shows the problem is: drumroll please......... with our OC install. Scheduling then editing 3 times, and the video is still recording. So it seems the problem is not with GC, so sorry for wasting everybody's time on this.

Thanks for all the help @Paul and @Alfonso! And sorry again!

Regards

HE

 

Vrywaringsklousule / Disclaimer: http://www.nwu.ac.za/it/gov-man/disclaimer.html

>>> Stefanos Georgopoulos <stefanos.g...@fau.de> 07/27/18 9:43 AM >>>

[Stefanos Georgopoulos]

Hi Hans,

I am a little bit confused. If this had to do with the Opencast version
then is this a general or an Opencast user setup problem ?

Is this bug by other Users re-producable (using OC 2.x or 3.x)?

Does this mean that upgrading to OC 4.x or 5.x will solve this ?

Sorry for the questions but I still try to understand in which side
this problem occurs. Because changing metadata in our OC 3.5 series with
NCast CA everything is working as expected.

Regards
Stefanos

[Paul Pettit]

Hi,

Sorry I was off for a few days - glad you got it sorted Hans!

Stefanos: I can not reproduce the problem with my production OC 3 so I guess it is not specific to the OC version but maybe config related? I don't know if Hans tracked down what the actual issue was or just that it was not in GC.

Thanks,

Paul.

[Stefanos Georgopoulos]

Hi Paul,

thanks for the feedback.

Just for the record, I tried today with our OC 5.x dev vm and it is
working without any problem (schedule-> pick by GC -> change meta in OC).

I am still very interested for this behaviour, so if anyone has a clue
is very welcome!! I am going to stick at the moment (and maybe for the
upcomming winter semester) with OC 3.x and GC 2.1 with this "bug" so,
until no one comes up with a solution, I would rather prefer not change
the metadata at all!

-Stefanos