Hmm, I wasn't able to reproduce this with Banshee from git master on Ubuntu 10.10 x64.  It seems unlikely that this was fixed between the release on Wednesday and today, but it would probably be good if you could test the latest Banshee from git or a build from the Daily PPA[1] just to be sure.

To make sure I was trying to reproduce this correctly, here's what I did:

1. I created a new (non-smart) playlist called 'Test'
2. I dragged 5 different songs by 5 different artists from my Music Library to this new playlist
3. I selected the 3rd and 4th tracks in the playlist, selecting multiple tracks by using the Ctrl key.
4. I pressed the Delete key on my keyboard, and when asked to confirm, I clicked the 'Remove' button.

In my case, the two selected songs were removed.  Either we're doing something different, or there's some hidden factor behind the scenes that it causing this difference in behavior.  Or maybe the issue has been fixed in the last couple days -- please test if you get a chance.  Thanks for reporting this!

[1] https://launchpad.net/~banshee-team/+archive/banshee-daily

Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!

Was no longer able to reproduce either. Don't know if my situation changed in between or if something magical happened in 1.9.1.
I'll reopen if I can re-reproduce and provide steps.

I'm seeing this too; Banshee 1.8.0 on Ubuntu 10.10 x86_64.

Not 100% sure what the magic incantation is to make it consistently happen, but I've definitely seen it several times in the last hour. Will attach screen shots and log.

Created attachment 179335 [details]
Screenshot showing three selected songs in a playlist & remove confirmation dialog

Created attachment 179336 [details]
Screenshot showing the three selected songs still there, but 3 other songs somewhere in the playlist have disappeared

Created attachment 179337 [details]
banshee log file from the session the screen shots were taken from

I wasn't able to reproduce this bug on ubuntu 10.10 x86_64, with banshee 1.8.

If no one can get this bug to occur in the latest stable (2.0.0) it needs to be closed.

*** Bug 647420 has been marked as a duplicate of this bug. ***

The bug that I just marked as a duplicate was reported against Banshee 2.0, so even if this issue is sporadic and hard to reproduce, it sounds like it's still around.

I am also having this issue with banshee 2.0.1, so yeah it seems to be hanging around.

I too have this problem. I may have an explanation on when this can (or cannot) be reproduced as I've been doing quite a lot of testing trying different combinations to understand what is happening.

Try the steps mentioned in Comment #1 after you start playing items from the test playlist with shuffle on. Let the playlist play couple of songs and then try to remove a song that is still playing (or songs that have just played). If you just create a static playlist and try to remove songs from it, it always works as it is supposed;  some goes for starting Banshee and directly removing the selected songs from static playlist, but if you start playback on Banshee things change.  

In my experience, removing selected song from static playlist (not smart) _always_ fails if you try to remove a song that is currently playing in that playlist. In that case, some other random item is removed from the playlist and the song keeps playing, staying in the playlist. (I would like the song to keep playing but to be removed from the playlist)

Using shuffle is also definately a factor. As when not using shuffle, song(s) can be removed from static playlist after 4-5 songs have been played from start to finish after the item(s) you want to remove. This trick does not work with shuffle on or in trying to remove items to be played. 

Another curious feature of this bug, which I have only encountered once or twice, is that you could not remove an item from static playlist1 even though you were playing songs from static playlist2. In that case the song to be removed (playlist1) was present in both playlists and some form of shuffle was used on playlist2.

I believe at least part of the cause for this bug is somewhere in how Banshee chooses the songs to be played next and keeps track of the songs recently played. As, otherwise, removing a song after few songs have been played from begin to end (no shuffle), would fail sooner or later, but that trick seems to work constantly for me.

I can't recreate on Fedora 14 Banshee 1.8.1.

I'm also having this problem with the latest Banshee from the Daily PPA (currently Banshee 2.0.1).

I have a static playlist and shuffle is turned off. Also, in my case it doesn't matter if the song I'm trying to delete is playing or not, it keeps deleting the wrong songs from the playlist. Anything I can do to help debugging?

I have been able to reliably reproduce this problem. It appears to be that when you sort the playlist, it is picking the song based on the unsorted order. Here are the steps to reproduce:

