profile=pseudo-gui should enable warnings log when using the OSX app bundle

[Cpuroast]

When mpv is used with the OSX app bundle, profile=pseudo-gui effectively disables all logging, yet an empty mpv.log gets created on launch.

This is in reference to the recent interpolation change requiring "video-sync=display-*"

A regular OSX user wouldn't immediately realize that interpolation has silently been disabled because video-sync=display-* is now required.

I suggest altering the "pseudo-gui" profile to set these 2 options, so that mpv.log actually gets populated with warnings that come up, this would at least provide some indication as to why interpolation was disabled, and whatever else may come in the future.

msg-level=all=warn
terminal=yes

[sumyungguy]

I agree it would be nice to be able to set the logging level for the OS X app bundle, but I don't think it's because of the pseudo-gui setting. See #1590 - this is probably a dupe of that. Up until the last version or two, mpv used to write things into ~/Library/Logs/mpv.log. The content of what it wrote has changed over different versions, and there never seemed to be any way to control it. The current release doesn't write anything there anymore.

You're supposed to be able to override pseudo-gui settings in mpv.conf with a [pseudo-gui] block, but I tried that and it didn't have any effect at all, for any of the options eg. screenshot-directory. So it's hard to say exactly, whether it's having any effect on the logging.

The log file isn't supposed to depend on terminal verbosity or msg-level anyway, but only on -v arguments. If you specify a path with eg. log-file=/Users/me/Desktop in mpv.conf (requires a full path name, ~/Desktop doesn't work) it does write a verbose log there. I can't find a way to control the verbosity. It doesn't include warnings eg. about misconfigured mpv.conf file, etc., that used to also get written to ~/Library/Logs/mpv.log at the same time, but don't anymore.

[edit: For future reference, the ~/Library/Logs/mpv.log is a capture of what otherwise would be the terminal output on the command line, automatically created by the OS X mpv.app bundle. Its location can't be changed. It has nothing to do with the log-file log, which is always verbose. If log-file is put in the config file, it will miss messages during startup until the config file is read, and it will miss messages about the config file unless it's the first line in the file.]

[Cpuroast]

sumyungguy: as far as I know and from my testing, it is in fact because of the pseudo-gui profile configured in the app bundle.

pseudo-gui defines the following:

[pseudo-gui]
terminal=no
force-window=yes
idle=once
screenshot-directory=~~desktop/

You don't need a [pseudo-gui] block in your config file to override the settings it defines, just put them in your general config area.

So if you add "terminal=yes" to your mpv.conf, suddenly it starts logging to mpv.conf, but it logs too much.

So you add "msg-level=all=warn" to your mpv.conf and then it only logs the relevant warning messages that pop-up, which is the desired behaviour.

Adding those 2 lines to the [pseudo-gui] profile would solve the logging issue when using the app bundle.

[sumyungguy]

Up to and including release 0.12, mpv would always write things to ~/Library/Logs/mpv.log, even without terminal=yes. For example, versions from early 2015 and before would log the file name, status info about it, errors in the file, and so on. I have thousands of lines in mpv.log, going back several years - the file is never truncated - and I've never had terminal=yes set. Releases 0.10-0.12 don't log the file name and info, but still write warnings about eg. misconfigured mpv.conf file options, for example:

Invalid parameter for sub-visibility flag: off
Valid values are:
    yes
    no
    (passing nothing)
Error parsing option sub-visibility (option could not be parsed)
/Users/sumguy/.config/mpv/mpv.conf:19: setting option sub-visibility='off' failed.

msg-level has never had any effect on these messages. Neither has eg. log-file=/dev/null. So up until recently, the only way to prevent mpv from keeping a permanent record of every file you ever watched, was to remove write permission from ~/Library/Logs/mpv.log - if you happened to stumble across it, because its existence isn't documented anywhere.

I don't know where those messages come from, because it's not from the terminal i/o. And I don't know where they went... release 0.13 doesn't seem to write anything by default anymore, and just creates an empty log file there. I can't find anything in the changelog about it.

[edit: the messages do come from the terminal i/o, and are affected by msg-level, but only after the config file is parsed. See comment below.]

It seems you're correct that setting terminal=yes in mpv.conf - not in a [pseudo-gui] block - causes normal terminal stdio/err to be directed into the mpv.log file. That's in addition to the above information, and it doesn't include the above information. For example, in release 0.13, you don't get the warning about a misconfigured mpv.conf file option anymore, even if you set msg-level=v. Too bad, because that was kind of useful information.

As far as I understand, you shouldn't be able to override the psuedo-gui profile settings in mpv.conf that way, unless you put them in a [pseudo-gui] block. The pseudo-gui section in the manual says "The profile always overrides other settings in mpv.conf." Also see #2218 for a discussion where @wm4 says allowing a config file option to override the pseudo-gui profile is not the right thing. Nevertheless you're right, it does work that way, while putting things in a [pseudo-gui] block has no effect as I mentioned.

Note that none of this has anything to do with the log-file function. If you specify a log-file location in mpv.conf, a second log file is created there, in addition to whatever mpv writes (or used to write), and the stdio/err if you have terminal=yes, in ~/Library/Logs. The second log file is always verbose, since, as documented, it's not affected by msg-level, and there's no other config file option to control it.

