Support and General Use > Audio Playback, Database and Playlists
playlists start over
fredex:
Guru:
All my playlists have the absolute path to the audio files, e.g:
/<microSD1>/AUDIOBOOKS/Lois-Mcmaster-Bujold/TheSharingKnife/Beguilement/The Sharing Knife, Vol. 1 Beguilement (Unabridged) [File 01 of 19].mp3
I made a directory named "Playlists" on the root of the builtin storage. all the audio files go in a directory tree on the microSD card. the program I use to generate the playlists is coded to use the runtime path instead of the path of the folder when it is mounted as a Linux filesystem, so if the SD card is mounted as "/run/media/fredex/AUDIOBOOKS/... it replaces the "/run/media/fredex" with "/<microSD1>" which works fine on dozens of playlists.
and, I just recently played thru one of the playlists that always misbehaves, and this time it worked fine. Go figure!
Thanks for the idea.
Fred
TheAlmightyGuru:
Interesting, it seems like the problem isn't just related to absolute or relative paths, I wonder if there are two similar issues.
I just updated to the latest build, but I'm still seeing the same behavior with absolute versus relative pathing on mine. A relative path playlist -always- loses its place and resets to the beginning of the first track when I shut off my ClipZip while an absolute path playlist properly remembers the track and position.
If you have time, could you test this behavior on yours? Here is my file structure:
.\
---absolute.m3u
---relative.m3u
---MUSIC\
------song1.ogg
------song2.ogg
absolute.m3u contains the following lines:
MUSIC\song1.ogg
MUSIC\song2.ogg
relative.m3u contains the following lines:
.\MUSIC\song1.ogg
.\MUSIC\song2.ogg
To perform the test, here is what I did:
Absolute
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 the ClipZip by pressing power.
4.) Turn on the ClipZip with the power button.
5.) song2.ogg continues to play from the same track location as when it was shut off.
Relative
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 the ClipZip by pressing power.
4.) Turn on the ClipZip with the power button.
5.) song1.ogg plays from the very beginning.
Thanks!
jhMikeS:
Sure, I'll try it ASAP. Those are all relative paths since the don't start with "/" (root). The only difference is the explicit current-directory dot.
I do have a playlist with paths of the form "./a/b/c/d.xxx" (and "a/b/c/d.xxx", "/a/b/../c/d.xxx", etc.) and the tracks do in fact resume just fine. It was created for the purpose of testing path code and playlist behavior with new file code. The only difference it is a mix of various path forms.
Will get back to you.
TheAlmightyGuru:
Thanks jhMikeS! :)
TheAlmightyGuru:
I found something new that might help you in the debug process.
First, as you pointed out, proper absolute pathing requires starting with a root. I tried the following, and both songs are properly remembered:
\<microSD1>\Music\Artist\Song 1.ogg
\<microSD1>\Music\Artist\Song 2.ogg
I also tried using a relative double-dot parent path; both songs forget, just like a single dot:
..\Music\Artist\Song 1.ogg
..\Music\Artist\Song 2.ogg
Next, I tried a mixed playlist like this, and 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, 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!
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version