Broadcasts not working properly in multiseat environment

Could you try this change?

sudo gedit /usr/lib/python2.7/dist-packages/epoptes/ui/gui.py
line 279, change it from:
        self.execOnSelectedClients(["receive_broadcast", self.vncport,
                                    self.pwd, fullscreen], mode=EM_SYSTEM_OR_SESSION)
to:
        self.execOnSelectedClients(["receive_broadcast", self.vncport,
                                    self.pwd, fullscreen], mode=EM_SESSION_OR_SYSTEM)

Close an reopen epoptes, and see if it helped.

You did it! The broadcast is working as expected now!

Thank you very much!

Fix Commited? I've found no new commit in Epoptes trunk branch.

I suppose that EM_SESSION_OR_SYSTEM is not a good default for Epoptes, right? Could you please explain briefly the difference between these execution modes (EM_SYSTEM_ONLY, EM_SESSION_ONLY, EM_SESSION_OR_SYSTEM, EM_SYSTEM_OR_SESSION, etc.)?

@Youssef Habri: please don't change the bug status without comments, that change I proposed wasn't committed upstream.

@Laércio de Sousa: there are 2 epoptes-client processes running for each workstation. One runs as root (EM_SYSTEM), the other runs inside the user session (EM_SESSION).
On a few cases though, like NX connections, only the session epoptes-client process is available.

We normally want the system epoptes-client to receive the broadcasts, because it's faster for thin clients, and that's why we default to EM_SYSTEM_OR_SESSION, which means: "try to receive the broadcast with the system epoptes-client, but if there's no system epoptes-client, then use the session one".

That fails on multiseat systems because there's only one system epoptes-client process, and it can't handle all the displays.

A proper fix will be committed much later, when we re-design Epoptes to use forward connections instead of reverse connections, and also epoptes-client to be able to handle multiple displays and seats with a single system process and without any session processes at all.

So until then you'll have to use the workaround mentioned in comment #1. :)

@Laércio de Sousa: if this is the only problem remaining in epoptes for multiseat systems, then we may be able to work around it by only using "EM_SYSTEM_OR_SESSION" on LTSP clients, so that you don't have to maintain an epoptes "fork" (https://bugs.launchpad.net/+branch/~oiteam/epoptes/workaround-broadcasting-multiseat) just for that...

@Alkis Georgopoulos: Epoptes' reverse-conection design already makes it work almost out-of-the-box in multiseat environments. Great job!

As far as I can feel by using Epoptes in my multiseat lab, yes, this is the most critical problem, but there's another issue that would be interesting for general multiseat purposes, namely: the possibility of launching just one root terminal per CPU, instead of one per display, when I select several clients.

We already discussed about it in #980141, and I created this branch to implement a workaround: lp:~oiteam/epoptes/multiseat-one-root-terminal-per-host. In my case, I just changed the default behavior of "Root, locally" menu item, because it's easier than adding a new menu item "Root, locally (one per host)", but I believe you can provide a better solution.

I maintain a separate branch for each workaround (and merge all of them when building my custom packages), so I can easily get rid of it as the solution goes upstream.

This fix worked for me!

Epoptes 0.5.10 running on Ubuntu MATE 18.04.1 LTS 32-bits, both server and clients.

Anyway, I must wait the clients to open a session in their machines to get them accessed through epoptes. Before updating from Ubuntu 16.04 to Ubuntu 18.04, I was able to broadcast their screens BEFORE they could open a user session so I could force them to start working. Any idea?