#1775 Uncertain of whether logging is working correctly

[musewhirl]

I used to complain about too much logging, but now it's quite the opposite. Unless I missed a change, my attention was drawn to check whether there is a problem. So yes, I'm now complaining about too little logging now that I need it :-) I guess the problem is the inability to see how to control it using just Rosegarden, as opposed to searching the internet.

As always, I build with the option: CMAKE_BUILD_TYPE=Debug, and that is clearly given in the documentation related to building...no problem there.

Focusing on the following log entry which is one of the few I see now:

[main] sfxload disabled

I tracked this to only one place in the code: main.cpp

RG_DEBUG << "sfxload disabled";

Now, a statement like that occurs thousands of times throughout the code, but I don't see any of those messages? Perhaps yet some other preliminary flag or environment variable has to be set in addition to the make statement? So, why does the one above show up at all?

Many application provide a command-line log-level allowing the user to switch between e.g. RGINFO, RG_WARNING and RG_DEBUG, which are some of the few I see in the code. I tried the following for a clue:

rosegarden --help

...but that gives no indication that a log-level can be selected. Why? Is it not possible to set the level of Rosegarden from its command line?

Next I thought GUI preferences and checked those...no clues there either. I looked in the Rosegarden.conf file itself and found only one reference to the word debug:

debug_AlsaDriver=false

I changed that to true, just to see what would happen. Either the AlsaDriver is doing nothing, which seems unlikely, or something is wrong...the logging was exactly the same as before, right down to what appears at the end of this post.

Being forced to look around the code, I do see references to environment variables and Qt settings, but then again I am on debian 13 using GTK via the QT_QPA_PLATFORMTHEME=gtk3, so I'm not sure if that's an issue?

In any case, it seems like a good place to provide a clue would be via the RG_INFO in the log itself i.e. "if you need more logging do whatever...". In the mean time, I hope the do whatever will turn up during feedback here.

The entire normal start nowadays is shown below. Actually playing and stopping compositions adds hardly any, unlike in the past.

[main] System Locale: "en_US"
[main] Qt translations path:  "/usr/share/qt6/translations"
[main] Qt translations not loaded.
[main] RG Translation: trying to load :locale/ "en_US"
[main] RG Translations loaded successfully.
[main] Loaded application icon "rg-rwb-rose3-16x16"
[main] Loaded application icon "rg-rwb-rose3-32x32"
[main] Loaded application icon "rg-rwb-rose3-48x48"
[main] Loaded application icon "rg-rwb-rose3-64x64"
[main] Loaded application icon "rg-rwb-rose3-128x128"
[main] Unbundling examples...
[main] Unbundling templates...
[main] Unbundling libraries (device files)...
[main] Creating RosegardenMainWindow instance...
[SequencerThread] run()
[PluginFactory] enumerateAllPlugins() begin...  Enumerating and loading all plugins...
[PluginFactory] enumerateAllPlugins() end.
[Exception] Creating: "Failed to open tranzport device /dev/tranzport0"
[main] sfxload disabled
[main] Launching the sequencer...
[main] Starting the app...
[StartupTester] StartupTester::StartupTester(): URL:  "http://www.rosegardenmusic.com/latest-version.txt"
[StartupTester] StartupTester::slotNetworkFinished(): Connection failed:  "Host www.rosegardenmusic.com not found"

[Philip Leishman]

I think the key is the macro #define RG_NO_DEBUG_PRINT which is included in most files.
This suppresses the debug output. To see debug for a certain file this line must be commented out and Rosegarden must be recompiled.

[musewhirl]

So, if I don't know exactly where a problem is located, and need to see the overall RG_DEBUG level to focus in on it, I would have to check every file for the RG_NO_DEBUG_PRINTline and then manually edit those files and recompile? It seems a bit clunky to me?

Ideally, when launching, the command-line could have a flag e.g. --log-level=DEBUG (defaulted to INFO). And if that is too difficult for some reason, then some way of adding a flag to the compile stage which sets the overall debug level for that particular build. I guess it would have to be another flag now that the first (CMAKE_BUILD_TYPE=Debug,which is now quite confusing) does not do what I expected. That way, the build code remains closer to the whatever was downloaded, in case the user is reporting a bug. Although the rebuild is still clunky, users could have two RG binaries around...the original for normal use, and one with an overall RG_DEBUG across the files, where they accepts the execution speed hit when investigating something. I prefer the command-line version myself though.

[Philip Leishman]

That's the way it is.
There was a discussion about using Qt category logging a while back (feature request 492) - this would enable runtime debug activation without recompile.

[Ted Felix]

So, if I don't know exactly where a problem is located, and need to see the overall RG_DEBUG level to focus in on it, I would have to check every file for the RG_NO_DEBUG_PRINT line and then manually edit those files and recompile?

Yes. If you need some suggestions on which files might be associated with specific issues, just ask on the devel mailing list and we'll point you in the right direction.

It's not very likely that the debug logging that is in a particular file will be of much help for debugging a specific problem. You've run into plenty of misleading logging in rg. It's very likely you will need to add some more specific logging related to the issue you are tracking down.

[musewhirl]

When I opened the bug, I wasn't thinking that log levels was a development activity, but a developer way to help users provide more information when something goes wrong. Hence the idea of command-line --log-level (as per lilypond) and --verbose (as per jackd). And I've seen many such command-line options in applications over time, especially on linux.

However, I don't see it in ardour either, so maybe the lack of it is just a DAW thing? In any case, if the user has already built RG, then they can easily alter the code (at their own risk). I fall into that category. As for normal users who get it from a repository, I assume they would have asked for the feature if they needed it.

This appears to be expected behavior in RG, so feel free to close this bug, since it's not. The drastic drop in logging was intentional, and does make it easier to spot something unexpected when it turns up.