ERROR:jackpatch.jack_engine_remote - Failed to get ports and connections from patchbay_daemon, will quit.

[ycollet]

I use Ray Session 0.17.1 on Fedora 42.
When I create a new session, jac patch has a "save" symbol always grayed.
In the console, I've got the following error message:

ERROR:jackpatch.jack_engine_remote - Failed to get ports and connections from patchbay_daemon, will quit.

No other errors are displayed. I can continue building the session, but once I restart, Ray Session will not reconnect the elements of the session.

[ycollet]

I removed Ray Session directory and .config/RaySession and the problem is still the same.

[Houston4444]

I saw this bug and I think I have already fixed it in the master branch. I was waiting for any other bugs to publish a bugfix release. I will release it soon.

[ycollet]

Thanks a lot !

[ycollet]

Problem still happening with 0.17.3

[ycollet]

I put a logging message in:

RaySession/src/clients/jackpatch/jack_engine_remote.py

Line 140 in abe65b5

@bun_manage(rpm.BIG_PACKETS, 'i')

To display the content of the osp argument and I came to the conclusion that the BIG_PACKETS message is never sent ...
Do you have some hint to helper me continue the debugging ? :)

[Houston4444]

I came to the conclusion that the BIG_PACKETS message is never sent ...

mmmh, or never received ;) !

The message should be sent from this function :

RaySession/src/patchbay_daemon/osc_server.py

Line 182 in abe65b5

def send_distant_data(self, src_addrs: list[Address]):

or more exactly in the mega_send method (last line of the function).

mega_send is used between two known servers to send multiple messages together, for performance and to avoid some missing messages. Here, ray-jackpatch is Internal and has no really an OSC server, but a dummy one, used by commodity.

You will find the mega_send method here:

RaySession/src/shared/osclib/bun_server.py

Line 500 in abe65b5

