Bug 102668

Just upgraded. Same Problem exists with amarok 1.2.1

Just found out that this is obviously a problem with the arts-engine. Playing media:/ URLs works fine with the gstreamer-engine.

To support media:/ URLs like local files, it's possible decode to a path, like kaffeine:
http://cvs.sourceforge.net/viewcvs.py/kaffeine/kaffeine/kaffeine/kaffeineapp.cpp?r1=1.21&r2=1.22

Created attachment 11285 [details]
load media:/ urls like local files

It modifies playlistloader.cpp to decode media URLs to local paths and then all
engines can play media URLs and can seek in them, like with files in hard disk.

If you apply that patch, add media should permit media:/ URLs instead only local files.

With 1.3beta I can add media:/ URLs, but I can't play it with xine engine. With the patch I sent before, the URL is resolved to a file:/ URL and I can play it like a file in hard disk.

Comment on attachment 11285 [details]
load media:/ urls like local files

I'll send a patch with comments

Created attachment 11540 [details]
load media:/ urls like local files

The previous patch with comments

SVN commit 428454 by markey:

Support for "media:/" URLs. Patch from  
Sergio Cambra <sergio@ensanjose.net>

Sergio writes:
Some engines doesn't understand media:/ URLs, like xine, but media:/ URLs 
are local files too, and it's easy convert these urls to local files using 
DCOP, and then all engines can seek in those files like files in hard 
disk.

I sent a patch to fix it in bug #102668. I applied that patch to 1.2.4 and 
to 1.3 beta1 and works with no problem. I have attached that patch too.

CCMAIL: sergio@ensanjose.net
CCMAIL: amarok-devel@lists.sf.net
BUG: 102668



 M  +2 -0      ChangeLog  
 M  +23 -0     src/playlistloader.cpp  


--- trunk/extragear/multimedia/amarok/ChangeLog #428453:428454
@@ -5,6 +5,8 @@
 
 VERSION 1.3-beta2:
   FEATURES:
+    * Support for "media:" URLs. Patch by Sergio Cambra <sergio@ensanjose.net>
+      (BR 102668)
     * Support for visualizations in the Helix engine.
     * Queue manager to help organise your queued tracks. (BR 90594)
     * Ability to create Smart Playlists based on file path. (BR 92467)
--- trunk/extragear/multimedia/amarok/src/playlistloader.cpp #428453:428454
@@ -26,6 +26,7 @@
 #include <qstringlist.h>
 #include <qtextstream.h> //::loadPlaylist()
 #include "statusbar.h"
+#include <dcopref.h>
 
 
 typedef QValueList<QDomNode> NodeList;
@@ -68,6 +69,28 @@
                 m_URLs += url;
         }
 
+       else if( protocol == "media" ) {
+            // url looks like media:/device/path
+            DCOPRef mediamanager( "kded", "mediamanager" );
+            QString device = url.path( -1 ).mid( 1 ); // remove first slash
+            const int slash = device.find( '/' );
+            const QString filePath = device.mid( slash ); // extract relative path
+            device = device.left( slash ); // extract device
+            DCOPReply reply = mediamanager.call( "properties(QString)", device );
+
+            if( reply.isValid() ) {
+                const QStringList properties = reply;
+                // properties[6] is the mount point
+                KURL localUrl = KURL( properties[6] + filePath );
+
+                // add urls
+                if( QFileInfo( localUrl.path() ).isDir() )
+                    m_URLs += recurse( localUrl );
+                else
+                    m_URLs += localUrl;
+            }
+        }
+
         else if( PlaylistFile::isPlaylistFile( url ) ) {
             new RemotePlaylistFetcher( url, after, m_playFirstUrl );
             m_playFirstUrl = false;

You shouldn't hardcode "media".

You should instead use KIO::stat and use mostLocalURL.

I think mostLocalURL doesn't exist in KDE 3.3, and amarok depends on it.

media:/ doesn't exist in KDE 3.3 either, but I see your point.

Can you add a "FIXME" for when amaroK no longer depends on KDE 3.3? That should happen at least for KDE4.

Thiago is right, media:/ uses UDS_LOCAL_PATH, and it's not the only one to do
this. Starting with KDE 3.5 it'll become even "worse", since home:/ is
introduced using the same technics.

To solve your issue in a generic way, you could define KIO::UDS_LOCAL_PATH which is equal to "72 | UDS_STRING" (defined in kdelibs/kio/kio/global.h in
trunk). Stating a file and search for the atom having this id number would
be enough. 
 
It's definitely a workaround but would be far better than using DCOP for this. 
And it would work with other ioslaves using UDS_LOCAL_PATH.

*** Bug 101671 has been marked as a duplicate of this bug. ***

Why hasn't this been implemented in 1.4.0?