We're restricting this to ~/Downloads and ~/Music, which folders are included in your case?

It shows .mod files from my ~/bin directory, my custom compiled applications and 3rd party apps are installed there as subfolders. Music is even showing files that are not music, *.mod files like

~/bin/Komodo-Edit-9/lib/support/catalogs/sgml-lib/REC-SVG11-20030114/svg-animation.mod

Is it happening on some specific view or across the whole app?

Could you also attach the 'gnome-music.log' file here produced by 'gnome-music -d &> gnome-music.log' command? Please start a playback of a faulty file before closing the app.

Which distro and package version are you using?

Checking the contents of the log I noticed the same files on my bin directory are on my Download directory too. GNOME Music is reading them from Downloads. .mod files that are XML DTD fragments, not audio. I did a grep over the log because It contains too much private information (Music preferences). I am attaching the lines where the .mod files are referenced.

Can it still has a preference to only use Music or set the folders instead of showing all silly audio file you download?

Created attachment 305754 [details]
log file fragment with incorrect .mod file detection

I forgot, I am using Fedora 22 with gnome-music-3.16.1-1.fc22.x86_64

(In reply to Robert Marcano from comment #4)
> Checking the contents of the log I noticed the same files on my bin
> directory are on my Download directory too.
Not sure if I understood the meaning of 'the same' - are those a copy or a hardlink? The case with files from ~/Downloads is clear to me, while why ~/bin files are included is completely puzzling. 
Any idea why is this happening? Could you attach this part of the logs?

(In reply to Robert Marcano from comment #4)
> Can it still has a preference to only use Music or set the folders instead
> of showing all silly audio file you download?

Yes, see [1] or [2]. Note, that this will disable indexing for other apps too - e.g. GNOME Documents. Other tricks to try - run GNOME Music with 'XDG_DOWNLOAD_DIR=/tmp'

[1] http://worldofgnome.org/indexing-preferences-in-gnome-3-8/
[2] https://mail.gnome.org/archives/tracker-list/2013-June/msg00022.html

(In reply to Vadim Rutkovsky from comment #7)
> Not sure if I understood the meaning of 'the same'

Let me rephrase everything for clarity:

1) Non Error: I found svg-animation.mod list on as music. did a "find -name svg-animation.mod" and found it inside ~/bin. Later when generating the log as requested noticed that it was looking for it inside the Download directory (another copy), so the location was right, the Downloads folder, my mistake

2) Error: Not all .mod files are audio, this is a text file (a XML DTD fragment), so it should not be listed as music. If GNOME Music is only taking into consideration extensions and it doesn't do a file contents check (Magic number?) the this could happen a lot. It could happen even with files that are being downloaded and not ready yet, Firefox for example create an empty file when downloading (reserving the name) and save the file with the .part extension, later it renames it.

> (In reply to Robert Marcano from comment #4)
> > Can it still has a preference to only use Music or set the folders instead
> > of showing all silly audio file you download?
> 
> Yes, see [1] or [2]. Note, that this will disable indexing for other apps
> too - e.g. GNOME Documents. Other tricks to try - run GNOME Music with
> 'XDG_DOWNLOAD_DIR=/tmp'
> 
> [1] http://worldofgnome.org/indexing-preferences-in-gnome-3-8/
> [2] https://mail.gnome.org/archives/tracker-list/2013-June/msg00022.html

3) Request for Enhancement: Add a setting to add or remove folders that the user consider contains music. Use case: I don't find rare to create a local folder with a family group permission to share music on the same device with many users. This is a case where Media network sharing doesn't help or is extremely inefficient because we are talking about sharing between users of the same device, using a single shared folder.

Adding to 3), those recommendations are nice as workarounds not as final user that don't know how to exclude the downloads folder using the CLI

(In reply to Robert Marcano from comment #8)
> (In reply to Vadim Rutkovsky from comment #7)
> > Not sure if I understood the meaning of 'the same'
> 
> Let me rephrase everything for clarity:
> 
> 1) Non Error: I found svg-animation.mod list on as music. did a "find -name
> svg-animation.mod" and found it inside ~/bin. Later when generating the log
> as requested noticed that it was looking for it inside the Download
> directory (another copy), so the location was right, the Downloads folder,
> my mistake

Okay, that was the original error, so I tend to close this as NOTABUG.

> 2) Error: Not all .mod files are audio, this is a text file (a XML DTD
> fragment), so it should not be listed as music.

