search

ravachol / kew

A command-line music player
GNU General Public License v2.0
567 stars 21 forks source link

BUG: Does not use correct album art. #102

Closed xplshn closed 8 months ago

xplshn commented 9 months ago

Screenshot_2023-12-03_09-03-50 Screenshot_2023-12-03_09-05-02 Follow up of the old bug report. I compiled this commit: c766373a7825a5ba385166b411c327319a32f784 - "improved settings file"

xplshn commented 9 months ago

One terminal is xfce4-terminal, the other wezterm so, the problem remains, and the behavior is the same for normal images or blocky unicode ones.

ravachol commented 9 months ago

Is that cover from a png in the directory? or embedded in the file? Are both audio files in the same directory?

ravachol commented 9 months ago

It looks to me like you have two files with no embedded metadata or cover. The cover is taken from the directory those files reside in, which is how kew behaves. If it can't find an embedded cover, it takes the largest image file in the directory and uses that as cover. This is the intended behavior.

I don't really know how to solve this without losing the ability to show covers for albums where the cover is an image in the directory and not embedded in the files.

ravachol commented 9 months ago

Maybe it could ignore loose covers if there's no metadata...hmm.

xplshn commented 8 months ago

SOrry to answer this late, the files have the metadata and thumbnail embedded.

ravachol commented 8 months ago

Ok, what file type/extension is it on the song showing the wrong cover? does this happen every time or is it a something rare? It still looks to me like no metadata is detected, because there's no album name artist name, year. Is there an image in the folder those files reside in?

xplshn commented 8 months ago

It happens everytime, the files are Opus. I haven't tried with other formats, I only use Opus. The only thing on that folder is the songs themselves(*.opus).

ravachol commented 8 months ago

I'll look into it, thanks!

ravachol commented 8 months ago

This happened to me when I tried, but it was because the cover was there in the folder. When I removed it the file correctly showed no cover, or a cover only if it was embedded.

So I wasn't able to reproduce this.

ravachol commented 8 months ago

Tempted to close this because I cannot reproduce it. Are there any other files (in other directories) to which this happens or is it just this one?

xplshn commented 8 months ago

There are only *.opus files, I will rebuild now, I forgot... I will report back once I do, thanks!

ravachol commented 8 months ago

Think I might have found the issue. The random number generator might have been producing the same image filename twice. this would lead to the behavior you describe. I made some changes to that. If you grab the latest commit.

xplshn commented 8 months ago

Now it does not show anything. Just compiled and works, but does not show the ASCII art. bugreport.txt

ravachol commented 8 months ago

not sure I understand. you can't get it to show any covers?

xplshn commented 8 months ago

Yes, indeed, sorry. I can be a mess sometimes. The bugreport.txt contains a script(1) file, it can be read using cat. The player did not show the thumbnails, even though they were embeded

xplshn commented 8 months ago

Hey! It works! I disabled that -relro flag and it automagically worked!

xplshn commented 8 months ago

I compiled with gcc this time, when I changed to clang it worked! Could it be because of Musl and GCC not playing well with each other? zig cc + mold as linker(my preferred setup) worked fine too this time

ravachol commented 8 months ago

cool, do the images display correctly now?

xplshn commented 8 months ago

Yes, tried with wezterm, ascii art works, block art works too.

ravachol commented 8 months ago

nice. thanks for taking your time and work with me.