Version: 1.90 (using 4.1.1 (KDE 4.1.1), Gentoo) Compiler: x86_64-pc-linux-gnu-gcc OS: Linux (x86_64) release 2.6.26-gentoo try downloading a file via the jamendo plugin, or just click on "copy to local collection", you'll be prompted with a nice dialog to tweak the way you want to store these music files. however, the path names being generated are all directories except the last part. although, it seems that the jamendo.com request URL is part of each song is part of the local destination filename, too.
can you please provide an example?
This also happens on Windows XP SP3, MSVC build. You chose the way to download the music from Jamendo (Copy to collection or just Download) and Amarok launches KGet. In KGet the URI filed contains something like this: file:///C:/Program%20Files/KDE/bin/%2522C:/Documents%2520and%2520Settings/Kraplax/.kde/tmp-X-COM/amarokgx4760.torrent%2522 The destination file name is E:/Download//KGet/amarokgx4760.torrent%22 (E:/Download/ is my default download directory). This happens if we manage to launch Amarok with Start menu (which makes the launch directory to be C:/Program Files/KDE/bin - or just %KDEROOT%/bin). If we open console, navigate to, for example, D:/Setup/ and launch amarok (given that amarok.exe is in system PATH), then the KGet will show the following string in the URI field: file:///D:/Setup/%2522C:/Documents%2520and%2520Settings/Kraplax/.kde/tmp-X-COM/amarokri1172.torrent%2522 and destination file is named respectfully: E:/Download//KGet/amarokri1172.torrent%22 i Hope these examples are enough. If needed i could provide you with more. Thanks for your efforts.
This has to do with the CollectionLocation API. The model assumes we are transferring actual tracks between collections. So it is JamendoCollection's responsibility to handle the torrent before passing it to the receiving collection.. Nikolaj, any ideas how this should be handled? Maybe open up ktorrent.. use some dbus magic to figure out when the download is done, and launch a real Move to Collection from the downloaded files?
Nikolaj, any update on this?
Since we are using an external app for actually downloading the files, this is not that simple to fix. The "real" way of solving this issue would be to not use the KTorrent (or other bittorrent) application but rely on libktorrent. When I originally wrote the service, this was not available however. This is a somewhat large task though and it is not very high on my todo list at the moment, so if anyone else feels like having a go at it, feel free.
Nikolaj, is this somehow API related?
Commit 60aabfe17cc2628867f53cd4b3f4e3ed37d3bc63 fixes the issue when using "copy to collection"
The last part of this bug, about the name of the album being downloaded is unfortunately not something that can be easily fixed while relying on an external bittorrent client. I am closing it and marking it as "later" as I will revisit it if we ever decide to use a bittorent lib to handle the downloads internally. Now that "copy to collection" works smoothly it might actually make sense to disable this bittorrent download option completely if it does not work well and simply making the "download button" start a "copy to collection" operation.
Closing correctly, solved in 2.x since quite some time.