Closed xplshn closed 6 months ago
Anyways: Footnote: Kew is excellent, hasn't failed me (yet), it is not bloated (yet), and you should continue to love what you do, so if it is a hassle to address the warnings Clang, or Mold, or LLVM based Linkers like Zig's ld yield, its completely understandable the: "Close as not planned" button.
Also, I just had the thought that maybe there is a bug in Mold..? Because instead of ignoring Linker flags, which is what Clang did, it did not say anything about relro and its the linker's fault that relro does not work..? I am not sure.
Thank you! Glad you like kew! There's still work to be done to stabilize it though. Version 2.2 has a lot of improvements in that area but clearly not enough.
I'm going to try and remove the warnings with clang and gcc/mold.
I committed a fix for this but there is still one warning related to ffmpeg. they have deprecated a variable but the alternative isn't in yet (only avaiiable in devel releases). So when removing the warning the github build fails.
So, you use ffmpeg to transcode the formats to wav and then play that with miniaudio? Or how does the process work?
FFmpeg is used for decoding m4a, the other formats are covered by miniaudio itself (together with libopus and libvorbis).
I found some rather serious bugs:
I will explain every image: First image is how it looks after I toggle "i" in the library. Second is for comparison. Third is a weird bug where F4 opens the F5 keys menu, but if you touch F4 again it will display the track info, except messed up. Also, F5 responds the same way.
This one was compiled with the default makefile, except for using Clang, which raises more warnings than GCC. I will test with the defaults and see if I can be of any help :)
Also, I am using Clang because after playing some songs the binary I compiled with GCC gives me a Segfault error. I've never used debug builds, much less GDB, but if you are willing to instruct me what to do I will try my best to help.
Also, do you want me to send you the binaries? Doubt they are of any help but I have two Kews, one is kew.gcc and the other kew.clang
Thanks for helping out.
First two images, these are two different modes. You either derive your colors from the album cover (gray if there is no album playing) or from the default terminal colors as specified in your terminal settings. You can switch between them by pressing 'I'. The coloring needs a bit of work though. The album color mode for instance just sets the same color for everything.
About the third, what terminal emulator are you using? And does this happen every time or on some rare occasion?
No need to send the binaries.
To run a debug build you can compile it with switch -g and run that in vscode for instance and see where it crashes.
if it is certain songs that gives you the error, I am interested in getting a hold of a song like that. is it opus?
If it's possible, you could run ffprobe 'songname' and send the results to kew-music-player@proton.me.
Yes, I surely will right now. Will send thing through email.
About the third, what terminal emulator are you using? And does this happen every time or on some rare occasion?
I am using Wezterm as is, except I set my color scheme to be "Monokai", also, yes, it did happen most times, I even got some segfaults with the gcc compiled binary, they were less frequent on the clang compiled one.
Sent you an email. One thing I left out in the email was that I also committed a fix for what could be the segfault you are getting on switching tracks. Please let me know if the issue persists, even with the latest fix.
Ah, thanks! I will now compile and see if the issue persists
Great, I just compiled, I will report any errors that I encounter.
~/Documents/kew @ ls -sh kew.*
1.0M kew.clang 48.7M kew.clang.blob 948.0K kew.gcc 48.6M kew.gcc.blob 4.2M kew.zigcc 50.1M kew.zigcc.blob
~/Documents/kew @
Welp, seems that the issue is not yet resolved. GCC crashed many times, Clang too, the issue was kind of random. I did not yet try the zigcc binary
Could you @ravachol try compiling against netbsd-curses? Could it really be related to that? I haven't tried if Kew works on my netbsd install, but, I use netbsd-curse in my Alpine install, so...
Here's the netbsd-curses repo: https://github.com/sabotage-linux/netbsd-curses?tab=readme-ov-file
don't really know if I'm following. I don't use curses.
I ran kew for I think it was 16 hours doing almost everything you can do. No crash.
Not that that is particularly impressive, but just to compare to your experience.
Oh, thought it might be because of that., Then, it seems we both are at a loss, I don't know Kew's codebase well enough to be of much help
Might it be because Alpine uses Musl, which is way more strict than Glibc? I will uninstall gcompat and see if Kew runs without it.
(gcompat is a library that adds symbols that Musl refuses to implement because they are not compliant with standards, or should not work yet they do and people use them)
Nope, still works..? The crashes are random., But always at the end of a track
Sometimes I can play various tracks before it crashes
the help I need the most is with testing. Because most features are in I'm looking at bug fixing now. I think you could be of great help, actually.
Nope, still works..? The crashes are random., But always at the end of a track
hmm and you did grab the latest commit? https://github.com/ravachol/kew/archive/refs/heads/main.zip
Might be something with your setup glibc / musl, but as it happens at the end of the song I think the problem is probably with kew.
This is a standard install of Alpine, I uninstalled gcompat. Netbsd-curses is the only "weird" thing on my system. Alpine uses musl as its default, so the compilation should have failed if the problem were Musl.
Maybe you are relying on the output of a Curses cli tool to determine terminal size, etc?
nope.
but are you getting more crashes than before?
Yes, kew does not rely on curses at all, I checked term.h, term.c.... Then I really don't know
but are you getting more crashes than before?
Yes, more than before, somehow
Do you by any chance have Telegram? Are you wiling to debug now, and there? For a more seamless conversation.
Sent you an email.
I answered both already., Could add the "Needs help" tag to this issue and leave it open as "Constantly Segfaults in Alpine Linux"
or we could set it as "good first issue".
Yes, that is a good option too. I am now compiling the latest commit.
This time instead of a segfault it froze, I can't select any other song. Or do anything at all. Will have to kill the process from another tab.
Also, I have herbe installed in my PC, its my notifications apps., When I pressed F4, instead of the artwork showing up I had it show that notification, also I realized that it freezes after it starts playback, and not after it stops., I can't even quit. None of the keybinds work.
I just sent an email containing my music folder, could you check with your kew installation if the problem is parsing the metadata?
I don't think my email provider allows that, in any case I didn't receive an email.
I fixed the notify-send issue! Sorry! It had to do with configuration! I am now playing back some music to see if it works as expected now. Deeply sorry!
Sorry for the trouble, thanks for the fix. If it crashed we can reopen the issue again ; If you want me to test things you can contact me, I will send you my main email so that I actually get notifications when you do. Thanks! Also I love that you keep the project very professional, well presented and all.
wait :) configuration?
Well, not a config, a wrapper script around herbe called notify-send that I made and forgot long ago, it was for use with another program.
I found the bug. it was essentially a typo that lead to memory being freed twice, hence the crash.
Ah, I see. I will compile when I get home.
I just had Kew crash on me when playing Music, it was from a directory with more files, it should have started to play the next song instead of crashing. The files contain metadata and are in .opus format. I tested both GCC & Clang.