- Status Closed
- Percent Complete
- Task Type Bugs
- Category Playlists
- Assigned To No-one
- Operating System Sansa Clip Zip
- Severity Medium
- Priority Very Low
- Reported Version Daily build (which?)
- Due in Version Undecided
-
Due Date
Undecided
-
Votes
1
- TheAlmightyGuru (2017-12-26)
- Private
Opened by TheAlmightyGuru - 2017-11-13
Last edited by speachy - 2021-09-20
FS#13136 - Playlist position not saved on shutdown when using relative file paths.
Ordinarily, when Rockbox is shut off and turned back on, it will remember the position in the last-played song, and begin playing from where you left off. However, in the latest build, Rockbox doesn’t remember the last track that was playing if the file used a relative path. This happens on every version of 3.14 including the current daily build (2017-11-13).
Here is how the error can be reproduced:
Have a folder with two songs. Then, in the parent folder, create two m3u playlists named “absolute.m3u” and “relative.m3u”.
.\
—absolute.m3u
—relative.m3u
—MUSIC\
——song1.ogg
——song2.ogg
In the absolute.m3u playlist, add the following lines:
MUSIC\song1.ogg
MUSIC\song2.ogg
In the relative.m3u playlist, add the following lines:
.\MUSIC\song1.ogg
.\MUSIC\song2.ogg
To see expected behavior:
1.) Open the files list, and run absolute.m3u and song1.ogg begins playing.
2.) Push right to start song2.ogg. Let it play a few seconds in.
3.) Turn off your device by pressing power.
4.) Turn on your device with the power button.
5.) song2.ogg continues to play the same song at the same location as when it was shut off.
To reproduce the bug:
1.) Open the files list, and run relative.m3u and song 1 begins playing.
2.) Push right to start song2.ogg. Let it play a few seconds in.
3.) Turn off your device by pressing power.
4.) Turn on your device with the power button.
5.) song1.ogg plays from the very beginning.
The file format of the songs doesn’t seem to matter (I’ve tested ogg and mp3).
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
I found something new that might help the debug process:
Using absolute pathing, both songs are properly remembered:
\<microSD1>\Music\Artist\Song 1.ogg
\<microSD1>\Music\Artist\Song 2.ogg
Using a relative double-dot parent path; both songs forget, just like with a single dot:
..\Music\Artist\Song 1.ogg
..\Music\Artist\Song 2.ogg
In a mixed pathing playlist, unexpectedly, both songs are properly remembered, even the relative path:
\<microSD1>\Music\Artist\Song 1.ogg
.\Music\Artist\Song 2.ogg
But, interestingly, when I reverse the order, the second song is remembered, but the first song is not:
.\Music\Artist\Song 1.ogg
\<microSD1>\Music\Artist\Song 2.ogg
I'm guessing that, when a playlist is loaded, a flag is supposed to be set. In version 3.13, the flag was always set no matter what path type was used. However, in 3.14 and above, something was changed so that the flag would not be set on a line that begins with a dot.
This would explain why my third test remembers the position of the relative path track (because a non-dot path track was played first and set the flag), and also why in my fourth test the relative path track did not work (because a non-dot path track had not been played to set the flag). And also why in my previous tests a path without a slash or dot would be remembered properly.
I hope this helps!
I noticed the same issue caused by playlist entries having relative paths. Here is an attempt to fix this bug.
This has been fixed in master. Thank you for the patch!