mpvpaper hanging on startup

[ddxtanx]

The moment I try to run anything other than mpvpaper --help it just hangs with no output at all. It is doing some form of computation, as it is using 100% of one of my cores. Even if I try verbosely running it with mpvpaper -pv '*' [small gif] there is no output and 100% usage on a core. This happens when using mpvpaper from the Arch repos, mpvpaper-git from the AUR, and manually building from this repo. Is there any kind of log or output I can upload here for better debugging?

[GhostNaN]

So even with -v arg there's no output at all? Are you sure you aren't passing -f or --fork by accident? At a minimum it should of said "Verbose Level 1 enabled"

Just to be sure this isn't a mpv issue, try running: mpvpaper -v -o "--log-file=output.txt" "*" [small gif] And report back with the log.

[ddxtanx]

Even with that command, mpvpaper outputs nothing, and nothing is written to output.txt somehow... . I interrupted after ~10 seconds

[GhostNaN]

The only way that could happen is if mpvpaper caught either SIGINT, SIGQUIT or SIGTERM while starting up. And I have no idea so far how or why that's possible. But it must be happening while parsing the args inparse_command_line()

What kind of PC do you have? OS? Hardware? DE?

[ddxtanx]

I'm currently running the Arch version of Asahi Linux on an M1 Macbook Pro, and I'm using Wayland, wlroots compositor, sway window manager.

[GhostNaN]

M1 Macbook Pro? Didn't even know that could work on Wayland.

Did you try something other than a GIF or tried running in just the normal MPV player?

[ddxtanx]

I've tried an MP4, PNG, and JPEG as well all with the same weird hanging error. mpv is able to open all of those media types just fine, though it does complain about

[vo/gpu/opengl] after rendering: OpenGL error INVALID_ENUM.
[vo/gpu/opengl] after OSD rendering: OpenGL error INVALID_ENUM.

a couple of times. Running mpvpaper -v -o "--log-file=output.txt" "*" [file] also successfully creates an output.txt which I've attached to this reply. output.txt

Also while Asahi is a lil' buggy, the experience is still really nice. Highly recommend.

[GhostNaN]

I just realized you caused the SIGINT when you put in ctrl+c, my bad. So that makes sense. But hanging at the start is still very bizarre behavior. We are in unknown territory because this is an Apple ARM SOC. After doing very light digging I found this: https://github.com/AsahiLinux/docs/wiki/Broken-Software It shows there is some limitations for this kind of hardware and I'm not sure what it's getting snagged on.

It could be even getting stuck just outputting the error. But that could be tested by just trying to passing -l asdf and seeing if it responds back.

And again, it's breaking while just parsing the args. So who knows what else it would break if that problem is even fixable.

If you want to get your hands dirty to see if this is even possible to fix. You could try going step by step with gdb in your favorite debugger and seeing where it's going wrong. Otherwise, I'm not quite sure how to proceed and am open to suggestions.

[GhostNaN]

Wait, it just got OpenGL 2.1 support? https://asahilinux.org/2022/12/gpu-drivers-now-in-asahi-linux/ So it doesn't even have OpenGL 3.0 or higher support? That's rough. That would definitely make this a lot harder to work with.

[ddxtanx]

Thankfully it was a small error that most likely came from how different systems store chars. I introduced a fix in #49

[GhostNaN]

Huh, just like that? Is it completely working now?

[ddxtanx]

Yep! 100% working and even functioning in tandem with swaylock-plugin!

[GhostNaN]

I'm constantly humbled by others, thanks. I'll look over your pull and make sure it does have any side effects.

[GhostNaN]

So.... now I'm having this issue. I'll look into replacing this getopt_long() system.

[ddxtanx]

Welp that’s not good. Let me see if treating the opt as an int works; if it does then a direct comparison with -1 ought to do the trick for all systems

[GhostNaN]

Read the MAN: https://linux.die.net/man/3/getopt_long

[ddxtanx]

Yeah, changing the type to an int still works on my system. Then since getopt_long returns (int)-1 when all options are processed this ought to work on your system as well

[GhostNaN]

I should've read the man page myself. Turns out they use int for opt as well. Funny how simple problems can be. I'm pulling the request and closing the issue.

Thanks again.

[ddxtanx]

Happy to help!😄

[GhostNaN]

I just fully realized what when wrong, if you are curious. This was a classic case of integer overflow. When getopt_long() returned -1 to the char for some reason on most systems it just handles it. Probably because it's treated like a signed int. But on yours it's like a unsigned int so it overflowed back to 255. Hence why setting to 255 worked on your system. Just some food for thought.