Music files are imported into the Music app, rather than simply opened

[Victor Thompson]

Currently the File Manager uses Content Hub to send audio files being "opened" to the Music app. However, the files are actually imported when sent via Content Hub. This causes duplicate entries of the files if they are "opened" from the user's Music directory. The imported files will get stored to the user's $HOME/Music/Imported/mm/dd/ directory.

It'd be better if the File Manager used the "file:///" URI handler when prompting the user to "Open with" the Music app. Any use of Content Hub to send files to the Music app should be made clear that the action will import the song rather then just open the current location.

[Victor Thompson (vthompson)]

This same behavior also occurs for Videos and Picture, all of which import as duplicate content in the Gallery app.

[Andrew Hayzen (ahayzen)]

Can music read files outside of ~/Music/* (or the SD's music folder) ? (IIRC it can't)

If music can't then we would need urihandler calls for anything inside ~/Music/* (or the SD's music folder) and content-hub calls for audio somewhere else on the filesystem, eg ~/Downloads/*.

[Victor Thompson (vthompson)]

I agree that that would be possible, but the instances using content hub
should say that the file is being imported.
On Jan 23, 2015 6:05 AM, "Andrew Hayzen" <email address hidden> wrote:

> Can music read files outside of ~/Music/* (or the SD's music folder) ?
> (IIRC it can't)
>
> If music can't then we would need urihandler calls for anything inside
> ~/Music/* (or the SD's music folder) and content-hub calls for audio
> somewhere else on the filesystem, eg ~/Downloads/*.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1413821
>
> Title:
> Music files are imported into the Music app, rather than simply opened
>
> Status in File Manager application for Ubuntu devices:
> New
>
> Bug description:
> Currently the File Manager uses Content Hub to send audio files being
> "opened" to the Music app. However, the files are actually imported
> when sent via Content Hub. This causes duplicate entries of the files
> if they are "opened" from the user's Music directory. The imported
> files will get stored to the user's $HOME/Music/Imported/mm/dd/
> directory.
>
> It'd be better if the File Manager used the "file:///" URI handler
> when prompting the user to "Open with" the Music app. Any use of
> Content Hub to send files to the Music app should be made clear that
> the action will import the song rather then just open the current
> location.
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu-filemanager-app/+bug/1413821/+subscriptions
>

[Arto Jalkanen (ajalkane)]

I don't think this is a FileManager bug, in my understanding this is rather about missing features in Content-Hub.

As said by Andrew, using urihandler won't work because of app-confinement. Unless there's objections I'll invalidate this bug in few days since I unfortunately don't see there's anything that can reasonably done by FileManager about this issue....

[Pat McGowan (pat-mcgowan)]

It would be a nice optimization if files in /Videos and /Music which will be accessible by the target apps were called with url dispatcher.

I am told that the import is a hard link so it should be fast and not take additional disk.

[Arto Jalkanen (ajalkane)]

I closed this bug. This issue, which I readily admit is a real one, belongs IMO to improving content-hub

[Andrew Hayzen (ahayzen)]

As discussed on IRC.

The problem with content-hub is not that it is slow, it is the fact that we import that music again. So say you open a file that is already in ~/Music via content hub, you'll then have two inside ~/Music and a duplicate in your library :/

Can we not have a whitelist of directories for both music and videos which will use url-handler instead of content-hub. The only directories in this whitelist would be (eg for music):
/home/*/Music
/media/*/*/Music

I feel this should be simple enough to implement and prevents duplicates in your library therefore I am reopening this bug.

[Stefano Verzegnassi (verzegnassi-stefano)]

My two cents on this question, since it affects also ubuntu-docviewer-app.

Docviewer re-uses some classes from gallery-app to handle content-hub import/export[1].
During an MP, it has been suggested to compare the MD5 checksum of the imported document with the checksum of the existing document with the same name.
If they're the same, the app should finalize the transfer without creating a new copy of the file.

It seems easy to achieve this with the C++ APIs, but I don't know how it could work with the QML APIs.

However, I agree with Arto: while I was looking at this issue, I expected that content-hub exposed the source path of a transfered file through some function, since that would simplify a lot the management of such critical scenarios.

[1], line 56: http://bazaar.launchpad.net/~ubuntu-docviewer-dev/ubuntu-docviewer-app/trunk/view/head:/src/app/content-communicator.cpp

[Andrew Hayzen (ahayzen)]

I agree that MD5 sums could be a potential alternative however as you stated this is easy to achieve with C++ but probably not QML. Also maintaining and generating a list of the MD5 sums of 1000s of files at 5-50MB+ each could be very resource intensive, therefore this probably not a realistic solution.

Furthermore I'm not sure whether content-hub should expose the original source path this feels like it breaks security/privacy a little in my mind, but I'm open for this being an option if the content-hub and security guys are OK with this.

[Stefano Verzegnassi (verzegnassi-stefano)]

Yes, MD5 is not the best solution we have.

I'm not sure about exposing the original source path. Although it's true that it could be a sensible information, I don't think it's more sensible than the content of a file itself.

If a user wants to transfer an image (e.g. from /home/phablet/Pictures/secret_projects/patent_no82399.png) to another app (which is an unknown malware), that app could anyway read the content of the image and upload it somewhere on the net (supposed that the app uses "networking" and "content-hub" policies).
The malware can't access the original source anyway, so the only information it can get from it is that there's a specific path in the FS.
Things change a little bit if the malware is unconfined. But in that case, it could already sniff at all the images without need any further information from content-hub.