diff options
author | Christian Soffke <christian.soffke@gmail.com> | 2023-11-05 02:32:39 +0100 |
---|---|---|
committer | Christian Soffke <christian.soffke@gmail.com> | 2023-11-11 00:36:14 +0100 |
commit | e9b4275d1f5b8d166fa772242af44b4d056ed482 (patch) | |
tree | 99fb350cf3fc8029954ef04cb1ce6257f7db8d66 /apps/gui | |
parent | dd1063fc2ccc5c254ee018398c0162cccd549018 (diff) | |
download | rockbox-e9b4275d1f5b8d166fa772242af44b4d056ed482.tar.gz rockbox-e9b4275d1f5b8d166fa772242af44b4d056ed482.zip |
Playlists: Fix resuming from control commands with first_index > 0
add_track_to_playlist_unlocked only increased a playlist's
first index as necessary when its position parameter was
negative (i.e. one of the special insert positions was
specified).
A negative value was not stored in the control file, but
was always converted into an absolute position. Thus, any
adjustments to first_index weren't repeated when resuming
from the control file.
In particular, shuffled playlists were affected (in case of
first_index > 0), when inserting at positions <= first_index,
including appending a track to the end of a playlist. This
works by inserting at first_index and increasing first_index
by 1 afterwards.
Similarly, adding tracks in a shuffled fashion could increase
first index, whenever that was the value randomly calculated
for a track position, effectively appending it (I assume this
is on purpose).
To make sure that first_index adjustments are recovered when
resuming from the control file, and to be able to differentiate
between a prepended or appended track, store the special value
PLAYLIST_INSERT_LAST_ROTATED as the insert position in the
control file whenever first_index would have been used before,
and a special position (other than PLAYLIST_PREPEND) was
provided to the function.
Change-Id: I31f26796627fb136daeddd046cb1892bdf1b4014
Diffstat (limited to 'apps/gui')
0 files changed, 0 insertions, 0 deletions