v1.1.0

[Losses]

We're excited to announce the latest update to Rune, bringing significant improvements to stability, performance, and user experience.

New Features

• Introduced lyrics display functionality
• Added support for multiple scrobbling services including Last.fm, MusicBrainz, and Libre.fm
• Added Nise Japanese language localization
• Enhanced file handling with drag-and-drop support and keyboard shortcut (Ctrl+O) for opening external files

Improvements

• Improved randomization algorithm for the cover art wall display
• Enhanced image rendering quality with high-quality filter settings
• Optimized analysis performance for better overall responsiveness
• Traditional Chinese language option has been promoted from experimental status to stable

Bug Fixes

• Fixed playback mode switching issues when insufficient modes were enabled
• Resolved navigation back text clickability problems
• Fixed metadata display issues for blank cover art on the lyrics page
• Corrected window dragging behavior that was triggering unwanted navigation actions
• Fixed tray icon functionality in Flatpak installations
• Resolved navigation bar issues that were causing program crashes due to multiple event triggers

Technical Changes

• Removed GPU FFT implementation due to stability concerns

We're constantly working to improve Rune and appreciate your continued support and feedback. Thank you for using Rune Music Player!

---

This discussion was created from the release v1.1.0.

[mncho]

@Losses Hello, sorry if it is a bother, the Rune music player is really nice, but this one is having one major issue with it, which is that seemingly randomly, Rune is not displaying any art at all, for about half of the library. Other audio players seem to display the art with no problem, but Rune does not display any art for these at all. After reimporting twice, the issue does not go away. Does Rune have some kind of issue with certain types of format of embedded art, so is it an issue on this one's end, or is this unknown?

Thank you.

[Losses]

@mncho Thank you for your feedback. I hope you can provide more detailed information, such as whether the cover art is embedded within the files or stored as Coverart.png in the folder. The latter is only supported from version 1.1 onwards. Additionally, is there any pattern to the files that are causing issues, such as their format?

[mncho]

@Losses You are very welcome. All of the files have cover art embedded, as this one makes usage of a program that automatically embeds the art if it exists as well as tags it. Many of the folders do have an albumart.png, as well as embedded art, but there is no pattern if the ones with albumart.png have art or not, or vice-versa. The files are all FLAC format, or Opus format, though some of the FLAC were ripped quite a while ago, so perhaps there is some kind of update this one has missed? The Opus files seemed to not import at all (which, makes sense if it has no Opus support which was assumed, it is disappointing but it's fine since this one can wait and use a different player in the meantime), so the only files in the player library are FLAC.

[Losses]

@mncho Thank you for the reply, let's sort out these issues one by one.

1. Currently, the supported folder cover file names are only cover.png/jpg/jpeg and folder.png/jpg/jpeg. "Albumart" doesn't seem to be a commonly used name. If you can provide some references supporting this practice, I will consider adding support for this file name in the next version.
2. Regarding the issue with "Opus" files not importing, let's clarify which container the Opus is in. What is the file extension? As far as I know, both CAF and OGG containers can contain Opus encoding, and Opus itself can also be a file extension.
3. For files that can't be imported, my guess is it might be related to file encoding. If there are decoding failures during import, the Logs in the Settings interface will store all decoding failure records. You might find some clues there.
4. I would greatly appreciate it if you could provide a sample file.

[mncho]

@Losses
Thank you for your response yet again... Apologies for the long wait on a reply.

1. Honestly, it should just be allowed for users to input their own string to gather album art while importing music. While a lot of the time, people might use cover.png, or folder.png, for example (though, this one only thinks folder.png is made by musicbee in all the programs it has used), the default on beets is "albumart.png" for album artwork fetched, and a lot of people use beets for library management, so you see this kind of artwork name a lot in libraries. But also, this one has seen coverart.png, front.png, and etc., on a lot of libraries on a program like soulseek for instance. Maybe there should be a default, but it being just forced presets is quite bad. It can turn people off from your music player, as most people with large libraries (like this one) who have thousands of albums, or perhaps even small libraries, will not want to rename every single cover art file to the strict format, should the situation come that they don't have one of those two strict option.
2. All opus files are .opus, the container for all the audio, would be OGG.
3. The logs seem to only contain ~20 logs related to .flac files, and most of them seem to be an issue with parsing .flac files metadata, but the songs still seem to be in the library. Besides that, there is no acknowledgement at all of the .opus files, or any issue related to artwork.
4. Here is an opus file from the library: https://files.mintchoco.lat/u/fMMnkj.opus Here is a FLAC file: https://files.mintchoco.lat/u/g59sia.flac