Show debug info in about page

[vchernin]

It would be helpful for debugging to show the commit of the build in a debug section/page in the about window. We could also show things like distro or whether this is the flatpak build. Potentially info about plugins and so on could also be added.

We could ask in the bug report template to copy paste from this window to ensure we have accurate info to start with.

[wwmm]

It would be helpful for debugging to show the commit of the build in a debug section/page in the about window. We could also show things like distro or whether this is the flatpak build. Potentially info about plugins and so on could also be added.

I think that as long as the issue is not one of those where EasyEffects crashes before its window is shown it would help. But I am not sure about how to get some of these information in a way that works both on Flatpak and non Flatpak builds.

Maybe we should try to get some of this information in the logs first and after this considering if it will be worth the effort of having them in the about window.

[vchernin]

FYI we can get some distro information with /etc/os-release, annoyingly only fields like ID are actually guaranteed to be there: https://www.freedesktop.org/software/systemd/man/os-release.html. We can use this to find out if this is a flatpak, and for other builds what distro they are on.

I think showing information about plugins or pipewire itself would be useful. For inspiration where I got this idea from originally is gnome builder: https://gitlab.gnome.org/GNOME/gnome-builder/-/blob/main/src/libide/gui/ide-support.c

[vchernin]

What do you think of just recording all the already existing logs using the internal log helper functions (all of them meaning as if G_MESSAGES_DEBUG=easyeffects was passed), and copying them into the troubleshooting section of the about window? So then users can just copy paste from the app to get logs when they see an issue.

This would make it easier to get logs, since users don’t need to open the command line and then copy paste or save stdout and stderr to a file manually. Also they don’t need to restart the app, which is a problem because easyeffects needs to be fully quit if shutdown on window close is disabled, and that is easy to miss.

I’m sure it’s possible the logs could balloon, for that case there could be a hardcoded limit on kept log size. Most of the time I imagine the logs aren’t that massive?

I don’t think there should really be a performance impact since the codepath for logs is mostly executed normally anyhow (just the logs don’t get printed) I think?

I don’t think recording the plugins is terribly useful since we have a fairly clear error message if plugins are missing now. But things like pw-dump do record plenty of useful information and work in Flatpak.

Also perhaps it is possible to enhance the logs by passing environment variables like PIPEWIRE_DEBUG.

[vchernin]

Also, we can create a url like so:

https://github.com/wwmm/easyeffects/issues/new?title=my%20issue&body=```here%20are%20my%20logs```

The user can click the link and can create an issue with the logs already filled in, all formatted properly. Albeit the query parameter length limits seems to vary across browsers, and depends on GitHub’s limits so this may not work.

[wwmm]

What do you think of just recording all the already existing logs using the internal log helper functions (all of them meaning as if G_MESSAGES_DEBUG=easyeffects was passed), and copying them into the troubleshooting section of the about window? So then users can just copy paste from the app to get logs when they see an issue.

I think that the problem is that this path is not useful for when the app crash. In this case there is no way to view the troubleshooting section. So in general we will still need to use both methods to get logs and we may have users providing duplicated data if they do not realize both paths provide the same information.

I don’t think there should really be a performance impact since the codepath for logs is mostly executed normally anyhow (just the logs don’t get printed) I think?

Internally glib ignores the calls to functions like g_debug if G_MESSAGES_DEBUG=easyeffects is not set.

Also perhaps it is possible to enhance the logs by passing environment variables like PIPEWIRE_DEBUG

It gets too messy because PipeWire's logs can be really huge depending on the log level being used.

As EasyEffects logs usually are not big performance probably won't be a problem. But as we still have to use the current procedure in the cases where the app crashes or the window does not open I am not sure it is worth the effort.

[vchernin]

But as we still have to use the current procedure in the cases where the app crashes or the window does not open I am not sure it is worth the effort.

It is indeed confusing to have 2 ways to find the logs. At least when the window doesn't open the only thing that can be done is to check the command line anyhow.

I think that the problem is that this path is not useful for when the app crash. In this case there is no way to view the troubleshooting section.

How about outputting logs to a file as the app runs? This would also help with hard to reproduce crashes. I don't think writing to a file is much worse than writing to memory. We would need to worry about not filling the sytem with logs, but that should be solvable...

It is also possible to try do our own crash handlers by handling SIGSEGV and other signals. But I am not sure if that would impact how stack traces look on things like coredumpctl. So long as the logs are safe somewhere is probably the most useful thing.

[wwmm]

How about outputting logs to a file as the app runs? This would also help with hard to reproduce crashes.

There are some applications that do this. I think we can do some tests and see how it goes. We will probably have to open and close the file whenever something is printed with the log functions. But as we do not print a lot it should be fine.

I don't think writing to a file is much worse than writing to memory.

It is a lot worse. Specially on slow drivers. But fortunately we do not write logs as often as PipeWire and Gstreamer do when using high log levels.

We would need to worry about not filling the system with logs, but that should be solvable...

In my opinion EasyEefects should delete and recreate the log file whenever it is started. There is no reason to have a log file with output of older runs. With this procedure in place the only other case to deal with is the one from the users that almost never reboot the computer. So for these cases a check for a reasonable file size has to be in place.