Wishlist: ability to ignore folders or tracks

[csolisr]

As of yet, Vanilla adds all the content of the SD card to its playlist, including ringtones and podcasts, which I wouldn't like to hear during a music session. The "Filebrowser home" has no effect on the library's behavior. Please allow the user to select which folders will be added to the library.

[adrian-bl]

VanillaMusic uses the Library provided by the android system - wouldn't it be simpler to add a '.nomedia' file to such directories? This will instruct the mediascanner to skip a directory and the tracks would not show up in any music player that makes use of the global music library.

[mleduque]

I think .nomedia is a bit like arcane magic. It may be documented here and in android dev doc, but for the casual user like me it's not obvious and will require somme googling (which may not be what you want to do when your music player decides to grab somme music form some place you didn't expect).

[adrian-bl]

I agree that .nomedia is not nice for the average user, but i wonder if the blacklist is really such a good option. Maybe a whitelist would make more sense:

-> The default would be to show everything from the Media Database (as it is now) -> But the user would have an option to make Vanilla Music only include music in specific folders

..or maybe a simple config option such as 'Only handle files in /sdcard/Music' would already be enough?

[mleduque]

I agree that a whitelist would be better that a blacklist for this.

[K-RAD]

any update on this whitelist feature? i've been trying to look into it, but for the gods, i can't figure out where the system does the main scanning and indexing of the songs

[adrian-bl]

-> Closing all open bugs as vanilla was removed from the play store by some DMCA-Troll, see: https://plus.google.com/115564237657785223556/posts/TvY1PD4ci2N

[mase76]

I also agree with the whitelist feature. A .nomedia file in the ringtones folder would make the ringtones not be selectable any more in the Android system. There are so many (app) folders, that can contain media files. Adding .nomedia files to all of them is too much effort.

[xbao]

I've been looking at implementing this by restricting the ContentProvider query with something like:

    selection.append("_data LIKE '%/Music/%'");

This works fine for the songs queries, but doesn't work at all for the artist/album queries as they don't have the _data field. This means the artists/albums of non-whitelisted audio files show up in the artist/album lists and pressing on them gives an empty song list.

Not sure there's a good solution with this approach, unless there's some way to exclude artists/albums that have no tracks in the whitelisted folders.

[adrian-bl]

Not sure there's a good solution with this approach, unless there's some way to exclude artists/albums that have no tracks in the whitelisted folders.

We probably would have to do some JOINs on album + artist queries. Not sure how pretty this will end (i did some MAJOR hackery to fix the genre support: The gene support is now done using some sql injection. whee.)

[xbao]

I hacked up a (relatively) simple implementation, you can see it at https://github.com/xbao/vanilla/commit/ecc4dd873d59d2e67b2529548471f438d10c448b. It's still a work in progress, not configurable, bit of grossness etc but a good starting point I think.

I ended up just changing all of the calls to be generic media calls, masquerading the id as the specific query's id (e.g. artist_id AS _id) and applying DISTINCT to remove duplicates.

At first I thought of JOIN'ing all the tables. I still like that approach: it's way more flexible, gives us SQLite statements that actually make sense and is something we should probably look at doing. I doubt the tables are doing to change drastically, see MediaProvider.java for the ridiculous hoops being jumped through to maintain backwards compatibility and how generally messy the whole thing is. I would be surprised if the Android team would see the benefit as outweighing the cost of any major schema change.

Testing/feedback/improvements etc are of course always welcome (my sdcard just broke so I was limited in my test cases). At a higher level, I worry a little as this is a hack that is hacked into another hack (the genre one). It might be time to start thinking about some way to cleanly separate these things out so that they don't conflict with one another.

[xbao]

Cleaned up version is at https://github.com/xbao/vanilla/tree/feature/22-library-whitelist.

As it is, the interaction with preferences leaves much to be desired. In particular:

• Only allows one folder to be specified (even though the logic in the adapter works with an arbitrary number)
• doesn't have an explicit way to clear the filter

Feedback please!

[adrian-bl]

Thanks for your patch - but somehow i do not have a good feeling about this. I think that this approach will end up in too much hacking around: There are, IMO, too many corner cases that might break:

Eg: isSongAvailable() does it's own query and might return true even if everything is blacklisted, same goes for randomSong() and queryAllSongs. (And there are probably more)

Given the abysmal state of androids media scanner: Maybe it wouldn't be such a bad idea to just implement our own media store database :-/

[refi64]

Given the abysmal state of androids media scanner: Maybe it wouldn't be such a bad idea to just implement our own media store database :-/

Which would probably fix the colon bug and the stupid sorting issue I've come across, right?

[adrian-bl]

Which would probably fix the colon bug and the stupid sorting issue I've come across, right?

No: The colon bug is a bug of the mediaserver itself. What sorting issue are you referring to?

@xbao I started to think about a different (and hopefully cleaner (?)) approach: What would be your opinion on an id-based blacklist for each MediaAdapter?

eg: Each instance of an MediaAdapter builds its own _id blacklist while it gets created. (-> The Albums Adapter would build an array of id's with hidden album id's (= albums which only contain non-whitelisted songs)). This would simplify the SQL trickery we have to do as buildQuery could simply append the blacklist to the query via: 'AND _id NOT IN ($blacklist)'

[refi64]

What sorting issue are you referring to?