The point is that the solution is maybe not that straightforward. Your suggestion isn't unreasonable, however:

• the existence of ~/Library/Logs/mpv.log isn't documented. How did you find it? I'd think that most people would find the log-file=<path> option in the manual instead, and remain unaware of the other log file.
• I would be wary of enabling logging by default, particularly to an undocumented log file that's never truncated, and silently gets written to at the same time as another file you've set with log-file.
• on the other hand, the verbose log created by log-file is difficult to wade through. Being able to capture the terminal output in pseudo-gui mode and use msg-level to control it makes sense. But I think it should be documented in the pseudo-gui section, and referenced in the --log-file section (both of which should probably contain the phrase "log file" so you can search for it). And even then, I think it should be "opt-in" rather than enabled by default. If you need to look at the terminal output log, you'll have to look in the manual anyway to find out where it is. If you don't need to look at the log, then it shouldn't be turned on.

Anyway I'm glad this came up, because now I finally understand (more or less) how to control the log file, which is something that has confounded me for a long time. The only thing I'm missing is the info about misconfigured config file options. I wonder why that's not part of the normal terminal/log-file output?

[Cpuroast]

I don't pay too much attention to mpv release versions, I've been using various git master builds since I started using mpv. I simply follow the commit log and update when something interesting comes up, or if it's been some time since my last update.

But I do know that the lack of logging into mpv.log, has been around for quite some time, most likely since the introduction and use of the pseudo-gui profile.

I'm pretty sure I've added the following to my config for that exact reason quite some time ago, and because I'm not a fan of the weird "smaller window->larger window" glitchy looking window resizing artifact caused by "force-window=yes".

force-window=no
msg-level=all=warn
terminal=yes

as for when I wish to check for dropped frames, I simply open terminal and use my mpv alias, which calls: /Applications/mpv.app/Contents/MacOS/mpv --msg-level=all=status

As for where I found the log, I found it in something magical called "/Applications/Utilities/Console.app", where all log files on OSX are displayed. It's an app that's been shipped with OSX since pretty much the beginning and any OSX power user should know about it.

As far as warnings for misconfigured mpv.conf options, they show up in mpv.log if, you have
msg-level=all=warn set.

Having it set at that level is probably what most people care about as it will only log warnings(including mis-configured mpv.conf options, like interpolation set but missing "video-sync=display-*", and won't overwhelm the log.

Now as far as the pseudo-gui profile, it's configured in "mpv.app/Contents/Resources/mpv.conf"
it can be removed or commented out, but then mpv doesn't work as an app bundle anymore and won't launch.

[sumyungguy]

Did some more digging... I hadn't realized pseudo-gui was only introduced a few months ago. You're right, its terminal=no setting does prevent the terminal output from going to the log file - and to the terminal too, if you use it from the command line: #2061

The exception is that, up until some time in November, error messages about misconfigured config file options were printed anyway, because they happened before the terminal=no took effect. Since then, that's no longer the case.

You can restore the terminal output logging by putting terminal=yes in the config file. But it has to be the first line in the file, otherwise error messages about config file options above it won't get logged. I had put it at the end of my config file, that's why I wasn't seeing the warnings.

The combination of some warnings being logged despite pseudo-gui being set in recent versions, and then not being logged despite terminal=yes in the config file in the latest version, had me a bit confused, as did the difference between the bundle app's terminal output log, and the log-file log.

Fyi, if you use --terminal=yes on the command line, you don't see config file warnings either, because it doesn't override the pseudo-gui setting until after the config file is parsed. A side-effect of pseudo-gui setting terminal=yes would be that you couldn't supress config file error messages with --terminal=no.

I still think logging should be off unless the user turns it on, but it could be made a lot more clear in the manual how to do that. On the other hand, it doesn't make sense that it should prevent output in an interactive terminal session. Given that choice, I'd agree with having terminal=yes in pseudo-gui. No idea how that would affect other platforms though.

[Cpuroast]

Location of "terminal=yes" has no impact on if it logs warnings about config file options, mine happens to also be at the very end of my config file and it correctly logs the interpolation warning when I comment out my display synch line which is close to the top of the config file.

[sumyungguy]

Your interpolation setting isn't malformed in itself, it's that it depends on another option. The check and warning about that comes from [vo/opengl] after the config file is finished being parsed. If you instead misspell "interpolation", you won't see any warnings if it's above the terminal=yes line.

If I put:

msg-level=all=warn
force-window=dummy
terminal=yes

into my config, then an empty log is generated. If I change the order to:

msg-level=all=warn
terminal=yes
force-window=dummy

then the log contains:

Invalid value for option force-window: dummy
Error parsing option force-window (option could not be parsed)
/Users/sumguy/.config/mpv/mpv.conf:94: setting option force-window='dummy' failed.

This is also true if I run mpv from the command line with --terminal=yes. Pseudo-gui overrides it during the time the config file is being parsed, up until it reads a terminal=yes line in the config file, or mpv finishes checking the config file.

If the default pseudo-gui profile was altered to set terminal=yes, it would conversely force config file error messages to be printed, despite the user or a script setting --terminal=no on the command line, or at the end of the config file.

I suppose I should open a separate issue about this...