Galicaster 2.1 records only 1 sec

40 views
Skip to first unread message

Stefanos Georgopoulos

unread,
Apr 12, 2018, 6:24:54 AM4/12/18
to comm...@galicaster.org
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

signature.asc

Andrew Wilson

unread,
Apr 12, 2018, 6:57:15 AM4/12/18
to comm...@galicaster.org
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

unread,
Apr 12, 2018, 7:06:12 AM4/12/18
to comm...@galicaster.org, Andrew Wilson
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
signature.asc

Paul Pettit

unread,
Apr 12, 2018, 7:33:02 AM4/12/18
to comm...@galicaster.org
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.


>> 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

unread,
Apr 12, 2018, 7:55:31 AM4/12/18
to comm...@galicaster.org, Paul Pettit
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.
signature.asc

Hans Erasmus

unread,
Jul 24, 2018, 5:34:21 AM7/24/18
to comm...@galicaster.org
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

unread,
Jul 24, 2018, 5:39:12 AM7/24/18
to comm...@galicaster.org
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

unread,
Jul 24, 2018, 5:44:30 AM7/24/18
to comm...@galicaster.org, Hans Erasmus
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
signature.asc

Hans Erasmus

unread,
Jul 24, 2018, 5:48:20 AM7/24/18
to comm...@galicaster.org
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

unread,
Jul 24, 2018, 9:11:17 AM7/24/18
to comm...@galicaster.org
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

unread,
Jul 24, 2018, 9:36:32 AM7/24/18
to comm...@galicaster.org, Hans Erasmus
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
signature.asc

Hans Erasmus

unread,
Jul 24, 2018, 9:49:12 AM7/24/18
to comm...@galicaster.org
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

unread,
Jul 24, 2018, 11:12:38 AM7/24/18
to comm...@galicaster.org
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

unread,
Jul 24, 2018, 11:31:03 AM7/24/18
to comm...@galicaster.org, 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

unread,
Jul 24, 2018, 11:35:04 AM7/24/18
to comm...@galicaster.org
hi Ruth,

which patch are you referring to?

Thanks,

Paul.

Hans Erasmus

unread,
Jul 24, 2018, 12:41:54 PM7/24/18
to comm...@galicaster.org
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

unread,
Jul 24, 2018, 12:48:44 PM7/24/18
to comm...@galicaster.org
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

unread,
Jul 24, 2018, 1:08:05 PM7/24/18
to comm...@galicaster.org
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

unread,
Jul 25, 2018, 4:25:07 AM7/25/18
to Galicaster-Community
Hi Paul,

and added the patch for routine ical.py.

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

Ruth

Paul Pettit

unread,
Jul 25, 2018, 4:36:31 AM7/25/18
to comm...@galicaster.org
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

unread,
Jul 25, 2018, 6:16:50 AM7/25/18
to Galicaster-Community
Hi Paul,

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

Best
Ruth

Paul Pettit

unread,
Jul 25, 2018, 6:17:56 AM7/25/18
to comm...@galicaster.org
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

unread,
Jul 25, 2018, 6:25:52 AM7/25/18
to comm...@galicaster.org
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

unread,
Jul 25, 2018, 7:22:24 AM7/25/18
to comm...@galicaster.org
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

unread,
Jul 25, 2018, 8:02:53 AM7/25/18
to comm...@galicaster.org
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

unread,
Jul 26, 2018, 3:30:35 AM7/26/18
to comm...@galicaster.org
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

>>>>>> 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

>>>> 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

unread,
Jul 26, 2018, 9:01:30 AM7/26/18
to comm...@galicaster.org
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.


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

>>>>>> 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

>>>> 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

unread,
Jul 26, 2018, 9:36:58 AM7/26/18
to comm...@galicaster.org
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.


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

>>>>>> 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

>>>> 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

unread,
Jul 26, 2018, 9:42:14 AM7/26/18
to comm...@galicaster.org
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.


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

>>>>>> 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

>>>> 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.