There is no way for us to know that. Filetype is detected by tracker-extract - not sure if it can easily be resolved, but this is where the error occurs.

> 
> > (In reply to Robert Marcano from comment #4)
> > > Can it still has a preference to only use Music or set the folders instead
> > > of showing all silly audio file you download?
> > 
> > Yes, see [1] or [2]. Note, that this will disable indexing for other apps
> > too - e.g. GNOME Documents. Other tricks to try - run GNOME Music with
> > 'XDG_DOWNLOAD_DIR=/tmp'
> > 
> > [1] http://worldofgnome.org/indexing-preferences-in-gnome-3-8/
> > [2] https://mail.gnome.org/archives/tracker-list/2013-June/msg00022.html
> 
> 3) Request for Enhancement: Add a setting to add or remove folders that the
> user consider contains music. Use case: I don't find rare to create a local  > folder with a family group permission to share music on the same device with > many users

If user doesn't store music files in XDG_DIR_MUSIC, this folder should be updated. I haven't tried it but sounds like updating user's xdg folder will fix Music. I believe we can add a setting to include additional folders, but that's a subject for a different bugreport anyway.

Well the original error was "Restrict music catalog to the Music folder (or add a setting)", the .mod was an example of why, so please consider it to be the 3) case, and don't close it unless the decision is to not add a way to add and remove folders

About the .mod false detection, do you recommend that I open a new bug for tracker?

(In reply to Robert Marcano from comment #11)
> Well the original error was "Restrict music catalog to the Music folder (or
> add a setting)", the .mod was an example of why, so please consider it to be
> the 3) case, and don't close it unless the decision is to not add a way to
> add and remove folders

Agreed. 
Allan, any thoughts on this? It seems to be a rather frequently requested feature. My initial idea is to add 'additional-folders' in gsettings.

> About the .mod false detection, do you recommend that I open a new bug for
> tracker?
Yes, though I don't know if they can do anything about it.

I have a suggestion concerning design (the same I posted for gnome photos):

Add option called "My Library" or simply "Library" on Music's menu (the one on the GNOME Shell top bar).

After clicking, a dialog open: it has a brief explanation ("This are the directories that GNOME Music will look for your songs" or something like that), a list of directories (~/Photos and ~/Downloads by default) and +/- buttons (to add and remove directories from the list).

This way we both:
1) Maintain a sane default, that is reasonable enough to keep users from dealing with folders/files directly. 

2) Add a option to non-default users (who may keep music on multiple folders, possibly on a different drive, or simply don't want music inside ~/Downloads showing up on the app). The configuration is as straightforward as possible, and simple enough to the average user to find and use. This also avoids a new "Preferences" menu, that would clutter the app.

(In reply to p.oliveira.castro from comment #13)
> After clicking, a dialog open: it has a brief explanation ("This are the
> directories that GNOME Music will look for your songs" or something like
> that), a list of directories (~/Photos and ~/Downloads by default) and +/-
> buttons (to add and remove directories from the list).

We cannot ask tracker to start scanning arbitrary directories. This would set inotify watchers for them and severely impact the performance.

Hmmm...how about making a checkbox (possibly inside the top menu) called "Photos in Downloads". That said, now I believe the sane default would be only watch ~/Photos. This is much more predictable to the final user.

Indexing the audio files from Downloads was supposed to serve as a kind of poor man's import function. However, I'm really not sure whether it is performing that function. Music tends to exist as a fairly well defined collection which is managed.

It might well be best to stop indexing ~/Downloads - it produces a lot of false positives (as this bug demonstrates), and doesn't seem all that useful.

Created attachment 318373 [details] [review]
query: restrict music catalog to the Music folder

Comment on attachment 318373 [details] [review]
query: restrict music catalog to the Music folder

pushed to master as https://git.gnome.org/browse/gnome-music/commit/?id=539a60d

This change has broken my use case, as I was also listing music from ~/Downloads/. Still, I understand the intent of this report and the associated change, so I'd like to express my opinion in favour of a configuration option that would allow selecting which folders to include. If possible, those folders should explicitly be restricted to what tracker is listing and invite users to change tracker settings to have more locations available.

Finding out that configuring tracker was needed to list music from the directories I want (on 3.18) was not trivial, so this would be a way to make it a bit easier for users, too.