-
-
Notifications
You must be signed in to change notification settings - Fork 163
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] Tracks displaying wrong embedded artworks #494
Comments
thats expected behaviour since artworks are saved based on their filename, u can change that by enabling "group artworks by album" and maybe specify "album identifiers"
exactly as u pre assumed, except that i didnt like this as default, since tags can be changed more than filename + for me atleast i have some music with similar tags (nightcore/sped up/slowed/etc), i guess "group artworks by album" would do it for ya, or i guess u should name ur files properly like for example "[track] artist - title (album)", lemme know if i missed smth or if u disagree |
Noted, thank you!
"group artworks by album" solves my original issue but instead creates another. This is a bit of an edge case but this setting doesn't take into account tracks with separate embedded artworks in the same album (presumably by design). I have a few tagged albums where the songs within each have their own different embedded artwork, however with this setting enabled it just uses a random artwork from a song in the album for all the songs in the album. If you'd prefer to keep the naming schema the same for cached artworks, your idea of naming my files more appropriately will suffice, thank you for the suggestion! |
thats not edge case i guess, it was requested on discord few days ago, i might or might not look into implementing it (tho it would be pain so idk yet)
the only solutions we have:
|
Guess I'm not alone then haha.
Could you use file hashes instead i.e you name the cache files with part or all of the hash of a file? How big of a performance hit would there be to calculate file hashes based on files? Maybe you could create the hashes using just the metadata of a track instead? The above is just an idea, not sure of its potential problems or performance implications.
This is pittifully easy for me, don't worry! I use a tool called Tagger which makes bulk metadata editing a breeze. |
thats what i was refering to, but a hash for file path not the file itself
thats the same but file path would be better
yah its actually used by most players, i just didnt want the overhead of hashing all the time.. or maybe we can hash once and save it with the track details, that could be better but one more reason i used clear names for the file is to easily access them without being tied/hidden to the track file only, for example i can go to artworks folder and know which artwork is for which track etc
thats cool, it looks awesome i will use it for windows. the one i sent u is for android too so we have both options ^^ |
If there are two or more files that share the same name and they have embedded artwork, all files with the same name will use the artwork of one of the identically named files instead of their respective embedded artwork. I believe this only relates to files with embedded artwork and not folders with "cover" or "folder" images in them, although I have not verified this. This issue is present on three different android devices I have used.
Expected Behavior
Each track should display its respective embedded artwork.
Current Behavior
If I have 3 files called "Song", (referred to as Song 1, 2 and 3 for explanation), each with different artwork, tracks "Song" 2 and "Song" 3 will instead display the artwork of "Song" 1. The incorrect artwork will also be displayed in the media player notification.
Steps to Reproduce
Screenshots
screen-20250211-002642.mp4
The above video shows the problem clearly. You can see the correct artwork for the track is displayed when you open the "edit tags" menu.
Logs
Possible Solution
I would presume cached artwork files are named after the respective file name that the artwork is associated with. When caching artworks (assuming my presumption is correct, I haven't read the code myself), naming them with the schema {title}{artist}{album} would prevent these conflicts in the future.
The text was updated successfully, but these errors were encountered: