Not matter what and how, I can't get the Organize File Feature to work under Windows. Dialog works and fires a new dialog to confirm the operations. Progress popup appears, but seems to be stuck at 0%. Progress window stays until Amarok is closed or the operation is canceled by using the corresponding icon. The files aren't moved/renamed. Reproducible: Always Steps to Reproduce: 1. Select "Organize Files" from the context menu of a Collection/Album/Single file 2. Confirm upcoming dialog with "OK" or adjust format setting to your personal likings and confirm then 3. Confirm upcoming dialog with "rename" 4. Wait till eternity Actual Results: unlimited time to look at progress window Expected Results: Moved/renamed files I didn't work under 2.50-2 as well and thats why I upgraded to 2.6-beta. The only thing changed is the text on the operation confirm dialog.
I have the same problem. In my case I have the collection on my D: drive and I'm guessing that the problem is how the new path is built I attach a image showing the problem
Created attachment 72653 [details] screenshot of the problem
(In reply to comment #1) > I have the same problem. Looks more like this bug to me: https://bugs.kde.org/show_bug.cgi?id=279560 > In my case I have the collection on my D: drive and I'm guessing that the > problem is how the new path is built Organizing Files, doesn't work for me, even if the paths look fine. So I would guess, that those bugs are unrelated.
I'm organizing files in the same Collection folder, just changing their names and it adds C:/ twice at the beginning of the name, so probably this bug related to https://bugs.kde.org/show_bug.cgi?id=279560 I`ll attach an screenshot. Tested Amarok 2.6 under Windows 7.
Created attachment 73978 [details] Screenshot of what I think is causing this bug. I've circled what I think is the key of this bug, so this might be a duplicate of bug 279560
(In reply to comment #5) > Created attachment 73978 [details] > Screenshot of what I think is causing this bug. > > I've circled what I think is the key of this bug, so this might be a > duplicate of bug 279560 Thanks, it may be a good hint. Patrick, any thoughts?
(In reply to comment #5) > I've circled what I think is the key of this bug, so this might be a > duplicate of bug 279560 I can't reproduce it right now, but if I remember correctly my paths looked fine back when I opened this bug. Sadly I forgot to make a screenshot and if i want to reproduce it now, all I get is the double C:/ problem. By the way: Shouldn't it be C:\ as we are in a Windows environment?
(In reply to comment #7) > By the way: Shouldn't it be C:\ as we are in a Windows environment? Not necessarily, Qt translates all / into \ on Windows platforms for us.
Is this still valid for Amarok 2.6? Also Amarok 2.7 release for Windows is in the starting blocks, stay tuned :)
Yes, it still happens with Amarok 2.6
Thank you for the feedback.
It still happens with Amarok 2.7
(In reply to comment #12) > It still happens with Amarok 2.7 Thank you for the fast feedback.
Git commit fea4c497708328fdb886333c0e8836653f0dcb9c by Matěj Laitl. Committed on 18/07/2013 at 10:58. Pushed by laitl into branch 'master'. TrackOrganizer: fix foolish behaviour on Windows wrt \ vs. / path separators BUGFIXES: * Fixed organizing/copying/moving tracks to Local Collection on Windows. Related: bug 279560 FIXED-IN: 2.8 CCMAIL: Patrick von Reth <vonreth@kde.org> DIGEST: Amarok fixes organizing/copying/moving tracks in Windows M +2 -0 ChangeLog M +13 -3 src/core/support/Amarok.cpp M +17 -1 src/core/support/Amarok.h M +3 -5 src/dialogs/TrackOrganizer.cpp http://commits.kde.org/amarok/fea4c497708328fdb886333c0e8836653f0dcb9c
I have the problem with Amarok 2.8. In the preview the path displayed is the following: "C:/Program Files (x86)/Amarok/C/Data/music/Alec Holowka/Aquaraia Original Soundtrack/01 Intro.mp3" It should rather be: "C:/Data/music/Alec Holowka/Aquaraia Original Soundtrack/01 Intro.mp3" Deteting files works fine. There is also the path correct shown. The source path in the "Organize files" window is correct.
Reopening, based on comment #15