GNOME Music Should No Longer Be So Sluggish

[M@GOid]

Clementine is a very good and much faster Amarok 1.4 replacement if you're interested.

I am already using it, but not a fan. They managed to take the Amarok 1.4 interface and made it worse. BUT it works and I'm glad for that.

For faster players there is Audacious in GTK and Qmmp in QT, both maintaining the dream of XMMS alive.

[woprandi]

I am already using it, but not a fan. They managed to take the Amarok 1.4 interface and made it worse. BUT it works and I'm glad for that.

For faster players there is Audacious in GTK and Qmmp in QT, both maintaining the dream of XMMS alive.

https://gnumdk.github.io/lollypop-web/

[Chewi]

Funny, I've been working on a similar thing myself these past few days. XMMS2 doesn't get much love for some reason, even though the backend is really awesome. I guess it could do with some better clients. I've picked up a long-unmaintained client called AlbumThing and ported it to GTK+3 and Python 3. I've also made use of the new (as yet unreleased) media library query features in XMMS2 to allow it to group albums more accurately and efficiently. Unfortunately none of that has stopped the UI grinding to a halt for several seconds while it refreshes the album list. Turns out this was entirely because of the covert art and the fact that Python sucks at threading. I'm going to try the multiprocessing module and I'm looking forward to seeing vast improvements.

[starshipeleven]

There is fast directory browsing on Linux, too. Just use command line tools, you can even parallelize them if you start a parallel directory traversal for each distinct physical mount point. It's not hard if you know the 101 basics about computing.

I assume that what is slowing down players isn't directory browsing that is kinda the same for everyone, but what they do once they have found a file (read it, index it , write down their stuff)

Still, everything may feel slow, slower than in 1995 on that particular 486DX. For instance my Android phone has 128 GB of storage. I decided to store all my ripped music on the internal storage so that I can play my fav music on road trips. A big fail. I couldn't find a single Android music player that won't die when browsing the music library. They're also slow as hell and crash prone. It's a mess.

That's probably because media apps are using the system's media indexer, which is brought to its knees by so large collections of stuff.

[Chewi]

For instance my Android phone has 128 GB of storage. I decided to store all my ripped music on the internal storage so that I can play my fav music on road trips. A big fail. I couldn't find a single Android music player that won't die when browsing the music library. They're also slow as hell and crash prone. It's a mess.

I have about 16GB and even that can be too much for most players. VLC for Android did slightly better but the best option I've found is Poweramp. Unfortunately I'm facing a new issue where it crashes when album art isn't present. Maybe it's just me as it seems like a critical bug that they should have fixed by now. I'd recommend checking it out anyhow.

[Marc Driftmeyer]

Something doesnt sound right here. Im not a user of Music software so havent experienced sucg sluggishness but on modern hardware these ops should be near instantanoues.

I use it daily with access to aroud 15GB of Music and it takes tracker to update every periodically, but loads in less than 3 sec on my FX-8350 with 32GB RAM.

[Luke_Wolf]

I assume that what is slowing down players isn't directory browsing that is kinda the same for everyone, but what they do once they have found a file (read it, index it , write down their stuff)

Yeah... the issue here isn't going to be thread management, or directory traversal. it's that attempting to read from and process a zillion files at once is slow because it's pretty much the worst access pattern you could come up with.

[caligula]

Yeah, that doesn't sound right. I have a 64GB collection on an SD card and VLC is just wonderful for managing it. I'm getting a 128GB card this week and I don't expect any issue.

Ok, good to know. Thanks guys. VLC wasn't exactly the first thing I had mind for playing just music, but it's good if it works. On the PC, it isn't as nice as the real music players for managing music libraries.

[smitty3268]

Sorry, but that's still pretty stupid. Why does the app block at all just to load album art?
It should just load immediately and try loading art 1 at a time in a background thread going from top to bottom.

[grok]

Did anyone here try deadbeef for android? I'm curious if that works well. (I don't have Android on my PC yet.)

There is fast directory browsing on Linux, too. Just use command line tools, you can even parallelize them if you start a parallel directory traversal for each distinct physical mount point. It's not hard if you know the 101 basics about computing. Kodi also used to be quite slow as a music player. Browsing a single directory (10 files) took few seconds per 3 MB file. You know, from SATA SSD on i7 4770k and 16 GB of RAM.

People just accept this shit nowadays. The app generation is full of clueless idiots. I started with mp3s on my 486DX66 and Winamp, it was a step up from scream tracker modules and midi. Now people have 4 GHz octa-core setups, 64 GB of RAM and NVMe SSD. The DACs support up to 64-bit audio @ several thousands of kilohertz. Still, everything may feel slow, slower than in 1995 on that particular 486DX. For instance my Android phone has 128 GB of storage. I decided to store all my ripped music on the internal storage so that I can play my fav music on road trips. A big fail. I couldn't find a single Android music player that won't die when browsing the music library. They're also slow as hell and crash prone. It's a mess.

This bug of "let's run 1400 threads to read 1400 files" was funny. I wonder if they read files this way too : "open a file. read a byte. close the file. open the file. read a byte. close the file..."
Combine these together, you'll spawn a thread for every byte you need to read.