FS#7967 - New live moving of playlist

Attached to Project: Rockbox
Opened by Daniel Siebrecht (DimensionSix) - Monday, 15 October 2007, 21:07 GMT
Last edited by Jonathan Gordon (jdgordon) - Wednesday, 08 July 2009, 00:41 GMT
Task Type Bugs
Category Playlists
Status Closed
Assigned To No-one
Operating System All players
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


Sometimes, one item of the playlist is moved when you go to the move function of the playlist viewer.
I don't know, in which cases this happens but I've made screenshots when noticing it the first time. Picture 1 shows the item I wanted to move and Picture 2 shows how it looks when moving the item.
This task depends upon

Closed by  Jonathan Gordon (jdgordon)
Wednesday, 08 July 2009, 00:41 GMT
Reason for closing:  Accepted
Additional comments about closing:  r21708
Comment by Daniel Siebrecht (DimensionSix) - Monday, 15 October 2007, 21:16 GMT
I forgot something. The item with the selection bar is the one I can move and this is not the one I chose to move. The problem occurs now in the complete playlist, but every item has another "defined" item that is on the wrong position when moving.

With the latest playlist I didn't have the problem. It worked great. The only thing was that the icon moved more slowly than the selection bar.
Comment by Nicolas Pennequin (nicolas_p) - Monday, 15 October 2007, 21:17 GMT
I'm not sure I understand your description, but are you aware of, which is  FS#7958 ?
Now when you want to move a track in the playlist, the item actually move to its new position realtime until you confirm the change.
Sorry if you know it already, but I couldn't see what's wrong from your description or screendumps.
Comment by Antoine Cellerier (dionoea) - Monday, 15 October 2007, 21:27 GMT
That commit might have fixed your problem (due to the gui_synclist_draw call added on line 640 of apps/playlist_viewer.c). Can you try updating your rockbox build and see if the problem is gone?
Comment by Daniel Siebrecht (DimensionSix) - Monday, 15 October 2007, 21:28 GMT
Yes I know this.
The first screenshot shows the song I want to move on position 2. I go to the context menu and choose the option "move". Now it shows the playlist like on screendump 2. The item from position 8 is now on position 2. The item I want to move is on position 3 but I didn't move it. Now, the item from position 2 is the one I can move (it moves in realtime). But it isn't the one I want to move. The icon is the only thing which is marks the right item.

And I'm very sorry for my bad descriptions and for my english, too.
Comment by Daniel Siebrecht (DimensionSix) - Monday, 15 October 2007, 21:36 GMT
So I updated my build. It took me some time to reproduce the bug but now I know whats causing this.
You have to enable shuffle. Without shuffle everything works as expected but when you enable it, you should get this bug!
Comment by Daniel Siebrecht (DimensionSix) - Monday, 22 October 2007, 17:46 GMT
Could someone reproduce this?
I don't know if the problem occurs with shuffle enabled in the current builds, but I get this bug very often, e.g. in reshuffled playlists.
Comment by Daniel Siebrecht (DimensionSix) - Monday, 26 November 2007, 16:09 GMT
For the clearness I reproduced the bug and made a screendump of mostly every screen. These dumps are attached as an animated gif.
The second attachment is a picture of two screens: The playlist before entering the "move" screen and the move screen.
The third attachment is like the second. It shows the display before confirming the move action and after.

I hope this helps you to reproduce this bug.

For me, this bug still occurs in the latest build, also with a "clean install". (H320)

Also happens on H10 of my brother with the latest build!
Comment by Marc Guay (Marc_Guay) - Tuesday, 08 July 2008, 04:24 GMT
Confirmed on the H300 w/ r17939, but it works fine on the e200.
Comment by x (vmh) - Friday, 11 July 2008, 06:07 GMT
> Confirmed on the H300 w/ r17939, but it works fine on the e200.
I would say this bug is player independent. Maybe you tried to move a track which index after shuffling has the same as unshuffled. Try to move different tracks in shuffle mode. I'm sure you will also see this bug on your e200.

Here I have patch to partially fix this problem:
In normal (unshuffled) mode the displayed index of a track is the same as stored. The code for moving a track doesn't consider that the displayed and the stored index can be different.
In the patch I added a new variable to distinguish between both. Now the visual moving is fixed, but after confirming, sometimes the track is put below or above the selected position. I guess the remaining problem is in playlist_move().
Comment by Marc Guay (Marc_Guay) - Friday, 11 July 2008, 11:50 GMT
You're right, I do see this on the e200. Sorry for the misinformation.
Comment by Michael Carr (Strife89) - Thursday, 14 August 2008, 12:39 GMT
Yep, target independent. This bug affects my c250....
Comment by Marianne Arnold (pixelma) - Wednesday, 20 August 2008, 18:28 GMT
I also experience this bug sometimes and now made the following observation which might help to track down the problem.

In general I don't use the shuffle mode (globally) but use "insert shuffled" every now and then to extend my playlist which sometimes results in this bug being visible and sometimes not. Now it seems that I found a pattern to this.

Here's what I do:
- start a dynamic playlist by chosing a song in a folder (shuffle mode of, recursively insert on - in case that matters)
- insert one other track by chosing "insert shuffled" from the context menu
=> if that track randomly ends up before the last track, then there won't be a problem
=> if it ends up as new last track, the moving line display will show the name of the one track above in the highlighted line
- every track which gets added using "insert shuffled" and ends up after the last track (of the original playlist) will add to the offset
- "insert" or "insert last" do not have this effect even when inserting after it already is off by one (these won't add to it)

So far I only thought that the displaying is broken because (maybe I'm wrong though):
- the speaker icon is always at the correct spot
- if I abort the moving by pressing left, the correct track will be highlighted again
- in my case I actually move the correct track, I only need to ignore that it displays the wrong one during the move - except I can't move it to the last position

Does that ring a bell? Does it match the findings which lead to the patch? (Which I still need to try, I admit.)
Comment by Clément Pit--Claudel (CFP) - Tuesday, 02 September 2008, 08:41 GMT
Ok, I guess this is the same as my bug report  FS#9335 . However, maybe the title of this task should be changed as I could'nt find it through the search function before posting mine. I'll copy here the text of my report so that it can be closed to avoid duplicates :
I recently encountered a quite annoying bug :
-> Go to Database, Artist, All, and play a file. Wait for all the files to be added (this is not needed though, the bug still appears if you stop the creation of the playlist)
->Now try to edit the current playing list by moving songs around.

When selecting the song, another playlist entry appears just before the actually selected one and gets moved instead of the right one. When you validate the move, it disappears and gets replaced by the track you wanted to move.
Furthermore, if you cancel by pressing 'back' button, the cursor jumps to the actual position of the track that had appeared. Sometimes, an empty tack is inserted, probably because the part of the playlist it comes from has not been loaded yet. Only verified on Gigabeat, not tested on other targets.


Comment by Dave Hooper (stripwax) - Wednesday, 01 July 2009, 22:55 GMT
Can confirm that bug is still present on recent builds. Tested the above patch and agree that the visual moving of the track now works correctly but indeed the track *sometimes* gets moved to the wrong location (i.e. not the location you actually picked). Very curious that it doesn't even consistently go to a different location than the one you picked. It *often* goes to the right place.

I'm using the following easily reproducible scenario (i.e. easily reproduces the *original* problem even on simulator; does not consistently reproduce the incorrect-move on a patched build)
1. Play a track from an album with plenty of tracks. If you need to erase a dynamic playlist to do it, so be it. Playlist will get created with all tracks of the album and playback will begin from track 1
2. While playing track 1 still, reshuffle playlist
3. Now go to the playlist viewer and trying moving any track (for best bet try any track that is not in its correct sorted position)

Comment by Dave Hooper (stripwax) - Thursday, 02 July 2009, 00:30 GMT
So in looking at this I discovered a couple other oddnesses-
1. If you delete the last item in the playlist, then the selection disappears - this is due to incorrect condition in playlist_viewer.c should be looking at ret_val instead of ret
2. If you delete everything in the playlist, and then back out of the playlist viewer and hit Resume Playback, it shows playing track 1 of 0, and freezes. It's not a hard freeze, just says it's playing when it's clearly not.

The first is an easy fix. The second I'm not sure about, we could either reset global_settings.resume_index = -1 somewhere inside playlist_viewer, or make the playlist_delete function, or something called by that, do this automatically. Anyone have an opinion on where best to do that? I'm thinking update_playlist in playlist_viewer looks reasonable, since we get there if we delete an item. Then in the if( viewer.num_tracks <= 0) we also reset global_settings.resume_index=-1 (and global_settings.resume_offset = -1 ?).
Proposed patch attached (this is a separate patch to above, just to demonstrate the above two issues)

Comment by Dave Hooper (stripwax) - Thursday, 02 July 2009, 23:04 GMT
Ok, committed both the above patch (for the weird behaviour on deletion) and the patch above by Vuong Minh Hiep (with a small amount of variable renaming for consistency) to fix the track moving issues in playlist viewer
Comment by Dave Hooper (stripwax) - Tuesday, 07 July 2009, 22:16 GMT
I think I have also observed the above-described issue where the move sometimes moving the selected track to one entry before or after where it's supposed to. For me it seems to be reproducible if moving one track from before the currently-playing track to after the currently-playing track (or vice versa). I need to confirm and reproduce but should have a fix for that if so. I also have a fix for a regression I inadvertantly introduce in my latest commit (being that the moving array shows occasionally even when no Move is in progress - uninitialised variable in my commit)
Comment by Dave Hooper (stripwax) - Wednesday, 08 July 2009, 00:20 GMT
Fix for the playlist_move issue: someone please test and confirm? Essentially the playlist_move would move to the wrong location if the new location wraps around the playlist indices (i.e. if we were moving index 6 to location 9 on a playlist of ten items, we would rotate index 9 to index 0 and move the item to 1 place after where it should be, due to the rotate calculation tooking place AFTER the item to be moved has been removed from the playlist at which point the playlist has 9 items not ten). Hopefully that description makes sense; if not please try the patch, shuffle a playlist, and try moving the top item in the playlist to any/all of the other slots (by which I mean, move the top item to a new slot; then move the NEW top item to a new slot rather than the one you moved previously; keep moving the one on the top); if that works try same using the second-top item. That should be sufficient I think.
Comment by Dave Hooper (stripwax) - Wednesday, 08 July 2009, 00:32 GMT
Patch committed in r21708