Rockbox Technical Forums
Support and General Use => Audio Playback, Database and Playlists => Topic started by: beatnik on February 25, 2008, 12:55:01 PM
-
On my Sansa e260 I am frequently unable to skip tracks. Most of the time when I am able to make it work it skips to the next file but would not got to the file after that. Sometimes after I try to skip a track it locks up and I have to either turn it off (if that works) or wait until it shuts down due to idle.
It worked fine with the last release I had I updated it for the better video player. (which I like a lot) I do not remember what release it was but it was before the Video player update about 2-3 months ago.
As was said in another post to do a clean install (which I did in the first place) I did again and am now certain it is something with this current build. Unless I can find an old release before the video player upgrade. I might install it and wait until a new release is out with a fix to this problem as it is not a trivial bug I can deal with but it directly affects the audio play otherwise Everything else works great.
Thanks for reading my post Rockbox just Rocks and I am able to use 3 times the features available with my Sansa's factory firmware. I just want this Awesome firmware to work again. Anyone else with a Sansa e series have this problem or have a solution to it?
Thanks
-
I cannot replicate this problem with revision 16416.
Could you provide additional details about how to replicate the problem? Are you using the file browser or the database? What types of files are you playing? Does the problem happen with all of your music, or just certain tracks/directories/albums?
Here are some other things that you might want to try:
1. Resetting your settings using Settings --> Manage Settings --> Reset Settings.
2. Using chkdisk or an equivalent utility to make sure that there are no file system errors on your disk.
-
I am using the file browser. After I cleared my settings it worked for a bit but it went back to the same problems. Are you suggesting using chkdisk on the sansa disk?
After I run chkdisk If it does not fix the problem, I will do a clean install and if that doesn't work I will even reload my files. I did check to see if it was a new file that was messed up but it was not it was happening to all files even those that played fine with the last build I had installed.
As of now even though I am using the cabbiev2 theme I still have maybe three themes with .wps that were downloaded. (from this site of course) When I reinstall I will not install anything extra as I like the default settings and have no need for anything else.
Thank you for your QUICK and helpful response BTW
edit: I just got release 16417 and will install this release after your responce. I will install it clean and only with the voice addon.
-
For the clean install, you can copy game saves and scores, plugin settings, etc., from your old build, but don't copy any files that are not "already" in the root of /.rockbox (i.e., your database, main Rockbox settings, and so on).
By the way, I've been using r16399 for a couple of days. It's been working nicely. :)
-
I could not find release 16399 as the current releases seam to not be archived like the daily builds (I would assume that is because they are the same build with the exception of a few non needed features) are but I tried the next highest daily build with no results, maybe i should have tried the one below it. . So I decided to try a newer release daily build #16441 and to my surprise, IT WAS FIXED!
So I took a chance and installed that days current release #16445 and it worked and it also had all the nice looks of the current builds icons and such. Now I am confident in saying that it at least worked for me and I would suggest if you have this problem try it out it worked for me but asive herd some people the problem never occurred and like posted above a different release fixed it for someone else. So all i can think of for others if the newest does not fix the broblem for you just try random daily builds and I hope you wil find one that works. Hopefully they have noticed the probelem and have fixed it and from now on it will be fine. So for me I wont be updating again untill they get full usb support for the Sansa E series as that is the ONLY think I believe they are working on.
They say that have made charging work for the current releases but as of now it seams to work but after i unplug, it freezes with a bunch of artifacts on the screen. So I still use the OF to charge.
Its amazing to me what they are able to do with this thing its 5 times more powerful than the first computer I had when I was 13. Good old 386 with 12 mb ram I had to trick that effer out but I was able to run win95 with no problems so who knows what they might be able to squeeze out a this thing. I would love to see more programs its just too bad its limited by the controls having only 5 buttons (6 with power) and a wheel there still is possibilities.
Thank you everyone for trying to help out on this one. Hopefully future releases wont have this problem on the Sansa E series. Good luck and also thank you developers for making this available, it makes the Sansa 10 times better I really would not have liked it without Rockbox you guys Rock.
P.S. Also if anyone has a Sansa im no pro but if you PM me I will Gladly try to help you.
-
I could not find release 16399 as the current releases seam to not be archived like the daily builds (I would assume that is because they are the same build with the exception of a few non needed features)
The daily build and the current builds are identical, except that the daily build is built at a specific time every day, and the current build is built on every source change. The reason that the current builds are not archived is that that would very rapidly take huge amounts of unnecessary space up. You can build any specific revision you desire from SVN.
So for me I wont be updating again untill they get full usb support for the Sansa E series as that is the ONLY think I believe they are working on.
Eh? Many people work on many different things....
-
Although r16441 isn't perfect (and I do not have r16445 to check) "something" seems to have happened to file navigation between r16441 and r16452 (2/28/08 and 2/29/08) respectively. Â Pointers or whatever seem to lose their way with quick file navigation and incorrect tags can be forced to be displayed for the playing track with r16452. Â r16441 seems to be able to (eventually) get it right with quick navigation.
iPod 5.5g 80GB 11,000+ .ogg files at q7 and q8.
EDIT:
For the purposes of testing, I skip forward and backwards very quickly and repeatedly. Â Auto-change to next directory is "off" as it most certainly has issues with r16441. Â Directory cache is "Yes".
Also have:
max files in playlist: 32000
max files in dir: 16000
Yes, 16000 is non-standard but it seems to help with r16441 for whatever reasons. Â Does rockbox ignore the non-standard value? Â If not, I assume there is a memory/buffer penalty.
I've been keeping up with the builds and r16685 has the file navigation problem.
MORE EDIT:
Just for fun I tried r16694 and stripped out virtually everything in config.sys, using the default system WPS, font, whatever.
The entire config.sys:
# .cfg file created by rockbox r16694-080318 - http://www.rockbox.org
volume: -37
repeat: off
folder navigation: on
This configuration cannot keep up with fast file navigation.
-
Same hickups happen on my Sansa e260 too, and additionally the display of the tags of the current and the next track are wrong to, when I've skipped the tracks too fast while in Shuffle-mode.
-
Just for fun I used the database feature of Rockbox (which I really don't want to use) to see both sides of the track and dumped my WPS to use cabbie_V2:
# .cfg file created by rockbox r16717-080319 - http://www.rockbox.org
volume: -33
repeat: off
max files in playlist: 15000
brightness: 2
volume fade: off
folder navigation: on
tagcache_ram: on
start in screen: db
Navigation within the database is still slow and problematic with fast navigation -- Rockbox still loses its way.
I'll get rid of the folder navigation and see what happens but it may be back to r16441 for me.
iPod 5.5G 80GB 11000+ .ogg files
EDIT:
Even more fun, I went back to build r15804-071125 (sort of):
1. copied over the rockbox.ipod file from r15804
2. copied over the codecs r15804
3. Changed the font to helvR14.fnt (easier on my poor eyes)
4. Shifted the time/track line in the .wps up one
4. Deleted the navram.bin file
5. Rebooted
Rockbox now file navigates like a bat out of you-know-what -- and looks great with cabbie_v2.
r15804 is missing a lot of stuff and fixes so may not be for everyone but its OK.
-
Please, rather than offering workarounds, why not try to track down exactly what is causing the problem so that it can be fixed?
-
In a previous post this comment was offered:
"Although r16441 isn't perfect (and I do not have r16445 to check) "something" seems to have happened to file navigation between r16441 and r16452 (2/28/08 and 2/29/08) respectively. Pointers or whatever seem to lose their way with quick file navigation and incorrect tags can be forced to be displayed for the playing track with r16452. r16441 seems to be able to (eventually) get it right with quick navigation."
I looked at the dev notes between r16441 and r16452 and nothing seemed relevent to me -- a non-developer of the code. I'm looking at this still and am doing what I can. Perhaps the workarounds offer clues.
-
No, the workaround doesn't offer clues because it's simply "use an older version".
Why not view the SimpleGuideToCompiling page, and try the builds between 16441 and 16452 to narrow it down to a specific one?
-
I'm hoping it might stimulate the memory of a developer who may have "tried something" which may have been thought innoucuous. I understand the request for builds.
In other somewhat related topics, I offered other workarounds such as increasing limits, not using caches, etc. I'm testing this, maybe other issues will be discovered.
I'm trying to help as best I can, if somewhat loudly.
The navigation speed seems to a be a progressing problem. playback.c seems to be awfully busy in the last few months.
-
I just told you the best way you can help out. Pinpoint the exact build where the major problem was introduced.
-
Build environment underway.
EDIT:
Build environment completed, Rockbox built, placed on ipod target and running. Â Here we go.
EDIT:
Problem with truly quick file navigation appears to start with r15816. Â r15815 seems OK -- not perfect but OK.
Now let's see where auto-change dir = "yes" problem begins.
-
EDIT:
Problem with truly quick file navigation appears to start with r15816. r15815 seems OK -- not perfect but OK.
I can confirm this on my Sansa e260, 15815 is fast regarding skipping and fetching of the ID3-Tags, but 15816 is slow regarding song-skipping and if done too fast, it plays one song and shows the ID3-Tags of a later track and eventually doesn't change the tags at all. So the changes made in 15186 are definitely at fault for this problem.
-
I tried to back out the changes for r15816. Â It appears the changes for r15816 have been used in other parts of the code for other revisions so, with my attempt and limited knowledge of the code an coding, it wouldn't compile/make. Â I built a "Frankenstein'ed" version of Rockbox using r15815 as a base and added in the power savings of r16259, 60, 61 and then added in the USB changes beginning with r16350 through r16422. Â To my amazement this thing make'd, runs like the wind, auto-changes directories, has increased battery life and a good USB connection. Â I haven't tried the games, apps, plugins, etc. Â In no way is this *unofficial* build to be considered a "fix", "workaround" or to negate the *very* hard work of the developers -- it is just an elaborate experiment for my simple needs and to learn more about Rockbox and familiarizing myself with the code and build process.
iPod 5.5G 80GB 11,000+ .ogg files varying from -q7, -q8 with a few at -q10 for fun.
EDIT: Narrowing things down for the changes for r15816 it appears the calls: unregister_buffering_callback (buffering_audio_callback) and register_buffering_callback(buffering_audio_callback) contribute to the file access response issue. Â Commenting out those two lines produces a make warning when integrating the r15816 fixes to r15815 but otherwise, the access time is improved. Â Maybe too much is happening within a created tight loop?
Let's say one presses the skip forward or skip back buttons repeatedly or alternatively. Â During that action the Rockbox is quick enough to find the track position but then Rockbox has to perform the register/unregister while the user has already pressed the skip forward or backward buttons again and again.
Too much overhead for each button press?
EDIT: Built Rockbox with r15815 (base) added in, r16259, r16260, r16261 (battery savings), r16279 (USB) and all USB changes beginning with r16350 to present (3/30). Compiled, make'd, and zipped. For my experimentation and learning only.