It was an issue where all songs I downloaded after I upgraded to Android M were put above the ones from before, even though the sort option was set to alphabetical. I had assumed it was another Android media issue. It magically corrected itself after I downloaded a media scanner and ran it about 3 times.

[adrian-bl]

I just had a look at the id-blacklist and it would turn out to be the same mess :-/

But is this actually still such a much needed feature? At least Android 5 does not add Notification + Ringtone sounds to the music library.

It was an issue where all songs I downloaded after I upgraded to Android M were put above the ones from before, even though the sort option was set to alphabetical. I had assumed it was another Android media issue. It magically corrected itself after I downloaded a media scanner and ran it about 3 times.

Androids media database provides a sort key (eg: to get the sorting with 'The' right), looks like the update messed this up, so clearly an android bug.

[mase76]

Why using android's database at all? Why not implemenring an own one?

[adrian-bl]

Because this would be a colossal amount of work and can hardly be justified. Androids media database has its quirks but it's not that bad - it also offers some nice features which a non-system app/implementation cant provide (graceful handling of varnishing external storage devices, getting notified on new downloads, etc)

[ghost]

Varnishing?

Do you mean vanishing??

[xbao]

Yeah, I don't know if anybody still wants this. Maybe close it and people can chime in if they feel the need?

The approach I used makes me uneasy too, glad you feel the same. I'll leave it there for future reference.

I just had a look at the id-blacklist and it would turn out to be the same mess :-/

That's a shame, it did sound like a feasible approach.

Because this would be a colossal amount of work and can hardly be justified.

Yeah, there's so many things that would need to be taken into account, even ignoring the (not trivial) work of designing the schema and populating the database. Just off the top of my head

• Loading interface/user-flow while building the library
• Error handling and reporting these to the user
• Mounting/unmounting of devices (as mentioned above. Presumably you weren't talking about lacquering microSD cards :) )
• File creation/deletion/modification
• Integration with the existing provider (likely with many of the same issues we have now with it)

I think many users like Vanilla because it's snappy and stable, so any changes that might compromise either of those two qualities should be looked at critically.

[privacy-wolf]

I really (could) love the vanilla app, however the one showstopper issue is that the music lists are completely messed up with audio-files not being music files at all (like hundreds of podcasts, audio-books, etc.).

So whitelisting the music directories is a must for me so vanilla music becomes useable for me. Looking forward to get it (as I really like all the rest and would like to switch over)!

[adrian-bl]

This feature will come sooner or later: the biggest amount of work (our own media database) is already done.

But in the meantime you can always exclude directories by placing a '.nomedia' file in folders you dont want to have scanned

[PanderMusubi]

This is also a security risk or a risk of embarrassment when randomly playing all tracks will also play voice messages received with instant messaging apps such as WhatsApp. Please increase the priority of this issue.

[adrian-bl]

First: If you consider this a security risk, you should complain to WhatsApp and tell them to stop storing your highly sensitive data in a public storage area of your device.

Second: The only way to 'increase the priority of this issue' for you, me and everyone else is to submit a patch which implements this functionality.

[PanderMusubi]

On 1) adding a .nomedia file took a whle before it had effect. So eventually I fixed it for me, but many non-technical users will have a more difficult or impossible task doing this.

[adrian-bl]

It took my only almost 4 years, but support to select (and exclude!) directories is now a thing:

See Preferences -> Media Library -> Edit

[utack]

Thanks for implementing this
Quick question: Any way to exclude the entire /storage/emulated/0/ path, so only the external sdcard is used?

[adrian-bl]

Yes: just set /storage/emulated/0 to 'neutral' and mark /storage/sdcard1 as 'included'

[utack]

Sorry I was not very clear with my report The problem is: I do not see a folder "0" when going up from the internal sdcard path, where one should be. "Failed to display"

So I can not exclude it Running a custom ROM here, but that should be pretty much the same on all Android devices

[adrian-bl]

Ah, thats indeed an issue on Android > 5.

Hmm... Maybe we should have a context menu to unselect all directories or make the textview displaying the current directory part of the listview..

[adrian-bl]

@utack this should be fixed in the latest nightly APK with commit https://github.com/vanilla-music/vanilla/commit/848dba0abce1f78d387ac4ca8c4377d71ecad21f:

We are now pretending that the default storage directory (0) always exists

[oliver]

So I guess this issue is the reason why VM suddenly wouldn't play any songs any more... My music is mostly stored on an external MicroSD card, which probably was not included in the standard search list. Frustratingly the songs were still displayed in VM and in its play list as usual, but tapping the Play button just didn't do anything.

Even rebooting or reinstalling VM or rescanning the media library (with SD Scanner) didn't help. Only after looking through the settings I noticed the inclusion/exclusion list. After adding the SD card to the list, VM again worked fine.

It would be nice if VM would either give a hint when trying to play a song that's not in the inclusion list, or would outright not display these songs (that might point users into the right direction at least).

Or maybe you already do all that and there was some issue during upgrading which foiled this; in which case please ignore this :-)

Anyway, thanks for working on this great app, I really like it!

[adrian-bl]

That should not have happened: if a song is visible in the library, we should be able to play (and would display an error if we failed to read the file)

So absolutely nothing happened when you hit play? Did at least the icon of the play button change?

[oliver]

Most times the icon did not change (the Play icon remained); but I think there were some times where the icon did change to the Pause icon. The duration of the song was displayed, but the current position remained at 0:00.