Bugzilla – Bug 733
Problem saving playlists containing mp3s from cuesheets
Last modified: 2008-12-18 11:55:16 UTC
I'll occasionally open up my playlists with a text editor to make some manual edits. I noticed that the start and end points of an mp3 referenced inside a cue file are no longer being saved. However, playing and seeking tracks inside an album referenced by a cue file still works, so the tracks are still being stored internally. For example, the playlists look like: file:///export/music/handel/messiah_pinnock/handel_-_messiah_-_pinnock_-_disc_1.mp3 file:///export/music/handel/messiah_pinnock/handel_-_messiah_-_pinnock_-_disc_1.mp3 file:///export/music/handel/messiah_pinnock/handel_-_messiah_-_pinnock_-_disc_1.mp3 file:///export/music/handel/messiah_pinnock/handel_-_messiah_-_pinnock_-_disc_1.mp3 instead of: file:///export/music/handel/messiah_pinnock/handel_-_messiah_-_pinnock_-_disc_1.mp3#0.32-203.57 file:///export/music/handel/messiah_pinnock/handel_-_messiah_-_pinnock_-_disc_1.mp3#203.57-409.45 file:///export/music/handel/messiah_pinnock/handel_-_messiah_-_pinnock_-_disc_1.mp3#409.45-621.2 file:///export/music/handel/messiah_pinnock/handel_-_messiah_-_pinnock_-_disc_1.mp3#621.2-792.55 It is possible this is affecting flac+cue files as well, but I no longer have any of those files to test.
please refer to bug682. I think these may be similar enough to be considered the same bug.
Yes, sure looks the same. This seems to be have introduced in Formats/Parse.pm v1.21
damn...that presents a problem. v1.21 was done so that the playlists written out by slimserver are compatible with other systems. Is this indexed reference system from the cue sheets valid when used with, say winamp? If so, this wont be too bad. If not, then we may be stuck on this one, or we'll have to come up with something custom, which then makes it complicated when there are mixed file types.
I asked a friend to try an m3u file with the "#xx-yy" extensions and they did not work in either winamp 2 or foobar2000. It was interpreting the "#xx-yy" as a file extension.
well...this is going to get interesting :)
*** Bug 682 has been marked as a duplicate of this bug. ***
Unfortunately, there's no standard URL format for expressing fragments of audio files, the url#start-end syntax is something that I came up to solve this problem. If we save the playlists with this format then other programs can't read the playlist. If we remove that ending from the playlist, then the playlists are broken for SlimServer (i.e. you lose the fragment information) and other programs (you hear it from the beginning). I'd prefer to make SlimServer work, since there's no other way to do it and the playlists are broken for the other programs with or without the suffix. Somebody want to roll back the problem file?
Do we really need to break ALL playlists? what if we detect the anchor references (I think we already break those out in another place too) and write out a slimserver-only playlist only when anchors are present? There has been a lot of user demand for better playlist management. I can see that going forward, the SQL features will allow this to be expanded, so I would expect a great many users will be expecting slimserver generated playlists to be compatible with their other players. (tho I can't understand the need for other players ;) )
KDF wrote: >Do we really need to break ALL playlists? No. :) The issue is that some songs which are expressed as fragments of a bigger file have no way to be expressed correctly in a playlist. we added a way to do this that SlimServer understands. So, we should export lists that work correctly for as many software packages as possible, including the CUE- originated fragments using our proprietary format. (And we should also try to get other folks to start using that format!)
Here's a simple patch to preserve the fragment when necessary: Index: Slim/Formats/Parse.pm =============================================================== ==== RCS file: /home/cvs/cvsroot/slim/server/Slim/Formats/Parse.pm,v retrieving revision 1.28 diff -r1.28 Parse.pm 409c409 < my $path = Slim::Music::Info::isFileURL($item) ? Slim::Utils::Misc::pathFromFileURL($item) : $item; --- > my $path = Slim::Music::Info::isFileURL($item) && !Slim::Music::Info::isFragment($item) ? Slim::Utils::Misc::pathFromFileURL($item) : $item;
looks like a winning plan to me :)
Dean's 1 liner fix works fine for me. Can this fix please make it into 5.4.1 & 6?
Commited to both 5.4 and 6.0
This Slimserver bug was fixed a very long time ago, and is now being marked as Closed. If you're still experiencing this issue, please verify you are running a current version of Slimserver and re-open the bug.
Routine bug db maintenance; removing old versions which cause confusion. I apologize for the inconvenience.