Restart Vocotomixes source via voctogui

[derpeter]

As we still experience problems with the source scripts it would be great to be able to restart the systemd unit via voctogui. This could either be accomplished via the control protocol and an listener on the vocotocore box or via SSH (e.g. with paramiko)

[MaZderMind]

After discussion we decided to not add that to the GUI, but instead create a Room-Admin-Webapp which can be accessed from a Smartphone or any webbrowser and allows checking and managing all systems in a room.

This would include

• restarting the voctocore
• stopping and starting the recording
• checking whether recording is running
• restarting all sources and all sinks

as well as in a later setup

• monitor the hyperdeck backup
• control the audio-mixers
• control the jvc-cameras

[derpeter]

i dont think this will solve the problem. On the one hand this still involves that the person in the room calls somebody who can operate the web app on the other hand the person who is constantly looking at the gui dont sees the problems you monitor with the web app. The web app sound like a good addition but it dont solves this missing feature. Also this solution is very special and only works on conference with much stuff. In my opinion vocotomix should also be operable on its own without a huge team.

To the controll cam / hyperdeck / mixer: This was an complete different feature. Controlling the cam from an web app is already possible we just need to use the web interface from the cam. Controlling the cam from voctogui instead would allow the operator to realtime fix wrong focus, this is nothing you should do on a phone but on a big screen.

[MaZderMind]

Okay, I'm with you on that. So let me propose this generic method of implementing that.

The voctocore could have configuration similar to this:

[command]
commands=restart-grabber,record-cut-timestamp

[command.restart-grabber]
title=Restart Grabber-Source
icon=some-fancy-icon.svg
execute=systemctl restart voctomix-grabber-source.service

[command.record-cut-timestamp]
title=Record the current Timestamp as Cut-Mark
icon=some-fancy-icon.svg
execute=date >> /video/roomX/cutmarks.txt

A similar methd could be used with #93 to achieve #44 and warn, when for example the recording starves:

[command]
polls=recording

[poll.recording]
title=Recording does not work! Call 100!!
execute=/opt/voctomix/scripts/check-recording.sh

[fightling]

In voctomix 2 I've thrown even away the TCPSingleConnection and used Gtk's tcpserversrc which I'm not sure about if it was a good idea. What do you think about exporting sources back into separated pipelines to be able to restart them separately? Would that bring back the sync issue? What do you think?

[MaZderMind]

Restarting sources has been necessary some times, for example at 35C3 we had to restart one the Decklink-Slide-Source during one talk, because it just showed black/silence. We were able to do this via the Command-Line-Protocol without restarting the complete Process and it brought back the Slides.

On the other hand this exact issue might not have been there in the first place with the Single-Pipeline-Design. I certainly see that restarting pieces of the Pipeline is more problematic with the Single-Pipeline and so would suggest to not worry about it for now.