Video and Music scopes should provide non-file:/// based URIs

The limiting factor here is the app_armor profile. This is set up to be this restrictive on purpose. Subscribing jdstrand to comment on whether this should truly be a bug or a won't fix.

What are the apparmor denials? mediascanner-2.0 has quite wide access to the users home. Are the files owned by root or the user? (thye should be owned by the user).

The same goes for media-hub-server.

It looks like the problem is URLDispatcher is failing trying to launch the URL from the dash when the file lives in ~/Pictures:

** (process:2555): WARNING **: Unable to dispatch url 'file:///home/phablet/Pictures/IMG_2088.MOV':GDBus.Error:com.canonical.URLDispatcher.BadURL: URL 'file:///home/phablet/Pictures/IMG_2088.MOV' is not handleable by the URL Dispatcher

There are no denials in syslog. When moving the movie to ~/Videos, it's launched correctly by url dispatcher.

The URL dispatcher current has two file:/// based URLs that are for backwards compatibility with the URLs that came from the Unity 7 scopes. Those two are for ${HOME}/Music and ${HOME}/Videos which are routed to their appropriate players.

The long term solution is to kill those URLs for usage in the video and music scopes as they don't really do what we want. Researching to see if that's reasonable in the RTM timeframe.

Just as an FYI the music-app supports the protocol music:///path/to/file which would resolve this issue for the music scope.

don't we need a photo:// url for the "My Photos" scope as well?

This affects video playback from sdcards (non standard we are "use to" paths on devices).

This bug was fixed in the package url-dispatcher - 0.1+14.10.20140925-0ubuntu1

---------------
url-dispatcher (0.1+14.10.20140925-0ubuntu1) utopic; urgency=low

  [ Ted Gould ]
  * Drop file based URLs for Music and Video (LP: #1340952)
  * Update tests to work with new UAL requirements (LP: #1370735)
 -- Ubuntu daily release <email address hidden> Thu, 25 Sep 2014 13:29:40 +0000