1. Create a new playlist and put an album's songs in it. (the behavior is easiest to see if the songs have track numbers) Make sure the unsorted order is the same as the track numbers.
2. Sort by a column, such as name.
3. Pick a song to remove from the playlist, and count the number of rows down from the top it is. (such as 4th from the top) Make sure this doesn't match the track number.
4. Remove that song from the playlist, and notice that a different track is removed. The track number of the deleted item should be the same as the position of the track you attempted to remove.

For example, for my sample I had a playlist with 11 songs from an album. I sorted by name, and selected track #1. Due to the sorting order, track #1 was 4th in the list. When I remove that track, track #4 is deleted instead, as it is 4th in the list when unsorted. If I try to delete track #1 again, track #5 is deleted, as that was the new 4th item in the unsorted list.

Mercifully, removing a track from the library or the drive isn't effected by this problem. I was able to restore a couple unintentionally removed tracks with the help of smart playlists.

I am using Banshee 2.0.1 on Arch Linux.

i am using nutty (11.04) and this problem is still present.

also, the banshee version i am using is 2.0.1

Created attachment 194351 [details] [review]
playlist patch

Can you test this patch if it fix the issue?

Review of attachment 194351 [details] [review]:

::: src/Core/Banshee.Services/Banshee.Playlist/PlaylistSource.cs
@@ +103,3 @@
             remove_track_range_command = new HyenaSqliteCommand (@"
                 DELETE FROM CorePlaylistEntries WHERE PlaylistID = ? AND
+                    TrackID IN (SELECT TrackID FROM CoreCache

The CoreCache table does not have a TrackID column, so I don't think this would work.

The cache table is defined here :
http://git.gnome.org/browse/hyena/tree/Hyena.Data.Sqlite/Hyena.Data.Sqlite/SqliteModelCache.cs#n499

Did you test Banshee with this change ?

I have applied that patch and instead of deleting the selected song it removes all the songs in that playlist.

I can confirm Aaron's method of reproducing the bug.

I'm no longer having this issue with Banshee 2.2.0 that comes with Ubuntu 11.10.

(In reply to comment #22)
> I can confirm Aaron's method of reproducing the bug.

(In reply to comment #23)
> I'm no longer having this issue with Banshee 2.2.0 that comes with Ubuntu
> 11.10.

Serrano, why comment#23 contradicts comment#22? Were you testing a version lower than 2.2.0 in comment#22?

> Serrano, why comment#23 contradicts comment#22? Were you testing a version
lower than 2.2.0 in comment#22?

I just checked, and I was already using 2.2.0 (from the daily PPA) when I posted comment #22 (still having that bug on Ubuntu 10.10 + daily PPA). But I have dual boot with Ubuntu 11.10 now which also runs 2.2.0 from the Ubuntu repo (so not the daily PPA) and I'm not experiencing that problem on Ubuntu 11.10.

(In reply to comment #25)
> > Serrano, why comment#23 contradicts comment#22? Were you testing a version
> lower than 2.2.0 in comment#22?
> 
> I just checked, and I was already using 2.2.0 (from the daily PPA) when I
> posted comment #22 (still having that bug on Ubuntu 10.10 + daily PPA). But I
> have dual boot with Ubuntu 11.10 now which also runs 2.2.0 from the Ubuntu repo
> (so not the daily PPA) and I'm not experiencing that problem on Ubuntu 11.10.

Thanks for the info! The main difference that may matter here I guess is the version of Mono that each distro has (11.10 has 2.10.x, 10.10 has 2.6.x AFAIK).

So I'm going to close this as NOTGNOME.

Please, if any of you is able to reproduce this with Banshee 2.2.0 and Mono 2.10.x, reopen this bug.

Thanks.

I am using Banshee 2.2.0 and Mono 2.10.6 under Arch Linux and still experience this bug. Maybe there's an Ubuntu patch that fixes it that hasn't been incorporated upstream?

A developer will have to re-open this bug, since I don't have permissions to do so.

Thanks for the information Aaron.

I guess it's not possible to try to install Ubuntu's package into ArchLinux?

(In reply to comment #16)
> I have been able to reliably reproduce this problem. It appears to be that when
> you sort the playlist, it is picking the song based on the unsorted order. Here
> are the steps to reproduce:
> 
> 1. Create a new playlist and put an album's songs in it. (the behavior is
> easiest to see if the songs have track numbers) Make sure the unsorted order is
> the same as the track numbers.

I tried very hard to reproduce this bug today, to no avail, using the above instructions.

I'm wondering if the way to bring the songs to the playlist matters. Aaron, how did you bring the songs of the album to the playlist? and what do you mean with "unsorted order" above? (did you mean just "sort column")

Thanks

I brought in the songs by dragging them over from another playlist.

By "unsorted order", I mean the order that is displayed when no column has a sorting triangle on it. When you click a column once, it shows a downward facing arrow, meaning it is sorted in descending order. When you click the same column a second time, it has an upward facing triangle, meaning it is in ascending order. When you click the same column a third time, it is the original, unsorted order.

Created attachment 199730 [details]
Step by step instructions to reproduce the bug.

To make it easier to make sure you're following the proper steps, I have attached a PDF with step by step instructions and inlaid screenshots for how to reproduce the bug. I have bolded the key parts to try to make it as easy to follow as possible.

(In reply to comment #31)
> To make it easier to make sure you're following the proper steps, I have
> attached a PDF with step by step instructions and inlaid screenshots for how to
> reproduce the bug. I have bolded the key parts to try to make it as easy to
> follow as possible.

Hi again Aaron, sorry for my delay in replying. I appreciate all your help and effort in guiding me to try to reproduce the bug, but I've tried again (this time with your PDF) and I still cannot reproduce it. So we may be missing something about your particular testcase that I'm not setting up in the same way. Every tiny detail is important because we're talking about completely different setups, hardware, and data to test! Even the metadata of your music may matter in this bug (because one of the steps of the bug requires you to sort via clicking on a column). Also, you still don't specify important details like how do you remove the song: pressing Del in the keyboard or via context menu?

Given the above difficulties, I'm thinking that the best way for you to show me a concrete testcase of data and exact steps to reproduce would be:
1. Locate some album from some band on the internet that gives music for free (there are a lot popping up lately, especially under CreativeCommons licenses).
2. Try to reproduce the bug with that album, if you succeed, point me to the URL from where I can download the album (if you don't succeed, go back to step 1 to find a different album).
3. Record a small screencast that covers ALL of steps to reproduce the bug (and by ALL I mean I want to see how you import the album into banshee, how you edit the metadata in case it is missing track numbers, how you send the songs to a playlist, how you send the songs from a playlist to another, etc).

Would you have the time to do this? If yes, I would try to correspond you as well with some time from me to try to fix the bug :-)

(In reply to comment #32)

Oh, and I forgot to say two things:

- You don't need to do all steps at once. If you do steps 1 and 2, you can tell me, and then maybe we're lucky and I can reproduce the bug without needing the screencast!
- If the above fails after all (I still cannot reproduce it myself with a free album you point to me) then, when recording the screencast try to use the keyboard the less you can (because I cannot see your keyboard in the screencast) and use the mouse for everything.

Thanks again.

I think I have found the detail that we were missing. I tried setting up a clean environment with a new database, and the bug did not occur. This appears to only happen with databases that have been created with previous versions of Banshee. (IIRC mine was created with 2.0)

Using my existing music database, I also tried importing a new album that I hadn't previously had in my library, and the bug still occurred. I did notice something else about the behavior, though: it looks like the order it deletes the songs is based on the order it was originally added to the playlist. In other words, if you manually change the order of songs by dragging the songs around, they will be deleted based on their *original* unsorted location before they were dragged around.

The behavior is the same whether I the delete key or remove the song from the contextual menu. I have verified that the bug occurs with this freely available album, at least with my existing music database. (http://ocrmirror.org/files/music/albums/ff5/Final_Fantasy_V_-_The_Fabled_Warriors_~I.WIND~.zip)

(In reply to comment #34)
> The behavior is the same whether I the delete key or remove the song from the
> contextual menu. I have verified that the bug occurs with this freely available
> album, at least with my existing music database.
> (http://ocrmirror.org/files/music/albums/ff5/Final_Fantasy_V_-_The_Fabled_Warriors_~I.WIND~.zip)

With Banshee 2.2.1, I import that album and try to reproduce the bug, but I don't succeed. So it must be what you say about your DB being an "old" one (and I use quotes here because, in theory, even being old, Banshee updates the DB to be new whenever there are DB changes in the new version of Banshee).

So at this point I think the best thing to do is:
1. Make a backup of your "old" db file.
2. Run banshee With your "old" db.
3. Copy the FinalFantasy album uncompressed to $HOME/Music/
4. Import the album.
5. Delete from the DB all other music except this album.
6. Try to reproduce the bug.

And then, if you reproduce the bug, attach here the .db binary file, so I can download it and use it with my banshee. Ok?

Sorry for the delay in getting back to you.

I've tried a number of different things when trying to remove as much as my music as possible from the library, including leaving different songs that have been present since my initial import into Banshee, but as soon as I close down Banshee and start it up again I can no longer reproduce the bug.

(In reply to comment #36)
> Sorry for the delay in getting back to you.
> 
> I've tried a number of different things when trying to remove as much as my
> music as possible from the library, including leaving different songs that have
> been present since my initial import into Banshee, but as soon as I close down
> Banshee and start it up again I can no longer reproduce the bug.

Thanks for testing again. With what version of Banshee were you testing?

I ask because we fixed some encoding issues recently which were included in the latest development release (2.3.2). If you could give that a go with your *entire* and *old* database that would be great. If you cannot reproduce it anymore with these conditions we'll consider it fixed.

The bug still occurs with my music database left intact.

(In reply to comment #38)
> The bug still occurs with my music database left intact.

Ok thanks, I've sent you an email about this.

Lowering severity as it doesn't happen with a new&clean DB.

Andrés, What version of Banshee do you consider unaffected by this bug with new&clean DB? Does 2.2.1 qualify? Because if it does, then there are at least two more users still affected by this bug.

(In reply to comment #40)
> Andrés, What version of Banshee do you consider unaffected by this bug with
> new&clean DB?

You should ask that to Aaron, because he's the only person that has been able to not not reproduce it (with clean DB, as explained in comment#34) and to reproduce it with a non-clean DB.

(BTW Aaron sent me his faulty DB by email and I plan to look at fixing this soon thanks to that.)

I was using 2.2.1, and a completely new DB didn't exhibit the bug.

Well, there are two users in Launchpad [Bug 785822] who report that creating a new database with Banshee 2.2.1 did not change Banshee behaviour. The wrong song still gets removed from the playlist.

I am affected as well. Banshee 2.2.1 on Ubuntu 11.10 with Gnome3-PPA's and the Banshee PPA.

I don't know whether the cause of the issue is narrowed down but what I just tried:
I copied all the songs from an affected playlist in a new one (did nothing else but renaming it). The new playlist was sorted by Artist and I did not change that. When I tried to remove a file from the playlist (via the context menu), the wrong song was removed.

Tested some more. If I make the new playlist unordered, I can remove the expected tracks. But if I then rearrange some tracks and try to delete one, the one that was formerly on that position is deleted and not the new one.

It seems like the remove-function selects the file to remove from the wrong list (not the one the shown playlist is ordered by but their original order).

I can confirm this issue, occuring on Fedora 16 /w banshee version 2.2.1.

To anyone that can reproduce this problem:
Please run Banshee with the --debug-sql option, reproduce the problem and attach the full output here.

As there's going to be quite a lot of log output, you might want to direct it to a file :
banshee --debug-sql > debug.log

Created attachment 209432 [details]
Debug.log as asked for by Bertrand Lorentz

Created attachment 209433 [details]
Additional Screenshot for Debug.log as asked for by Bertrand Lorentz

I added the debug.log, as you asked.

I also attached a screenshot where you can see what I did.
I created a new playlist "test" with those 9 Songs. (1)
I reordered them by name and selected the 5th Track (by Mumm-Ra) (2)
I deleted it and as you can see in the last shot, actually deleted was the Track by "Feist" which was in 5th place before reordering. (3)

Thank you for the quick reply !

From the screenshots, it looks like you have quite a lot of playlists. I'm thinking that might be a factor, as Aaron could reproduce the problem with a new DB.
Could anyone experiencing this issue also indicate how much playlists and smart playlists they have ?

Another test that would help, but make a backup of your database first (it's ~/.config/banshee-1/banshee.db) :
- Delete all your playlists
- Create a new playlist and try to reproduce the problem with it.

The SQL log seems OK to me, here are the relevant parts :

1/ Playlist is renamed
[4 Debug 15:00:37.579] Executed in 1ms 
UPDATE CorePlaylists
SET Name = 'test',
  SortColumn = -1,
  SortType = 0,
  CachedCount = 0,
  IsTemporary = 0
WHERE PlaylistID = 275

2/ Playlist reloaded in the cache, sorted by album title
[4 Debug 15:00:50.707] Executed in 34ms 
DELETE FROM CoreCache WHERE ModelID = 4546;
INSERT INTO CoreCache (ModelID, ItemID) SELECT 4546, EntryID FROM CoreTracks CROSS JOIN CoreArtists,CoreAlbums, CorePlaylistEntries WHERE CoreArtists.ArtistID = CoreTracks.ArtistID AND CoreAlbums.AlbumID = CoreTracks.AlbumID  AND  CorePlaylistEntries.TrackID = CoreTracks.TrackID AND CorePlaylistEntries.PlaylistID = 275
ORDER BY 
  CoreAlbums.TitleSortKey ASC,
  CoreTracks.Disc ASC,
  CoreTracks.TrackNumber ASC

3/ Playlist reloaded in the cache, sorted by track title
[4 Debug 15:01:00.011] Executed in 32ms 
DELETE FROM CoreCache WHERE ModelID = 4546;
INSERT INTO CoreCache (ModelID, ItemID) SELECT 4546, EntryID FROM CoreTracks CROSS JOIN CoreArtists,CoreAlbums, CorePlaylistEntries WHERE CoreArtists.ArtistID = CoreTracks.ArtistID AND CoreAlbums.AlbumID = CoreTracks.AlbumID  AND  CorePlaylistEntries.TrackID = CoreTracks.TrackID AND CorePlaylistEntries.PlaylistID = 275
ORDER BY 
  CoreTracks.TitleSortKey ASC,
  CoreAlbums.ArtistNameSortKey ASC,
  CoreAlbums.TitleSortKey ASC

4/ Track at position 4 (0-based) is deleted
[4 Debug 15:01:14.390] Executed in 48ms 
DELETE FROM CorePlaylistEntries WHERE PlaylistID = 275 AND
  EntryID IN (SELECT ItemID FROM CoreCache
    WHERE ModelID = 4546 LIMIT 4, 1)

5/ Playlist reloaded in the cache
[4 Debug 15:01:14.460] Executed in 33ms 
DELETE FROM CoreCache WHERE ModelID = 4546;
INSERT INTO CoreCache (ModelID, ItemID) SELECT 4546, EntryID FROM CoreTracks CROSS JOIN CoreArtists,CoreAlbums, CorePlaylistEntries WHERE CoreArtists.ArtistID = CoreTracks.ArtistID AND CoreAlbums.AlbumID = CoreTracks.AlbumID  AND  CorePlaylistEntries.TrackID = CoreTracks.TrackID AND CorePlaylistEntries.PlaylistID = 275
ORDER BY 
  CoreTracks.TitleSortKey ASC,
  CoreAlbums.ArtistNameSortKey ASC,
  CoreAlbums.TitleSortKey ASC


So the only way I can see how that would be wrong is if the rows return by the "SELECT ItemID FROM CoreCache WHERE ModelID = 4546" subquery are not sorted by the OrderID integer primary key. This seems to ba always the case in my manual tests.

Created attachment 209438 [details] [review]
Patch to force sorting in the subquery

This patch forces the subquery used to remove tracks to be sorted. This might fix this bug.

Could anyone who can reproduce the problem compile Banshee with this patch and check if it fixes the bug ?

I have 25 custom playlists with 10 to 1500 songs (most around 300). About half of that is dynamic.

I just removed all playlists and restarted banshee. Tried it again with the same songs and the problem persisted.

Your guess is that something in the Subquery of part 4 is incorrect (e.g. not sorted correctly).

Wouldn't it also be possible that somehow step 3 failed and the scheme from step 2 is still referenced.
I don't know whether the debug would throw SQL-errors but just say for whatever reason, "DELETE FROM CoreCache WHERE ModelID = 4546;" failed. Wouldn't then the INSERT fail as well and DELETE of the song would be correct?

I am not familiar with banshee's database layout and the debug-functionality (and how strongly the representation in the GUI resembles the database queries). But this would be the second thing that could go wrong.


What could, now that I think of it, well be part of the issue:
When a song is over and the next one plays, the progress bar does not always reset (it just keeps on adding seconds with the progress slider at the beginning). I have not yet been able to reproduce this consistently but if somehow the gui would not exactly represent the database query, this seems like something that could happen.

nevermind, this is a different bug
https://bugzilla.gnome.org/show_bug.cgi?id=664433
https://bugzilla.gnome.org/show_bug.cgi?id=664402

and seems to be coming from GStreamer.

Created attachment 210053 [details]
Patched library Banshee.Services.dll

I finally found the time to try to reproduce the bug with Aaron's DB (he sent it via email to me a while ago) and even with his same tracks, and haven't been able to reproduce this bug, so this is really a mystery.

Well I guess Bertrand got a bit closer if he produced a patch, so as no one has replied yet to him saying if the patch fixes the bug, I'm attaching here the patched assembly (assuming nobody has tried the patch because they don't have the skills to build Banshee).

So if you read this and you can reproduce this bug, please back up first your Banshee.Services.dll, then replace it with this one, and tell us if it solves the problem! Thanks very much.

I was able to reproduce the bug before consistently (even after cleaning DB). I have tested this patch here and it seems to work! 

(In reply to comment #56)
> Created an attachment (id=210053) [details]
> Patched library Banshee.Services.dll
> 
> I finally found the time to try to reproduce the bug with Aaron's DB (he sent
> it via email to me a while ago) and even with his same tracks, and haven't been
> able to reproduce this bug, so this is really a mystery.
> 
> Well I guess Bertrand got a bit closer if he produced a patch, so as no one has
> replied yet to him saying if the patch fixes the bug, I'm attaching here the
> patched assembly (assuming nobody has tried the patch because they don't have
> the skills to build Banshee).
> 
> So if you read this and you can reproduce this bug, please back up first your
> Banshee.Services.dll, then replace it with this one, and tell us if it solves
> the problem! Thanks very much.

But it seems that I could no longer open mp3 directly by clicking once this patch is applied.....

(In reply to comment #57)
> I was able to reproduce the bug before consistently (even after cleaning DB). I
> have tested this patch here and it seems to work! 
> 
> (In reply to comment #56)
> > Created an attachment (id=210053) [details] [details]
> > Patched library Banshee.Services.dll
> > 
> > I finally found the time to try to reproduce the bug with Aaron's DB (he sent
> > it via email to me a while ago) and even with his same tracks, and haven't been
> > able to reproduce this bug, so this is really a mystery.
> > 
> > Well I guess Bertrand got a bit closer if he produced a patch, so as no one has
> > replied yet to him saying if the patch fixes the bug, I'm attaching here the
> > patched assembly (assuming nobody has tried the patch because they don't have
> > the skills to build Banshee).
> > 
> > So if you read this and you can reproduce this bug, please back up first your
> > Banshee.Services.dll, then replace it with this one, and tell us if it solves
> > the problem! Thanks very much.

(In reply to comment #58)
> But it seems that I could no longer open mp3 directly by clicking once this
> patch is applied.....

Jennifer, did you apply the patch by modifying the source and recompiling, or by using the Banshee.Services.dll provided by Andrés ?

The patch itself shouldn't impact playing files, but the file provided by Andrés might not work right on your system (version mismatch maybe).

I used Andres' .dll file....perhaps that is why...

(In reply to comment #59)
> (In reply to comment #58)
> > But it seems that I could no longer open mp3 directly by clicking once this
> > patch is applied.....
> 
> Jennifer, did you apply the patch by modifying the source and recompiling, or
> by using the Banshee.Services.dll provided by Andrés ?
> 
> The patch itself shouldn't impact playing files, but the file provided by
> Andrés might not work right on your system (version mismatch maybe).

This problem has been fixed in the development version. The fix will be
available in the next major software release. Thank you for your bug report.

I've committed my patch in git master. Feel free to re-open this bug if you can still reproduce the problem with that patch applied.

*** Bug 674763 has been marked as a duplicate of this bug. ***