Server de-registers on GUI state change

[ann0see]

I tested running the server on macOS and it needed multiple tries to show up as directory. The directory did not show up for a local client if a path for recordings is set. It may not be related and needs more investigation (test with a path that is not writable).

It seems as if on 3.10.0 the directory shows up instantly.

Ursprünglich gepostet von @ann0see in #3259 (comment)

[softins]

I'll try it here and see if I find the same, and do some diagnosis if I do. But it will probably be after the weekend.

[softins]

I just tried the latest build of mac legacy, and it seems to register ok. I had one occurrence at the start when it registered, but then dropped back pretty quickly to not registered. But I've been unable to replicate that with several attempts: it has been registering fine and staying registered.

@ann0see Is there a repeatable way you have found to demonstrate the problem?

Or maybe I have misunderstood the description of the issue?

[ann0see]

I had one occurrence at the start when it registered, but then dropped back pretty quickly to not registered.

I think that's what I saw. I don't have macOS access at the moment. Sorry for it being vague. It may have to do with restarting the server having a recording directory set to which the application doesn't have access to -> so the reason is the macOS sandbox.

If the directory is set again, the sandbox has a whitelist to the chosen directory. But this may be reset after an app restart.

[ann0see]

Let me try to come up with steps to reproduce:

1. Install a build with hardened runtime/sandbox enabled
2. Set a recording directory
3. Set custom directory address to localhost to register as directory.
4. Choose the custom directory -> everything should work as expected
5. Close the server
6. Re open the server and check the directory with a client with custom directory as localhost.
7. Check the registration status - Register with custom directory and one of the inbuilt directories. See what happens.

[ann0see]

@softins could you please try again and wait a bit on the Server GUI? I can reproduce this with the new legacy build.

[softins]

1. Install a build with hardened runtime/sandbox enabled

What does this mean? Is it a special kind of build, or some special setting to apply to an installed application?

[ann0see]

This means that it's a sandboxed build. Both legacy and normal from the CI should be sandboxed. At least both show the error.

[ann0see]

Seems like a blocker!

[ann0see]

@softins can you reproduce this bug on your Mac?

[ann0see]

Now this also seems to apply to other directories like any genre 1, not just registering with localhost.

[pljones]

Have you tried downgrading your version of macOS? That would help diagnose the problem, at least.

This occurs on a Qt 6.7.x build, too? If not, it's going to be down to a Qt bug and the fix will never be back-ported.

[ann0see]

It occurs on legacy and non legacy but doesn't seem to happen on 3.10.0. So I suppose it's a bug on our side.

[pljones]

What version is the non-Legacy build now?

What was it for 3.10.0?

Does the tagged 3.10.0 release built with the current build chain work or not?

[softins]

I have just been testing on my Macbook. It looks like the latest version of GUI server will register with a directory (I tested using private.jamulus.io), but as soon at its window loses focus, such as when switching to a client to try connecting, the server loses its registration and the GUI reports "Not connected". It then does not appear in the list of servers shown in the client's Connect dialog.

I can see in Jamulus Explorer that the registration did initially succeed, and was maintained as long as the GUI retained focus. When it lost focus, the registration was actively cancelled with the directory, as Explorer showed the server was gone.

I went back to 3.10.0 server, and this behaviour doesn't happen; the registration is maintained when the server window loses focus.

Thankfully, I have about 16 different post-3.10.0 versions of Jamulus and JamulusServer app installed, so I want through them from earliest to latest until I got to one exhibiting the loss of registration.

By checking the commit IDs of the latest working build and the first failing build, I've deduced that the change in PR #3144 is what breaks it. This is the PR that adds the saving of settings on GUI state change. It was intended to fix an issue on the Android version of Jamulus client. But in server mode it does seem to kill the registration. I haven't diagnosed why yet. It's probably not specific to the Mac.

[pljones]

It's really intended for mobile rather than desktop. If it does affect the Windows desktop (I think I tested it there, though), we could make it mobile-only.

[softins]

I think on the client it's fine, but needs specific testing of the GUI server on the various platforms, and its effect on registration. I'm away for another week, so can't do much except on my Macbook.

[pljones]

It sounds almost like MacOS is putting the app to sleep following that commit and, as it didn't previously acknowledge "states", it wasn't doing so. Is there some setting that can be used not to put the app to sleep when it's not got focus? Or like the run in background power states on Windows? (I notice 3.10.0 doesn't have the advanced option on Windows... let me check the latest.)

[pljones]

Oh! It switches to "Not registered" immediately the window loses focus. Strange.

OK, there are builds of the main branch just before the merge of the state change PR and just after
Before: https://github.com/jamulussoftware/jamulus/actions/runs/9724415397
After: https://github.com/jamulussoftware/jamulus/actions/runs/9724432662

[ann0see]

MacOS is putting the app to sleep

This can happen and is called App Nap I think. But it doesn't seem like that.

[pljones]

src/settings.cpp 982:

    // we MUST do this after saving the value and Save() is only called OnAboutToQuit()
    pServer->SetDirectoryType ( AT_NONE );

... except Save() is no longer only called OnAboutToQuit(). I think maybe Server OnAboutToQuit() handler should call Save() and pServer->SetDirectoryType ( AT_NONE ) - not expect Save() to de-register the server.

---

Oh, we have two handlers for the QCoreApplication::aboutToQuit signal -- CSettings and CServer. The latter does not set pServer->SetDirectoryType ( AT_NONE ) because it could run before the former, which would then save the wrong value... Hm. What a mess.

---

Common to client and server - calls CSettings::Save, which is abstract, so either CClientSettings::Save or CServerSettings::Save is called.

src/settings.h:        QObject::connect ( QCoreApplication::instance(), &QCoreApplication::aboutToQuit, this, &CSettings::OnAboutToQuit );

---

Server-only:

src/server.cpp:    QObject::connect ( QCoreApplication::instance(), &QCoreApplication::aboutToQuit, this, &CServer::OnAboutToQuit );

src/recorder/jamcontroller.cpp-        QObject::connect ( QCoreApplication::instance(),
src/recorder/jamcontroller.cpp-                           &QCoreApplication::aboutToQuit,
src/recorder/jamcontroller.cpp-                           pJamRecorder,
src/recorder/jamcontroller.cpp:                           &CJamRecorder::OnAboutToQuit,
src/recorder/jamcontroller.cpp-                           Qt::ConnectionType::BlockingQueuedConnection );

src/serverlist.cpp:    QObject::connect ( QCoreApplication::instance(), &QCoreApplication::aboutToQuit, this, &CServerListManager::OnAboutToQuit );

[pljones]

I think the easier fix is to add a parameter to CSettings::Save that indicates it's being called to handle QCoreApplication::aboutToQuit rather than some other reason.

[pljones]

PR raised - if someone could check on MacOS, please?