def mega_send(

Because ray-jackpatch is Internal, it is in the same process than the main OSC server, so this function should be used

RaySession/src/shared/osclib/bun_server.py

Line 424 in abe65b5

def _mega_send_same_process(self, urls: list[str | int | Address],

.
print a log at this line to know if a local mega_send message is sent (it should !):

RaySession/src/shared/osclib/bun_server.py

Line 451 in abe65b5

_process_port_queues[dest_port].put(

[ycollet]

So, I put a print in this area:

            if dest_port:
                # we are sending a MegaSend to another instance
                # in the same process. No OSC communication is needed       
                for path, *args in mega_send.tuples:
                    print(f"DEBUGDEBUG: {dest_port} -> {args}")
                    _process_port_queues[dest_port].put(
                        OscPack(path, args, get_types_with_args(args), # type:ignore
                                Address(self.port)))
                same_proc_urls.append(url)

The message displayed in the session below:

DEBUGDEBUG: 17574 -> ['', '']
DEBUGDEBUG: 17574 -> ['', '']

And then loaded a session with tuxguitar / guitarix / non-mixer-xt:

$ raysession 
Unable to find theme 
WARNING:patchbay.patchcanvas.patchcanvas - theme '' has not been found,use 'Yellow Boards' instead.

[ray-daemon]
URL : osc.udp://192.168.1.27:16187/
      osc.udp://fedora.home:16187/
ROOT: /home/ycollette/Ray Sessions
GUI connected at osc.udp://fedora.home:17573/
Attempting to open /home/ycollette/Ray Sessions/TuxGuitar
DEBUGDEBUG: 17574 -> ['', '']
DEBUGDEBUG: 17574 -> ['', '']
Commanding smart clients to switch

[Non-Mixer-XT-m_xt]
[non-mixer-xt] Announcing to NSM

[ray-daemon]
'm_xt' has announced itself (name: Non-Mixer-XT, port: 13315, pid: 43340)
'guitarix' has announced itself (name: Guitarix, port: 17577, pid: 43345)

[Guitarix-guitarix]
NSM: Successfully registered. NSM says: Howdy, what took you so long?

[Non-Mixer-XT-m_xt]
[non-mixer-xt] Successfully registered. NSM says: Howdy, what took you so long?

[Guitarix-guitarix]
Gdk-Message: 21:03:14.299: Window 0x555ea9d37480 is a temporary window without parent, application will not be able to position it on screen.

[Non-Mixer-XT-m_xt]
[non-mixer-xt] Info: created by = The Non-Mixer-XT 2.0.13
[non-mixer-xt] Info: created on = Mon Mar  2 08:17:38 2026
[non-mixer-xt] Info: version = 1

[ray-daemon]
'm_xt' sends dirty

[Non-Mixer-XT-m_xt]
[non-mixer-xt] Add mixer strip "Guitarix"

[tuxguitar-tuxguitar]
WARNING: A restricted method in java.lang.System has been called
WARNING: java.lang.System::loadLibrary has been called by org.eclipse.swt.internal.Library in an unnamed module (file:/usr/lib/java/swt.jar)
WARNING: Use --enable-native-access=ALL-UNNAMED to avoid a warning for callers in this module
WARNING: Restricted methods will be blocked in a future release unless native access is enabled


[Non-Mixer-XT-m_xt]
[non-mixer-xt] Add mixer strip "TuxGuitar"
[non-mixer-xt] Add mixer strip "Master"

[ray-daemon]
[non-mixer-xt] Loaded project "/home/ycollette/Ray Sessions/TuxGuitar/Non-Mixer-XT.m_xt"
'm_xt' sends clean
Client 'm_xt' sends gui hidden
Telling all clients that session is loaded...
Telling client Non-Mixer-XT that session is loaded.
Telling client Guitarix that session is loaded.
Loaded
Done
ERROR:jackpatch.jack_engine_remote - Failed to get ports and connections from patchbay_daemon, will quit.

[Guitarix-guitarix]

(guitarix:43345): Gtk-CRITICAL **: 21:03:14.882: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed

[ray-daemon]
Client 'guitarix' sends gui shown

[tuxguitar-tuxguitar]

(TuxGuitar:43366): Gtk-WARNING **: 21:03:16.065: Negative content width -1 (allocation 1, extents 1x1) while allocating gadget (node scrolledwindow, owner GtkScrolledWindow)

(TuxGuitar:43366): Gtk-CRITICAL **: 21:03:19.517: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed

(TuxGuitar:43366): Gtk-WARNING **: 21:03:20.796: Negative content width -1 (allocation 1, extents 1x1) while allocating gadget (node scrolledwindow, owner GtkScrolledWindow)

So, message sent, but not received a priori.

[Houston4444]

humm, not sure of what is send, the mega_send method is used at many places. Could you print also the path in your debug ?

[ycollet]

Here is the result:

DEBUGDEBUG: /ray/patchbay/group_custom_name - 16380 -> ['', '']
DEBUGDEBUG: /ray/patchbay/port_custom_name - 16380 -> ['', '']

[Houston4444]

Ok, ce n'est pas ce qu'on cherche (oui je passe au français ce sera plus simple pour nous, désolé pour les autres).

Ces deux messages sont transmis du serveur principal vers le serveur du patchbay (qui sont ici tous deux dans le processus du patchbay).

Pour t'assurer que les print() que tu vas mettre dans mega_send (et ses fonctions appelées) correspondent à l'appel que tu cherches, tu vas devoir mettre un print AVANT et un print APRÈS l'appel à mega_send dans send_distant_data.

Dans notre cas, send_distant_data ne semble pas envoyer de message de bienvenue au ray-jackpatch.
Je m'explique un peu: En mode Internal, le ray-jackpatch est un module interne au démon qui va se connecter au démon du patchbay (qui lui aussi est interne dans ton cas), et il se connecte comme s'il était une GUI. Pour comprendre pourquoi le message de bienvenue n'est pas envoyé par le démon du patchbay au ray-jackpatch, il faudra possiblement remonter jusqu'à

RaySession/src/patchbay_daemon/osc_server.py

Line 219 in abe65b5

def add_gui(self, gui_url: str):

et comprendre pour quelle raison ce message n'est pas envoyé.

Je vais essayer d'installer une VM de fedora mais je commence à être limite limite en place.

[ycollet]

Quelle version de pyliblo tu utilises ?
A priori, Fedora est sur cette version:

%global commit 91d17815b911ccc2c1d1408412e7885c32f2d460
%global snapdate 20240801
https://github.com/gesellkammer/pyliblo3

Je vois sur ce dépôt un patch que tu as proposé a été mergé, mais la version Fedora utilise une version antérieure.
Possible que le souci vienne de là ...

[ycollet]

Je viens de mettre à jour localement le paquet python3-liblo et ça ne change rien.
Après, je vois que python3-liblo est testé avec python 3.13 et c'est python 3.14 qui est dans Fedora 43.

[Houston4444]

C'est bon, je pense que je l'ai eu ! Si tu peux essayer le git master, chez moi ça marche (en VM). la fonction are_on_same_machine qui faisait encore des faux négatifs.

On va être bons pour une v0.17.4 avec ça plus le problème de complétion.

[ycollet]

Effectivement, ça a l'air de mieux fonctionner :)

[ycollet]

Bad news. A priori la version 0.17.4 a de nouveau le bug.
Je vais refaire un test demain et je te tiens au courant.