Version: 1.1.1 (using KDE KDE 3.4.0) Installed from: Debian testing/unstable Packages OS: Linux Amarok doesn't play files from a media:/ URL. Playing from a "normal" mounted location works (e.g. /cdrom). Bug 101671 may be related, but I don't really get what the reporter wants to tell us. Here is some console output though I don't know if this helps: amarok: [aRts-Engine] Loading url: media:/cdrom/De-Phazz/De-Phazz%20-%20Godsdog/03-Jazz%20Music.mp3 amarok: aRts-Engine: url.path() == /cdrom/De-Phazz/De-Phazz - Godsdog/03-Jazz Music.mp3 amarok: aRts-Engine: url.protocol() == media amarok: aRts-Engine: url.host() == amarok: aRts-Engine: url.port() == 0 amarok: [virtual bool ArtsEngine::load(const KURL&, bool)] m_pPlayObject->object().isNull()
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?