`kew all` takes long to show UI

[vdawg-git]

When I run kew all it does play, but it takes quite a long time to load the UI.

Edit: Oh, and thank you for creating this awesome app. It looks so nice and is so good to use.

Edit: kew run with any command takes long to show the UI.

[ravachol]

Thank you!

Are you running the latest version of kew, 2.5.0? Do you have your music on a traditional hard drive or on a ssd? The extra time for "kew all" shouldn't be long because it's reusing the library structure that's in RAM, not scanning the disk again.

[vdawg-git]

Yes, I am running 2.5.0 and my files are on a SSD. Other apps read them out instantly, and kew does seem to do it too, as it starts playing basically instantly.

It is just the TUI which takes long to show. While it is loading, user input is also not registered.

[Plyply99]

I experience same thing. Running in a Arch distro container. Songs play immediately but it takes quite a few seconds before I can do anything with my system.

[ravachol]

Weird. Which terminal emulator are you guys using?

[ravachol]

And this is only when running "kew all"?

[Plyply99]

Just tried Ptyxis, Black Box and gnome terminal. All had the same pause.

And it happens even with "kew ." I only have one song in the playlist.

[ravachol]

I'm not getting a pause.

Do you get the same pause in Konsole terminal emulator, or kitty?

[Plyply99]

I did a system restart and it works fine now. Strange.

And thank you for this great program.

[ravachol]

np, thank you.

[vdawg-git]

Just tested again. So if I add any parameter after kew the UI will take long to render

Restarting does not change that

[ravachol]

Do you know if this is a new problem that wasn't there in earlier versions? Does it happen in Konsole terminal emulator?

Last version I changed the update frequency to 50ms so that people can type properly in search view. This could be too fast, and causing a delay, for some systems. But the rendering is still limited to a 100 ms frequency. Other than that I don't know, I can't seem to duplicate it.

Really appreciate it if you can help out and answer questions regarding this.

[ravachol]

I committed some changes to the develop branch. If you want you can try that, see if the problem is gone. The change is that it more cleanly doesn't do anything every other update if it's not in search view.

btw the develop branch should be as safe as the normal one, right now. There isn't a lot of stuff going on, just some minor changes.

[ravachol]

I ran a profiler and the thing taking the most time (on my computer) is drawing the cover (as it should - nothing strange with that). I wonder if you run kew and press 'c' to hide the cover, and then run "kew all", is there still a delay? what if you do the same thing with pressing 'v' (turn off the visualizer).

The big difference between kew and kew + a parameter is that the latter takes you to song view, which has a visualizer which gets redrawn often and it draws the cover.

[vdawg-git]

I tried it with both disabled visualizerEnabled=0, coverEnabled=0, but the delay is still there

How would I run a profiler? I have no experience with C

[ravachol]

Ok, cool here's a step-by-step:

1) extract kew.zip to a directory 2) edit Makefile so that -O1 is replaced with -g on the CFLAGS line. This is to create a debug enabled version of kew. 3) run "make" from the commandline within the directory 4) install valgrind 5) run: valgrind --tool=callgrind ./kew all 6) exit kew whenever the ui is reached and the delay is over. 7) run: callgrind_annotate callgrind.out.pid > analysis.txt (replace pid with the correct pid from the file that valgrind produced) 8) there will be percentages displayed in analysis.txt where time is spent. you could paste the top ones here.

A thousand thanks!

[ravachol]

alternatively, you could send the analysis.txt to : kew-music-player@proton.me

[vdawg-git]

Ive send you a mail with the file :)

Edit: The file is from the stable branch

[vdawg-git]

Wait a sec, I forgot to test the dev branch Also, I have not used earlier versions

Edit: Same problem with the dev branch

[ravachol]

Thanks!

It seems to be the flac decoding that's taking most of the time. If you let it run for awhile that would be the case of course. Flac is an expensive format, but a modern computer should be able to handle it.

Miniaudio that I'm using for decoding is not something I'm involved with.

Yeah, I would be grateful if you tried an earlier version to see if the problem was there before. Could be that I messed up somehow in this latest version.

[ravachol]

The top usage is not the decoding unless I'm playing a flac file.

Could you try kew and then as a parameter add a song that isn't a .flac: kew not-flac-song

See if you still get the pause/freeze.

[vdawg-git]

It is also happening with a .mp3

I checked out 2.0.1 and it works fine. I will try other versions too

Edit: v2.1.1 works too.

2.2 and higher fails to build with an unmodified Makefile

[ravachol]

I committed some changes to develop (changed back to 100ms update interval). Can you try that one?

[vdawg-git]

Builded with the latest dev, the delay is still there

Edit: This is not highly important, like I still use the app. So if this would take a lot of time for you, it could make sense to work on it on the future, as others could provide more data until then

[ravachol]

It's very important for me because I think this probably affects many people. And you are a godsend because most people just don't report anything.

I think I might have found the culprit actually.

Try the new commit in develop. If that one still gets stuck, I have added logging that we could use to see exactly where it gets stuck. I will just enable it in the next commit.

[vdawg-git]

It works, UI renders and inputs respond instantly now :)

[ravachol]

Nice! Caught it! Beers are on me lol! :)

Thank you!

[vdawg-git]

Aight, I'll close this then. Thank you again for your work :D