Rockbox Technical Forums
Rockbox General => Rockbox General Discussion => Topic started by: fredex on April 28, 2014, 09:26:00 PM
-
In the last few days my Sansa Fuze (Rockbox 3.13) has changed behavior. used to be when I turned it off, when I came back to listen (perhaps days) later, selecting "resume playback" from the main menu would pick up where it was when I shut it down. But now, suddenly, it always starts playing at the beginning of the first file in the playlist I was playing.
Having spent an hour or more digging in the manual and playing with settings, I cannot make it work the way it did before.
I'd welcome suggestions on how to resolve this, thanks!
-
Post /.rockbox/config.cfg for us to review.
[Saint]
-
I had kind of the same issue, where rockbox would always start from the same file in the playlist even if I went and change track and turn off the DAP and turn it back on, it would always start from the same file. I fixed it by resetting the settings to "Resume Playback" in Settings -> General Settings -> Startup/Shutdown -> Resume Playback, even if it was already set to that.
I believe the problem happens when you add new tracks to the player and turn it back on, it screws itself over, even if the playlist was updated.
EDIT
Never mind, it did not fix it.
Chose a random song in the playlist called "Raging River". Fast forwarded a bit into the song and powered off my Fuze. Immediately powered it on again to find out that it started on a song called "Eagleheart" which is much farther in the playlist. I'm seriously considering downgrading to 3.9 where I didn't have this issue.
EDIT 2
Sure enough. I downgraded to 3.9 and there we go! The behavior I want!
-
I just tried this several times in the current build using both the file browser and the database and everything worked as expected, so if it was present in 3.13, its apparently been fixed since then.
-
this problem seems to be intermittent... sometimes it goes to the right place when I resume playing, sometimes it doesn't. but here's t he config file you [saint] asked for...
# .cfg file created by rockbox 3.13 - http://www.rockbox.org
volume: -15
backlight timeout plugged: 15
invert: on
flip display: on
selector type: bar (inverse)
statusbar: off
backlight filters first keypress: on
scroll delay: 600
bidir limit: 75
foreground color: 000000
background color: FFFFFF
rec mic gain: 21
beep: weak
rewind duration on pause: 10
font: /.rockbox/fonts/20-Profont-basil.fnt
wps: /.rockbox/wps/BIG-fuze.wps
backdrop: -
button light timeout: 8
resume rewind: 10
-
Not solved, but I have a little more news:
Since the Fuze was misbehaving anyway (phone jack has become very intermittent) I bought a new ClipZip (and installed RockBox). The bad news is that the problem in restarting a playlist after a power off still occurs, intermittently.
What I didn't say was that I've got a 32-gig card in the micro-sd slot, and it's fairly full. I've been reading lately that there are some limitations on how many files can be cataloged in the database, so I wonder if somehow something has caused this playlist to suddenly fall into the category of files that no longer work.
I dunno, but anyone got any more thoughts?
thanks!
-
There are indeed a few limits in Rockbox, but most people will find them sufficient I would think.
By default, Max Entries in File Browser is set to 1,000 (but this is per-directory, and does not include sub-directories), as the name suggests this only affects the File Browser, and there is also Max Playlist Size which is set to 10,000 entries by default.
The 1,000 files per directory default is more than generous for most people's use case, unless you are one of those people that keeps literally thousands of files in a single directory...but even if you are this limit can be raised. 10,000 tracks per playlist may not be enough for everyone if they are wanting to add all their media to a single giant playlist, but this limit can easily be increased as well.
[Saint]
-
Saint, thanks for the reply.
So, I'll clarify a bit. I keep each album/book/thing in its own subdirectory. In the case of the specific playlist I'm having trouble with, it contains 30 mp3 files, all in the same subdir with nothing else at all except a copy of the .m3u file.
that playlist has been on the SD card for a year or two, and has been listened to multiple times (at least a half-dozen) without trouble, til recently.
probably the biggest playlists on the player is one on the SD card of around 300 files (complete Bach organ music), and one (on the old Fuze, not yet moved to the ClipZip) of music files, which is 183 files (about 7 gigs). Otherwise
So far, I've had this trouble ONLY with that one playlist.
So, I shouldn't be encountering any of those limits.
Having been reading the RockBox manual, it's still not clear to me how the restart-after-power-off "resume playback" actually is implemented. I think I saw something about it's stored as a temporary bookmark, rather than as some attribute in the database. Can you enlighten me on that?
Thanks for your attention.
Fred
-
I just tried resuming a playlist on the Clip Zip at random positions a number of times, and could not get it to fail. I'm using today's build. Which build are you seeing this problem in?
-
latest release, which is, as far as I remember 3.13. (the same release was in use on both the players where I had this problem.)
so far I've seen this only on a single playlist, but I haven't done an exhaustive study.
-
latest release, which is, as far as I remember 3.13. (the same release was in use on both the players where I had this problem.)
What happens if you try today's build?
-
that would be the clip zip build on build.rockbox.org?
and is there any special technique to revert to 3.13, should I want/need to?
-
that would be the clip zip build on build.rockbox.org?
Yes, or you can use rockbox utility to update.
and is there any special technique to revert to 3.13, should I want/need to?
Just download that build, or use rockbox utility to install 3.13. Equivalently, you can copy the build off your player and keep it on your PC if you don't want to download it again.
-
OK, lemme try it. I'll get back to you.
-
Well, no good news. I get the same result.
-
Whats the exact build? And do I need to do anything beyond powering off and then back on to reproduce it?
Edit: Actually, if you could concisely explain how you reproduce this bug it would be helpful. Just stopping an arbitrary playlist and rebooting does not seem to be sufficient to trigger it.
-
from the rockbox info screen: 355b540-140509
It occurs for me whether I pause then power off, or just power off. it's weird 'cause once in a while (not often) it comes back where I left off.
I just tried (a few mins ago) to reproduce it with another playlist, but so far it works fine for other lists. Weird thing is I've played this audiobook from the same playlist multiple times in the past without trouble. In case something is wrong with the mp3 files, I've re-copied the files from my PC, but no go.
-
dunno if this means anything in the context of my reported issue (My guess is that it does not), but twice since installing the dev build I've gotten this error while pressing the select button (and holding) then plug in the USB cable:
Data abort at 30
FSR 0x8
(domain 0, fault
address 0xDEADBE
pc: 30042890 sp:3
shown exactly as it appears on the screen. it appears that stuff is truncated on the right...
I haven't seen this with 3.13, but I can't categorically state that it couldn't happen there, this is a new player for me.
should this report go to the bug tracker too?
-
I tried this experiment:
-copy the files (for the playlist in question) from <microsd1> to /AUDIOBOOKS/foo
-modify the playlist to point to the new location
-play it, stop, resume playback, stop, resume playback, lather, rinse, repeat...
and so far it hasn't failed.
So now I'm running badblocks on the SD card. (though I don't expect it to fail, we'll see).
-
as I suspected, badblocks has no complaints with the 32 GB SD card.
so I did another experiment: I copied a subset of the directory tree from my AUDIOBOOKS folder onto another SD card, making sure the audiobook exhibiting the problem was one of the things copied.
Using that copy of the SD card, I can reproduce the problem on both players (i.e., the old Fuze, and the new Clip Zip). (the FUZE is running 3.13, and the Clip Zip is still running the daily build 355b540-140509).
Saratoga, you're one of the RockBox developers? Would there be enough interest in looking at this problem for me to mail you one of my players with the copied SD card, so you can see if you can re-create the problem??? (assuming I'd get them back, someday).
-
I've downgraded Rockbox on my Fuze v2 from 3.13 to 3.9.1, which is what I ran on it for a couple years before being updated to 3.13.
I can't recall exactly when this problem first came to my attention, but I apparently did the 3.9.1==>3.13 upgrade in Jan of '14, and I certainly never had the problem before that.
So, now with 3.9.1 back on the player, I've shut down and done "resume playback" 8 or 10 times and so far it always resumes in the right place. (Using the same playlist and SD card on which it was routinely failing on 3.13, yesterday.)
So, whatever is causing it, it looks as if it's due to something that changed after 3.9.1.
I may do a binary search thru old versions to see if I can pin down the exact point.
-
I've got 3.11.2 on the Fuze now, and haven't been able to make it fail. I've been starting and stopping it several times a day for the last four (or so) days, with zero failures.
So, if there's any developers reading this: How else can I help to find/solve this problem? The fuze is now old and has a flaky headphone jack, and I have a new Clip Zip, so I can spare the Fuze, shouuld someone want to use it to troubleshoot (assuming I'd get it back someday).
Any further ideas, or any takers on my offer?
Now, as I said, I've got a new Zip Clip, which exhibits the same problem, running 3.13. unfortunately, I can't fall back to 3.11.2 on the Clip Zip since 3.13 is the only stable release on offer. This gives me some impetus to help solve the issue.
thanks in advance!
-
Assuming you aren't intending to fix it yourself, you could suggest a way for someone else to reproduce the problem. Otherwise no one else is going to look at it.
-
well, I could try slogging thru the code to see if I could even find the place(s) that deal with bookmarking and restarting. Is there, perhaps, a document somewhere that gives some intro to the organization of the source code?
I attempted to give you all the details of how it was happening, but since you couldn't reproduce it, it seemed to me that since Ihave two players, both of which illustrate(d) the problem, I could send you (or someone) one of them so you could see it happening.
I understand it's an open-source project, and nobody has to do anything for me. So, I was trying to be helpful to the extent I could. My apologies if it seemed otherwise.
-
I don't think you need to look at the code; I'm just suggesting that you massively improve the odds of someone being able to help you if you can suggest a way to reproduce the problem.
Edit: Sorry, to not answer your other question. Some very general information is available in this wikipage: http://www.rockbox.org/wiki/ContributingToRockbox
-
Could you please verify that the file system of both the internal and external storage is intact?
[Saint]
-
Saint, I ran "dosfsck -Vaw" (from linux) on both devices while the player was plugged into USB. The built-in "drive" on the clip-zip reported some errors with reported sizes of things and did some cleanups, but the removable SD card was clean (and that's where the files that have exhibited the problem live).
Did the same thing on the FUZE v2 and the only errors reported were "FAT 1 and 2 are different sizes", but I cleaned those up too.
I'll post back here if the problems recur.
-
Saint, I ran "dosfsck -Vaw" (from linux) on both devices while the player was plugged into USB. The built-in "drive" on the clip-zip reported some errors with reported sizes of things and did some cleanups, but the removable SD card was clean (and that's where the files that have exhibited the problem live).
The internal drive is where all playback state is kept, so that's the one that matters.
-
Sorry that this is quite an old thread but I've been having the same problem on my Clip+ with a 32gb card and thought the rest of this topic would still be relevant. I can reproduce it every time I've tried following these steps:
1. Navigate to the 1st track of an album on the memory card using the file browser and press "right" to play the album.
2. Navigate to the folder of an album on the internal memory using the file browser and add the album to the playlist by holding the select button and picking "Insert Last".
3. Return to "Now Playing" and skip (or play) through to a track on the second album.
4. Turn the player off and back on.
5. Resume playback and the whole playlist will still be there but playing right from the start.
There is no problem if I restart the player during the 1st album or if both albums are on the card or both albums are on the player or if the 1st is on the player and the 2nd on the card.
There have also been a couple of occasions where playback has resumed from the start of the previous dynamic playlist or albums have played in a different order than I loaded them but I haven't been able to reproduce that.
If anyone is looking into this I'll try to help as best I can. Thanks!
-
In the last few days my Sansa Fuze (Rockbox 3.13) .../...
Now, as I said, I've got a new Zip Clip, which exhibits the same problem, running 3.13 ..../...
Sorry that this is quite an old thread but I've been having the same problem on my Clip+ with a 32gb card and thought the rest of this topic would still be relevant. I can reproduce it every time I've tried following these steps:
1. Navigate to the 1st track of an album on the memory card using the file browser and press "right" to play the album.
2. Navigate to the folder of an album on the internal memory using the file browser and add the album to the playlist by holding the select button and picking "Insert Last".
3. Return to "Now Playing" and skip (or play) through to a track on the second album.
4. Turn the player off and back on.
5. Resume playback and the whole playlist will still be there but playing right from the start.
There is no problem if I restart the player during the 1st album or if both albums are on the card or both albums are on the player or if the 1st is on the player and the 2nd on the card.
There have also been a couple of occasions where playback has resumed from the start of the previous dynamic playlist or albums have played in a different order than I loaded them but I haven't been able to reproduce that.
If anyone is looking into this I'll try to help as best I can. Thanks!
I never had that problem so I tried 1~5 on my Clip zip and did NOT get any problem : the playing resumed where I stopped the player. It sounds silly to make such a simple suggestion but have you check the Settings> /Bookmarking ; /Startup & Shutdown ?
My config.cfg file is as follows:
# .cfg file created by rockbox 3.13 - http://www.rockbox.org
volume: -33
backlight timeout plugged: 30
statusbar: off
scrollbar: off
scrollbar width: 3
volume display: numeric
battery display: numeric
idle poweroff: 5
max files in dir: 3000
car adapter mode: on
backlight filters first keypress: on
brightness: 3
scroll delay: 1500
bidir limit: 25
scroll step: 4
foreground color: 738A8C
line selector start color: 4A5552
line selector end color: 000000
line selector text color: FFFF29
volume fade: off
start directory: /Music/
show files: all
show filename exts: on
follow playlist: on
recursive directory insert: ask
autocreate bookmarks: on
autoupdate bookmarks: on
autoload bookmarks: ask
use most-recent-bookmarks: unique only
talk menu: off
rec format: mpa3
tagcache_ram: on
show path in browser: full path
fmr: /.rockbox/fmpresets/Lausenaz.fmr
fms: /.rockbox/wps/clock_lock2_zip.fms
font: /.rockbox/fonts/10-Artwiz-Snap.fnt
wps: /.rockbox/wps/zipplus SMM.wps
sbs: /.rockbox/wps/Classic Clip UI SMM.sbs
backdrop: /.rockbox/backdrops/black.bmp
start in screen: previous
viewers iconset: /.rockbox/icons/viewers.bmp
playlist catalog directory: /<microSD1>/Playlists
qs top: backlight timeout
qs left: show files
qs right: follow playlist
qs bottom: brightness
root menu order: shortcuts, wps, files, settings, radio,
-
I reported this a long time ago as FS#12864.
-
First of all, just want to say that I love Rockbox. It has turned my cheap Clip+ into a mighty music powerhouse.
But, I think I'm having the same problem that these guys are having with the new version (3.13). My config.cfg file:
# .cfg file created by rockbox 3.13 - http://www.rockbox.org
volume: -24
start directory: /<microSD1>/
autocreate bookmarks: on
autoupdate bookmarks: on
autoload bookmarks: on
use most-recent-bookmarks: on
autoresume enable: on
database scan paths: /<microSD1>
tagcache_autoupdate: on
fmr: /.rockbox/fmpresets/preset01.fmr
start in screen: wps
playlist catalog directory: /<microSD1>/Playlists
Semitone pitch change: on
Maybe I'm not understanding the way that bookmarks and autoresume work, and how they interact with one another. Basically, what I want is to be able to pause at any point in a playlist (dynamic or preset), and then either turn off my device manually or allow it to turn itself off automatically, and then have playback automatically resume at the same point in the same track where it left off.
It seems like sometimes it will behave in the desired manner, but sometimes it will just restart the playlist from the beginning. If I let it play from the beginning of the playlist, then sometimes it will get to the track where I had paused and resume that track. I'm assuming that it's not just a "random" behavior, and that there are some specific conditions when this happens. But, it seems to be a somewhat complex set of conditions and I'm finding it difficult to tease out the cause.
I realize that Rockbox has a LOT of customizability, and I appreciate that. But for this particular aspect, I just want my device to behave "normally". What would be the sane, "express" settings to achieve this?
-
You should update your build, even if it doesn't fix the issue you're talking about, update it anyway.
The release build is very far from new, you're missing out on the better part of two years worth of bugfixes and improvements.
[Saint]
-
Alright, I'll try that when I get home tonight. Should I just use the latest nightly build, or is there a build that is considered "stable"?
Also, I'm not sure but I think this issue might be related to the "auto power down" feature. I think it might only happen when I pause a playlist, leave it alone, and then Rockbox automatically shuts down. Then when I turn it back on, the playlist starts over from the beginning. I'll try to test this a little more rigorously.
-
Ok, I tried a few experiments:
Experiment #1:
Database->Albums->Select Track
Play for a while
Pause
Wait for auto-shutdown
Turn player back on
Playlist resumes as expected
Experiment #2:
Playlist Catalogue->Select Playlist
Play for a while
Pause
Wait for auto-shutdown
Turn player back on
Playlist starts over at beginning
It is important to note that this only happens when I start playing a playlist that hasn't already bookmarked itself in some other way, such as if I paused the playlist and then started playing another playlist. In that case, when I go back to the playlist it seems to resume where it left off (which is usually what I don't want to happen in that case, ironically).
Does Rockbox keep track of my position in a playlist exclusively through bookmarks? Or, is there some other way?
-
after a loooong hiatus, I can add a little more information:
this problem restarting from power off does not occur with every playlist (re-reading above I see that I was not clear on that). Some books seem to do it a lot, and once they start doing it I"m at a loss as to how to fix it.
however: the play lists for these books are just a straight listing of filenames that seem to naturally sort into the correct order (alphabetical/numeric sort seems to be the default on rockbox), so that if instead of using the playlist, I go to the directory where the actual files are stored and play the first one, then all the rest properly play in order no matter how many times the player is paused or powered off/on.
I've also tried the (then) latest dev builds 2 or 3 times with my fingers crossed, but no joy: the issue will still occur.
-
First, I love rockbox, too: file support, vorbis ...
I’ve got the same problem on my SanDisk+. And it’s still there with 3.14 and also wasn’t before I updated to 3.13 (I guess) some years ago. (Unfortunately I don’t know which firmware I used before.)
Here are some hints from my direction, because now we may find what Fredex, Alexweissman and I have common.
Like they said, it sometimes works like intended and often doesn’t. Then it resumes with the first track of the list.
I tried it with m3u (ANSI) and m3u8 (UTF-8) lists, with characters like apostrophe, with blank line at the end and without, to see if that’s the problem. I made a simple m3u list within the same folder like the files (so no path, just the filenames). It happens in all different cases.
Sometimes it happens only on one song. I can reproduce it by always going forward to THAT song, pressing Power to stop and “Resume Playback”. Then it happens on another track and suddenly everything is working right again. And then the problem returns. I just have to chose the track by going forward and stop (so it plays only for a second). I can’t see any pattern in this behaviour.
The ".playlist_control" file’s content always looks like following even if the player does not forget the song. But where is the current song stored? The only other written file is “nvram.bin”.
P:2:/playlists-shuffled/test:0-utf.m3u8
Regards
Thomas
-
I think this is fixed in the latest dev versions http://build.rockbox.org/
-
Unfortunately the (at this moment) latest development build for Sansa Clip+ (build 7a8c9da) didn’t fix it. Problem is still there.
-
can you make a sample of the smallest possible case for which it occurs and upload it somewhere for someone to peruse
like 3 songs and a playlist that doesn't resume properly?
-
Just switched from an ancient custom build on my now sadly defunct Clip+ to a bleeding edge custom build (mainly for your power saving and multiboot patches, Bilgus, thanks!) on my new ClipZip.
Ran into the same exact issues described here and in FS#12864.
I know that the following observations are basically worthless until I have verified with an unmodified non-multiboot dev build, but here is what I have noticed so far:
- The bug appears only sporadically and is thus hard to reproduce. Sometimes the exact same playlist will resume correctly, sometimes it won't.
- Dynamically created playlists from folders with a lot of (500+) files and quickly pausing multiple times after skipping many (5+) tracks seem to produce the issue more often than folders with less files.
- I am booting rockbox from my external sdcard. All my media is on this storage device.
The resume bug (so far) only appears when working with relative (or rather symlinked? loopmounted? not sure how rockbox handles storage integration into root) paths (/MUSiC/* instead of <microSD1>/MUSiC/*)
Will check back in once I can provide some actual information on how to reproduce this behavior with a current dev build.
-
I'm running into the same issue, and would like to add a bit more info.
When I am listening to a playlist and then turn off the player, 95% of the time the playlist will begin at the beginning of the first track. When this doesn't occur is usually when I immediately restart the player within 1-2 seconds.
When I browse to a file in a folder, play it, and restart the player, it will pick up where I left off 100% of the time.
Using Clip+, latest dev build.
-
Hello. It is an old topic, but I'd like to contibute, with a different approach, and, hopefully, a solution.
I recently had the issue of playlist resuming from the very first track, after a shutdown. My player is an iRiver H340 with a Toshiba disk of 80Gb. Rockbox is 3.14.
Some playlists I added recently were behaving as above. I had compiled the playlists with Media Monkey 4.1.24.1083. I have configured it (in settings) to export m3u playlists in UTF8. I also export them in the root directory of my laptop. I use the same folder structure in both my laptop and the H340, eg. \Music\somefolder\somefolder, etc.
The tracks in these playlists were in absolute path, but driveless, and more important, with no "\" at the beggining: eg.
Music\somefolder\song1
and not: \Music\somefolder\song1
The player recognized them and played them fine, ecxept for the resume problem.
I had many other playlists with the "\" at the begining of the tracks path and the resume were fine, from the point where they had stopped.
So I changed the path (from Music\somefolder\song1 to \Music\somefolder\song1), saved the playlists, copied them to the player and the problem went away.
The change of the path was easily performed with Notepad: replace "Music" with "\Music", replace all, and save as m3u.
I hope this helps.