@Jellby said in Continuous Buffering:

@rlkeeney said in Continuous Buffering:

As a retired Linux/Unix Systems Programmer, I have extensive experience with Linux.

Perhaps at this point what remains in biting the bullet, compiling your own Strawberry build and trying to debug with it.

It might be a good idea if there were time available. However, it only takes two mouse clicks to restart, so it is not worth the effort at this time.

If I may make a suggestion, why not make things easier on yourself and put covers (ie. folder.jpg) inside each music folder? In my experience of using many different audio players, I've found that to be a far better solution than relying on embedded artwork. It also has the additional benefit of displaying folder thumbnails in file managers, if you use something like Dolphin or Thunar. If interested, you can batch process your entire music library in one step with Musicbrainz Picard, by selecting the option "save cover images as separate files" and then saving.

@sardior (Sorry, I'm an incurable pedant - not being rude!) Fyi, all audio formats (bar 'raw') are encoded (even stuff like FLAC). M4P files are encrypted - that's the issue (with Strawberry).

Kind Regards, Jon

@henk
The startup could be slower because of the way Strawberry initializes objects earlier at startup, I fixed bugs and even rewrote many parts of the code where Clementine did things unsafe thread-wise, ie.: reading and modifying GUI things from a another thread than the main thread, which will be faster, but it's broken code, and just a coincidence that it doesn't crash.
One thing you can try is to turn off "Grey out unavailable songs in playlist on startup" in Settings / Playlist, this feature will lag the startup significantly.

Strawberry has a little delay at the beginning of the scan, it's because it iterates through the directories to find the number of files for the progress % status.
Clementine calculates the progress only based on the number of directories, which makes the progress inaccurate, and often stuck on 97-99% for a long time.
Other than that, then scan speed should be pretty much identical.

I think it would look like this:

{Disc %disc/}

@ruinspc IIRC you fix this on a per-tracks basis by unclicking "compilation" in the track's properties. Or similar option.

FYI https://github.com/strawberrymusicplayer/strawberry/pull/1837

On Linux Mint 22.2, there is Settings > User interface > Appearance > Style: gtk, which enables dark theme (I think I installed it via apt install strawberry instead of downloading deb file from website).

On Mint 21, there's no such option, I think I'll just wait until I need to upgrade this Mint installation. I'm avoiding the flatpak distribution since it's non-official.

@iceman @iceman I did not use itunes to create my m3u playlists but an android player called Musicolet and receive the exact same message on Linux Mint. However it won't play one song despite them all being in my library. I installed from the Linux Mint store as well.

I'm on Linux Mint Cinnamon 22.2 Zara. The following config just worked for me:

Tools > Settings... > User interface > Appearance > Style > Style: gtk2

e3ad7a0f-cf8e-4447-b1dc-4295e65e47aa-image.png

@itunes-refuge I actually found a workaround for this a while back, which I explained here: https://forum.strawberrymusicplayer.org/post/3567

@jonas any thoughts about this one chap? Super weird, I can't conceive what the issue might be, unless "2024.10.30" somehow compiles to the same hex code as M, or some other completely unexpected, arcane, but technically logical reason.