GNOME Bugzilla – Bug 635350
playlists and portable devices
Last modified: 2012-05-05 18:15:23 UTC
I've been trying to get playlists working reasonably with my portable media device. Specifically, my device has an .is_audio_player with the following two directives in it: audio_folders=Music playlist_path=Playlists because on my media player songs are stored in /Music and playlists in /Playlists (relative to the device). What banshee does with those two directives though is puts playlists into /Music/Playlists, and likewise expects to find playlists in that directory. It seems like a bug to interpret the playlist_path relative to the audio_folders path. I have been able to work around the above bug by creating a symbolic link in /Music to ../Playlists on my device such that /Music/Playlists -> ../Playlists. When I do so however playlists that I create have entries that are relative to the Playlists symlink such as: ../Depeche Mode/101 (disc 1)/01 - Pimpf.mp3 when that file is in fact in /Music/Depeche Mode/101 (disc 1)/01 - Pimpf.mp3 on the media player. I don't think it's reasonable to expect any media player to understand relative paths because I don't think you can ever assume which folder a media player considers "current" after it's read the playlist and is going to play tracks. Also, playlists created by the device itself, have entries such as: /Music/The Smashing Pumpkins/Gish/03 - Rhinoceros.mp3 but banshee fails to read and understand that type of entry relative to the audio_folders setting. I think in short, banshee needs to think more like it's the portable media player and create fully qualified paths with the audio_folders and playlist_path.
Thanks for taking the time to report this bug. This particular bug has already been reported into our bug tracking system, but we are happy to tell you that the problem has already been fixed. It should be solved in the next software version. The value of playlist_path is now relative to the top level folder of the device, so you don't need the symlink trick anymore. *** This bug has been marked as a duplicate of bug 587756 ***