Feature: Local music library

[bleonard252]

This PR introduces a new setting that allows you to set zero or more "local libraries" from a directory. These do not get modified in any way, not even created if they don't exist (they're just not loaded, in that case). Closes #595 (which seems to already be supported, actually).

This is only used right now in the "Local tracks" feature. Playback, queuing, removing libraries, and album art seem to work automatically, but MPRIS metadata does not, and it uses fallback data if you attempt to look at the track, album, or artist pages for any local track, but this seems to be an issue with the existing Downloads folder too.

The PR also changes some dependencies, which I had to do to get it to build and run on my machine. Feel free to revert it, or have me revert it, if you feel it necessary.

Screenshots

[KRTirtho]

Wow, that's really great work. Thanks for the contribution.

But I'd like to suggest some changes.

Instead of having the Local Library section in Settings, we can just show the Local Folders as grid of cards/list in the "Library" > "Local Tracks" Tab. The tracks for each folder will be accessible only on that Folder's specific page.
We can have the "add local library" button there as well to add the folders users want to.

This will also need the "Local Tracks" tab to be renamed as just "Local" meaning local library.

[bleonard252]

I'm not completely sure what a grid view would look like for a local tracks list. If you are thinking about album/artist grouping, that's a taller task, and I think it would be better to integrate it into the local fields anyway, which is definitely outside the scope of this PR. (I'm thinking about setting up local track integration via Spotify ID in a future PR.)

I think I might try integrating the settings into the "local tracks" list, by grouping by source and putting the "add to library" button there, as you suggested.

[bleonard252]

One interesting side effect of this new listing mechanism is that, now, if you click play on a track (with a clear queue, not sure if that matters), it plays all the tracks from that library source only.

[KRTirtho]

Great work. This is close to what I meant and imagined.
But, instead of showing all the tracks of all the libraries together,
we can show just the Library names in the "Local Tracks" tab. It can be a ListView or a GridView of them. Kinda similar to Playlist. But, we'll utilize the FileSystem to manage/store it.
We can move the playbuttons, sort button etc. playback related actions to specific Library view page. The Library view page will List all the Tracks contained by it

One interesting side effect of this new listing mechanism is that, now, if you click play on a track (with a clear queue, not sure if that matters), it plays all the tracks from that library source only.

Do you mean it doesn't play any other online tracks if we add them to the Queue later?

[KRTirtho]

We actually only merge PRs in to the dev branch. But, you were targetting master branch. So some conflicts arose after changing the target branch

spotube/CONTRIBUTION.md

Line 148 in a9ad7c7

Do debugging/testing/build etc then submit to us with PR against the development branch (dev) & we'll review your code

[bleonard252]

Do you mean it doesn't play any other online tracks if we add them to the Queue later?

It does. It doesn't add the other listed sources to the queue, though. I guess if I rework it into multiple pages, this becomes intended behavior :)

We actually only merge PRs in to the dev branch

Oops I must have missed that. That makes sense. I'll rebase and solve the conflict, and then start trying to rework it into multiple pages, like you asked. I still don't think a grid view makes sense, since I'd have to figure out what image shows up on it, so it'll still be a list, but I'll revert it back to a simple ListView and just list the libraries there. (This will look silly to anyone with just Downloads set, by the way.)

[bleonard252]

The force-push was from rebasing the branch upon dev. Here's what it looks like now:

[KRTirtho]

This is close to perfect. Later, I guess we can use the Album art of the first 4 songs of the library as the image for the GridView's items.

For now I think is acceptable. I can always redo the UI for better UX later.

[KRTirtho]

Sorry for the delay, I thought I merged this PR.

[vico93]

Well, just saw this PR just now - after reinstalling 3.7.0 - don't know if this PR here (or another brand new issue) would be the proper place, but i just want to throw my two cents as the final user:

• First of all, thanks for this effort to bring local playback as a feature. I'm in this cruzade to find a better alternative to the good ol'Windows Media Player (Legacy) since i migrated to Windows 10 and started seeing the growing issues with WMP from all those years (things like Discord integration, possibility to integrate with online libraries like Spotube does).
• Well, the first thing i noticed was that, apparently, you guys decided to keep the local files separate of the online stuff in the UI; although i understand that comparing the metadata of each .mp3/.m4a/.flac/etc file locally to the online database to make them appear as one would be hellish, i was aiming to see really an "integrated" flow, where when i try to reproduce a song it would first check if a file on the disk has the same metadata and then play it instead of downloading from the online source - or appear as unavailable if the user is offline, that is the default behavior for the official Spotify app. From that i understood, this isn't the behavior implemented, resorting to us to search around the desired song in a linear list of songs (that isn't even separated by albums and such). This really sucks, to be honest.
• Also, at least on my end (Windows 11 x64, 32GB of RAM), trying to play a local song freezes the entire app for a couple of time, and when the song starts to play the app gets very slow, a couple of times i tried i needed to kill the Spotube process on Task Manager.

if i was to suggest a different way to achieve that "seamless" local file seeking, would be actually adding a separate option on the audio source options (or even a checkbox immediately below) with something in the lines of "prioritize song files already existing in the local Music folder". When adding the local Music folder spotube should scan the folder (and its subdirectories, that was the missing thing from the already extant Downloads folder that made me to create #595) and create a internal "database" containing the song metadata and the file path on disk. And when the user tries to play a song, it would first seek if something with that metadata exists on the local database and, if positive, would play it instead of trying to resort to Youtube/Piped/Jiosaavn.