Bug 160841 - Path incompatibilities between Linux and Windows cause several problems.
Summary: Path incompatibilities between Linux and Windows cause several problems.
Status: RESOLVED LATER
Alias: None
Product: amarok
Classification: Applications
Component: Playlists/Saved Playlists (show other bugs)
Version: 2.4-GIT
Platform: Ubuntu Linux
: NOR normal
Target Milestone: 2.4.0
Assignee: Amarok Developers
URL:
Keywords:
: 195161 258769 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-04-14 21:54 UTC by Vangelis
Modified: 2013-01-10 11:20 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vangelis 2008-04-14 21:54:53 UTC
Version:           1.4.8 (using KDE 3.5.9)
Installed from:    Ubuntu Packages
Compiler:           I installed amarok from the kubuntu amd64 repositories.
OS:                Linux

I have a dual boot system (Linux, windows) and a common partition that unfortunately it is ntfs, for the reason to be able to be seen from both operating systems.
In the common ntfs drive I have my mp3 files and I have also my playlists that the paths are windows paths.
It would be nice if I could load these playlists directly under linux!

For example,
If the paths are relative you can see something like:

#EXTM3U
#EXTINF:341,Artist - XXXXXX
Artist\XXXXXX.mp3

Or if the paths are absolute something like this:
#EXTM3U
#EXTINF:341,Artist - XXXXXX
C:\Music\Artist\XXXXXX.mp3

It would be nice if the Amarok could determine that this is a windows playlist and if the paths are relative just change the "\" to "/" so that the files will be playable under linux without the need of recreating a new playlist :)

So the above it could be like this and then it would be playable under linux:

#EXTM3U
#EXTINF:341,Artist - XXXXXX
Artist/XXXXXX.mp3

If the paths are absolute it could be checking the mounted ntfs drives and changing instead of just the "\" to "/", also the windows drive letter "C:" or "D:"whatever to the correct folder that the corresponding drive is mounted!

Lets say that if you have mounted the drive C: to /media/Winblows the above example should be
#EXTM3U
#EXTINF:341,Artist - XXXXXX
/media/Winblows/Music/Artist/XXXXXX.mp3

Also after the change it should ask you if you want to save the playlist in the linux format :)

That`s the brainstorm!
Thanks,

Vangelis.
Comment 1 Mark Kretschmann 2008-04-14 23:11:44 UTC
Makes sense to me. Shouldn't be so hard to implement either.

Considering that Amarok 2 runs on Windows too, we'll have to deal with that anyway.
Comment 2 Bart Cerneels 2009-09-29 10:40:30 UTC
Qt/kdelibs already handles file paths on windows, we don't need t do anything special.

The \ -> / is probably easy to do, if Qt doesn't already. But I'm not going to implement a windows drive letter to unix mount-point translation, just save them with relative paths.
Comment 3 Sven Krohlas 2010-04-30 13:20:39 UTC
2.3.1 is in feature freeze -> 2.3.2
Comment 4 Myriam Schweingruber 2010-12-13 11:51:38 UTC
*** Bug 195161 has been marked as a duplicate of this bug. ***
Comment 5 Myriam Schweingruber 2010-12-13 11:52:03 UTC
*** Bug 258769 has been marked as a duplicate of this bug. ***
Comment 6 Myriam Schweingruber 2010-12-13 14:06:04 UTC
Changed title and severity.

Is this still valid with latest 2.4-git? I can't test here as I don't have a windows installation around.
Comment 7 Patrick 2010-12-14 05:45:13 UTC
Yes, playlists still contain absolute (and OS-dependent) paths, as does the collection database.

You actually don't need to have a Windows version of Amarok to verify that - if you look into the database, and see some paths starting with '/', and no drive letter in an extra column somewhere, you can be sure that won't work on Windows.
Comment 8 Myriam Schweingruber 2012-01-03 11:24:25 UTC
Isn't this fixed now with more recent Qt versions?
Comment 9 Myriam Schweingruber 2012-02-20 23:59:42 UTC
Patrick: is this still valid?
Comment 10 Myriam Schweingruber 2013-01-10 11:20:18 UTC
So apparently there is no easy fix for this, changing status.