On Fedora, Avidemux stdout output is automatically written to user's journal if not run in a TTY (this is why I always run Avidemux in a TTY). Is it not the case on yours?

On Windows and macOS, stdout is redirected to file, which can be examined in a text editor from Avidemux GUI (on Windows) or universally with any plain text viewer when the user has basic filesystem navigation skills.

The real problem arises from this log file rapidly growing (sometimes by > 1 MiB per second) from careless use of printf and its wrappers (we had requests, pretty valid, to let users disable logging alltogether) causing a DoS situation or filling up the disk as the worst case.

Adding an internal viewer is surely a good thing (it can be handy in normal situations not involving crashes), I just wonder what could be done to address the big issue.

Is it not the case on yours?

I run it from the start menu (except when i now i want to see the stdout).

I just wonder what could be done to address the big issue.

exactly what "verbose logging infrastructure" supposed to solve (on the long term).

I run it from the start menu (except when i now i want to see the stdout).

I meant, that whenever no TTY is attached, the stdout is dumped to journal. Is this not the case on your system?

exactly what "verbose logging infrastructure" supposed to solve (on the long term).

This would require replacing every single ADM_info, ADM_warning and ADM_error in the existing code. At the same time, plain printf would remain untouched (printf cannot be universally replaced with ADM_info in Avidemux code, they serve different purposes). I don't see how this helps to solve the problem.

I meant, that whenever no TTY is attached, the stdout is dumped to journal. Is this not the case on your system?

I dont know anything about that. (Ubuntu based)

This would require replacing every single ADM_info, ADM_warning and ADM_error in the existing code.

As i indicated, it would be helpful on the long term. But it would not require replacing every such, just the polluting ones.

At the same time, plain printf would remain untouched (printf cannot be universally replaced with ADM_info in Avidemux code, they serve different purposes).

Well, printf shouldnt be used AT ALL. Those are 99% leftovers from ancient lazy debugging attempts. ADM_info, ADM_warning and ADM_error should be used everywhere.

I dont know anything about that. (Ubuntu based)

Launch Avidemux via .desktop file (from start menu, dock, whatever), then run journalctl in the terminal.

But it would not require replacing every such, just the polluting ones.

If it were not that hard to identify the messages which can become repeated offenders...

Well, printf shouldnt be used AT ALL. Those are 99% leftovers from ancient lazy debugging attempts. ADM_info, ADM_warning and ADM_error should be used everywhere.

They have different features. ADM_info is unusable with long lines like the list of OpenGL extensions in UI_Qt4InitGl() or when full control of formatting is needed.

I think we should start with redefining printf. We probably should not use preferences for toggling silent mode as inability to open GUI would preclude users from disabling silent mode.

I would suggest to split the task in three stages:

1. silent mode (all or nothing, via redefining printf), controlled by a global var (inherited from env??)
2. verbosity level infrastructure, would allow to prioritize / filter messages, controlled by preferences(?)
3. user comfort (a console-like log viewer)

Launch Avidemux via .desktop file (from start menu, dock, whatever), then run journalctl in the terminal.

Only kernel/system messages are shown.

1 silent mode

IMHO this would be "easy", just enable/disable writing log into a file

Only kernel/system messages are shown.

This is interesting. Might be desktop environment dependent as on a pretty default Debian 11 installation with gnome-shell all Avidemux stdout output lands in journal either (when launched from menu).

just enable/disable writing log into a file

This would leave a good deal of Linux users not covered.