Differences

This shows you the differences between two versions of the page.

--- c3tracker:setup [2024/08/28 18:43] – kunsi
+++ c3tracker:setup [2024/11/04 13:34] (current) – try to fix formatting jtbx
@@ Line 6: / Line 6: @@
   * Adjust project properties, recommendations: (full reference at the bottom of the page)
   * Compare project properties with previous instalment of the same event
 ==== optimal properties from current project ====
@@ Line 21: / Line 22: @@
   Processing.Path.Outro           /video/intros/camp2023/outro.ts
-  Publishing.Path                 /video/encoded/camp2023/
   Publishing.Upload.SkipSlaves    speedy,tweety,blade1,blade2,blade3,blade4
-  Publishing.UploadTarget         upload@releasing.c3voc.de:/video/encoded/camp2023/
+  Publishing.UploadTarget         releasing.c3voc.de:/video/encoded/camp2023/
   Publishing.Tags                 <additional tags>
   Publishing.Voctoweb.Enable      yes
@@ Line 50: / Line 50: @@
-Please note that the conditions in the "project to worker group" filter are currently evaluated with logical OR.
+Please note that the conditions in the "project to worker group" filter are currently always evaluated with logical OR.
-Specifying a property with an empty value, which is often done for EncodingProfile.IsMaster, will match if this property does not exist at all on a ticket. So for EncodingProfile.IsMaster, specifying an empty filter will match on recording tickets which never have this property.
+Specifying a property with an empty value, which is often done for `EncodingProfile.IsMaster`, will match if this property does not exist at all on a ticket. So for `EncodingProfile.IsMaster`, specifying an empty filter will match on recording tickets which never have this property.
 == Pipeline setup during event
@@ Line 58: / Line 58: @@
-=== Simple: decentralised classic (Variant 2)
+=== Simple: single-room setup (Variant 2)
 {{drawio>c3tracker:setup-simple.png}}
@@ Line 67: / Line 67: @@
 For every worker:
-* set room filters in tracker e.g. `Fahrplan.Room = Foobar`
+* set `EncodingProfile.IsMaster = yes` to avoid encoding all sub formats
+* (set room filters in tracker e.g. `Fahrplan.Room = Foobar`, but this cannot be used at the same times as the above, see the warning below)
 For every recoding cube:
@@ Line 76: / Line 77: @@
 * start tracker scripts for encoding: `sudo systemctl start crs-encoding.service`
+<panel type="danger" title="Attention">Since tracker filters are joined via OR and not AND, this setup cannot be extended to multiple rooms without hacks if you want to e.g. limit on-site encoding to master formats.</panel>
 === centralised storage (rsync) (Variant 1)
@@ Line 112: / Line 115: @@
-=== decentralised pipeline (Variant 3)
+=== decentralised pipeline aka "even more samba" (Variant 3)
 <panel type="danger" title="Attention">The "decentralized pipeline (Variant 3)" should not be used by inexperienced users. Use the information above to find out how to get this variant working, then adjust/improve the documentation here.</panel>
-Similar to variant 2, but the release encoder (minion) only mounts the /video/fuse/$room/ from each recording cube. The encoded and tmp files life on one minion, the secondary minions mount /video/encoded and /video/tmp from the primary minion. [Reason: It is not guaranteed that the minion which encoded a talk also does the postprocessing (upload) step.]
+Similar to variant 2, but extended to work with multiple rooms. Instead of using rsync, recorded snippets remain on the encoding cubes and ''/video/fuse/$event/$room'' are exposed via samba to the minions, while the encoded and tmp files live on one "central" minion; all other minions mount ''/video/encoded'' and ''/video/tmp'' from the primary minion [reasoning: the tracker cannot guarantee that the machine which encoded a talk also does the postprocessing (upload) step, so all minions have to see the same files].
+Tracker filters have to be set only for the recording cubes, minions do not require any filters (but on smaller events without many minions, a ''EncodingProfile.IsMaster=yes'' filter can be a good idea, so sub formats won't crowd out the queues — they can always be encoded off-site later).
+On recording cubes: start the followin systemd units:
+ * ''crs-recording-scheduler''
+ * ''crs-mount4cut''
+ * ''crs-cut-postprocessor''
+On all minions, including the one acting as storage, do
-You have to set the room filters only for the recording cubes, the minions can process talks independently.
+  mkdir -p /video/fuse/$event/{$room1, $room2, ..}
+  mount.cifs -o uid=voc,password= {//$encoder1.lan.c3voc.de,}/video/fuse/$event/$room1
+  mount.cifs -o uid=voc,password= {//$encoder2.lan.c3voc.de,}/video/fuse/$event/$room2
+  ...
-  * On recording cubes:   start systemd units for steps A ''crs-recording-scheduler'', B ''crs-mount4cut'', and C ''crs-cut-postprocessor''
+On all minions except the one acting as storage, also mount:
-  * On release encoders:  start systemd units for steps D ''crs-encoding'', E ''crs-postencoding'', and F ''crs-postprocessing''
+  mount.cifs -o uid=voc,password= //$storage.lan.c3voc.de/encoded /video/encoded
+  mount.cifs -o uid=voc,password= //$storage.lan.c3voc.de/tmp /video/tmp
+  mount.cifs -o uid=voc,password= {//$storage.lan.c3voc.de,}/video/intros
+Finally on all minions, including the one acting as storage, start the following systemd units:
+ * ''crs-encoding''
+ * ''crs-postencoding''
+ * ''crs-postprocessing''
-==== New example with systemd units and case 1 and 5:
+==== Old example with systemd units and case 1 and 5, which was used during jev22 in Munich:
 {{drawio>c3tracker:setup-variant-3.png}}