Bugzilla – Bug 5798
Can't add the same song more than once in a playlist
Last modified: 2009-10-05 14:34:22 UTC
If I edit a playlist and manually enter a new playlist entry (song or radio station) with a URL that already exists in the list and press the "Add" button, it will replace the existing entry, not add a new entry.
Similarly, if I try to edit an existing entry, manually changing the URL and press "Add", it adds this as a new entry, leaving the old entry too. I think there needs to be a distinction between editing an existing item, and adding a new item. eg. pick any item in the list, and you get to edit that item (change "Add" to "Update"). An "Add" button could be provided to force the creation of a new entry in the list.
see also bug 5797 Dean says this bug should go away with the playlist UI changes in 5797
Adding more than one item with the same URL can't be done easily: the url is the key to a playlist entry. We'd have to change the DB schema to make this work. Similarly if you edit an entry's URL, this is a new entry, as there's currently no command to actually _edit_ an entry. The command used is "add", which in turn runs an "updateOrCreate" call on the DB - which explains your second comment. Will concentrate on bug 5797.
Who know, maybe the new schema work will help?... reviewing for next release.
Brandon - is this something the new schema might address? Or shall we target this bug for future? Or close it as "wontfix"?
Alan - should this behaviour have changed with your recent changes to playlist handling?
I'm not sure why this should be a problem with ether the old or new schema. The URL is not required, by the schema, to be unique.
IMHO the problem is you can't have a url twice in the same list due to the way the playlist is stored in the DB?
The table definition is now (actually modified to ease explanations): TABLE playlist_track ( id INTEGER PRIMARY KEY AUTOINCREMENT, position int(10), playlist int(10), track text NOT NULL, FOREIGN KEY (`playlist`) REFERENCES `playlist` (`id`) ON DELETE CASCADE ); The 'track' field holds the URL of the track. Previously it used to be a foreign key into the tracks table. But either way it is not the primary key of the table, so there should be no problem with having two rows that refer to the same track. There is nothing in Slim::Schema::Playlist::Slim::Schema::Playlist() that seeks to eliminate duplicates.
Working fine in 7.4. Thanks Alan.
This bug has been marked as fixed in the 7.4.0 release version of SqueezeBox Server! * SqueezeCenter: 28672 * Squeezebox 2 and 3: 130 * Transporter: 80 * Receiver: 65 * Boom: 50 * Controller: 7790 * Radio: 7790 Please see the Release Notes for all the details: http://wiki.slimdevices.com/index.php/Release_Notes If you haven't already, please download and install the new version from http://www.logitechsqueezebox.com/support/download-squeezebox-server.html If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.