Rockbox Technical Forums
Rockbox General => Rockbox General Discussion => Topic started by: Wrathernaut on January 27, 2008, 06:46:57 AM
-
I've been running various builds of rockbox for a while and I've been a bit disappointed with the responsiveness.
My previous players were a Rio Riot and a Rio Karma, both of which could skip forward and backward without delay. My Gigabeat F40, however, seems to take it as a suggestion when I skip ahead or back, sometimes changing as you'd expect, other times updating the WPS screen and taking 3-5 seconds to actually start playing the next song. This has been pretty consistent with the various builds I've used.
This most recent daily build (23 Jan 08) has been quite bad at resuming play, sometimes skipping the current audio file, sometimes just going to a random spot in the one that was playing. I was previously using MadCow's build, with the fast resume, and it never failed to resume properly (about 5sec faster) when resuming from power off.
Are these experiences typical?
-
The hard drive has to start up the new set of tracks need to be loaded up to the buffer. That is what takes the time and yes it is normal. The original firmware did pretty much the same thing except the wps updated immediately but the new track still had to load up.
When you do skip a track and it goes to it immediately, it is because the track is already in the buffer and the hard drive doesn't have to start up.
-
But my Sansa (which has a flash drive) has been experiencing this as well. In the original firmware, this was almost nonexistent. I understand that there would be some lag, but often the delay is around 3, maybe 4 seconds.
-
I use a Sansa e260 and noticed same behaviour, its not as bad when your skipping to next track, then its pretty fast, but if you skip backwards its very slow.
-
Okay, so the sluggishness is pretty common, but what about this skipping the song that was playing and jumping to the next one on "Resume Playback" (Sometimes, but more often than not)?
Did I just get a bad daily build, or is this common?
-
I think part of the problem is that rockbox keeps playing the old track until "everything is ready". In other firmwares playback is stopped immediately when you hit the "next" button. IMHO this would be better as it gives you direct feedback on the button press.
-
Okay, so the sluggishness is pretty common, but what about this skipping the song that was playing and jumping to the next one on "Resume Playback" (Sometimes, but more often than not)?
Did I just get a bad daily build, or is this common?
I get this too on my c250 and found the commit that made this behaviour a very obvious problem (at least on dual core targets - Ipods, Sansas and the H10s). Taking the chance to talk to the developer in IRC earlier today I've been told that it is actually a playback or buffering bug, and his commit is not the real cause but revealing the bug which could have hit before too, not that often though. There are a few bug reports about resume problems in the tracker and I will append the important part of the discussion to one of them and hope it'll get fixed soon.
-
Seeing a similar issue with my e200 I see a lag with the resume play or for that matter moving backwards in the menus. Some times it is so bad that I just reboot the player. Actually its getting quite frustrating at this point. It was a whole lot more stable a while back. My personal opinion is that if it ain't broken don't fix it. Currently using version 16169-080126. Any body know how far back I have to go to get to a version without this issue and perhaps without the remap of the buttons?
-
I think builds from the first half of the month doesn't have this issue..
EDIT: Just tried revision 16043 (from January 10th), and I find it is much more responsive. :) (I even left the (now commited) Cabbie theme (version 2); no problems there.)
(I deleted my settings and database beforehand as a precaution, though. ;) )
-
I went all the way back to EvilG's last custom firmware and the difference is night and day, perfect resume on startup and most everything else is more responsive.
-
Went back to the fist half of January and still seeing the same problem. EvilG's last custom firmware can be found where and when? Will it work for the e200 series? If that does not work perhaps I will put the e200 back to scratch and start fresh.
-
If that does not work perhaps I will put the e200 back to scratch and start fresh.
I recommend you test run some of the Device Disabled builds in the Unsupported Builds forum, they've been treating me very well.
-
Went back to the fist half of January and still seeing the same problem. EvilG's last custom firmware can be found where and when? Will it work for the e200 series? If that does not work perhaps I will put the e200 back to scratch and start fresh.
EvilG's is for the Gigabeat, (others?) and can be found in the unsupported builds.
-
I have a sansa e260r and have noticed the same issues. I was using a build from 2.Jan.2008 (and went back to it) because the recent builds (I tried the 20th, 25th and the 30th) were slow to respond and/or seemed to lock up my sansa.
UPDATE: Just to clarify my exact problem I tried a few scenarios. It doesn't seem entirely dependent on the Theme used, but I am getting different responses with different themes.
When I am using the cabbie2 theme, the responsiveness seems bad all of the time with the current build (downloaded today). If I use one of the acotil blue themes, the responsiveness to pause, stop (pressing the menu button), forward or back only happens during the first ~15-20 seconds of initial playback. After that everything works as expected. I tried a default set up for the theme and it still seemed to have a similar issue.
Possibly useful to note: If "Fade on Pause/Stop" is disabled the song keeps on playing after pressing pause or stop for the first ~15-20 seconds of its initial play time. If "Fade on ..." is enabled, it fades appropriately, but still isn't responsive until that ~15-20 second interval.
UPDATE #2
It turns out the equalizer seems to be the culprit for me. When I turn off the equalizer, the ~15-20 second delay goes down to 5 seconds and only happens after I first start playback.
-
Went back to a Jan 5 build r15998-080105 works fine , no delay that I can find anywhere.
-
This issue seems to have appeared with r15444 (http://svn.rockbox.org/viewvc.cgi?view=rev&revision=15444). It is described in FS#8260 (http://www.rockbox.org/tracker/task/8260). I posted a patch there that reverts the changes in r15444, and it seems to fix the problems.
-
The build from 2/13/08 still has problems with auto-resume on my Sansa E270.
The problems appeared (for me anyway) in a build released on or around 1/28/08.
After a fresh install, auto-resume works for a bit (it worked several times in a row when I tested yesterday's build), but on further reboots the player starts to either skip to the next track or go back to the beginning of the current track.
I'm experiencing this when playing 20 minute audio book .mp3s
FS#8511 is open on this and it appears to affect multiple platforms:
http://www.rockbox.org/tracker/task/8511?histring=resume
-
My issues with resume were with fairly long files too, 48~ish minute long would very consistently skip to the next track, shorter ones still had issues, but would resume on occasion.
-
So has the underlying problem to the sluggishness been taken care of yet? I'd like to take advantage of new features, but not at the cost of basic operations.
-
Revision 16392 by Lear had the following message, "When starting playback, prevent the codec from starting to decode too early, which would cause rebuffering (slowing things down) and incorrect playlist index. Hopefully fixes a bunch of playback-related bugs, such as FS#8520, FS#8525, FS#8555 and possibly FS#8511."
Why not try it? If you want to be able to revert to the build you're using now, just rename your .rockbox directory before installing a current build.
-
First and foremost: I AM NOT complaining here.
I appreciate the work done to fix this problem (I'll test r16399 shortly), but the amount of time since this thread was first posted and the build that fixed the problem (I hope :) ) was quite long - at least a month.
I don't know if this was because the problem was too difficult to fix quickly, or if there was simply a lack of people working on the fix, but I will assume the latter; and while I appreciate continuous work on other aspects of Rockbox (such as USB functionality for PortalPlayer targets - I eagerly await such ;D), I submit that proper operation of basic functionality should ALWAYS come first.
Again, I AM NOT COMPLAINING here; I love the work you guys do and thank you all for the wonderful software that you provide at no charge to users; but I am saying that glaring problems like this ought to get more attention in the future. ;)
-
So why didn't you work on fixing it?
-
Because I can't code. But at least 300 people have worked on the project, and THEY can definitely code quite well. ;)
Hence, my notice that I'm not trying to be a complaining @$$%0!#. ;)
EDIT: Huzzah!! ;D The problems seem to be fixed!! Thanks again!
-
Those 300 people are all volunteers. Of them maybe 40 are active. Of them maybe 3 know enough about the details of this part of the code. For three people to fix a difficult problem in their spare time, I think this is a reasonable period of time. Saying proper operation should come first is all well and good but often there is a lack of manpower despite the apparent numbers. And of course people like you never pitch in by starting to learb so you can help next time Instead you just say you can't code, and give your opinion of how we could spend our time better as if we were too stupid to realize that playing music well is the single key function of a DAP.
-
I AM NOT trying to imply that you are "stupid" or that you are not trying hard. I apologize for anything that rubbed you the wrong way.
Side note: I am attempting to learn C, and have been for the past week, but the only way I know to do so right now is to grab C files off this site and fire up Notepad ++, then attempt to read the code and decipher commands. Needless to say, it's not going well, and I will be far from capable of helping with the project anytime soon.
Side side note: See FS#8631 (http://www.rockbox.org/tracker/task/8631) for my attempt to give to the project, albeit in the one programming language I ever figured out: TI- Basic.
-
Thanks for the response and the fix, I'll have to give it a try.
While one month may be seen as a long time for a fix, the beauty of Rockbox is that we can roll back to a working version, which was my solution.
I have more to say on this, but it does not belong in this thread.
-
I'm running 16408 and the resume is working great but when i skip forward or backwards 4 or 5 songs, I end up with a large occurance of it playing one song but showing the title and name of another. The last time i was able to skip forward and back without long pauses and display weirdness was way back in late december/early january. Any idea if i can change a setting to fix this?
Thanks,
JT
-
r16417 here, Sansa e260
Skipping to next track once: fast
Skipping backwards once: slow
1) Shows next tracks name somewhy for 1sec
2) shows current tracks filename
3) finally shows the previous track its supposed to
Skipping forward multiple times as long as its in the buffer is ok, but the moment its out of buffer its hellishly slow and mixes up the track and the playlist number and then it just doesnt play.
Same with backwards multiple times only you dont need to skip beyond the buffer since there is none as far as I understand for previous tracks.
And I just managed to make it hang by pressing stop while it was skipping backwards once.
-
well it depends what version of rockbox did you install? ???
-
well it depends what version of rockbox did you install? ???
What are you replying to? The last two posts in this thread specified the exact SVN revision being used.
-
r16417 here, Sansa e260
Skipping to next track once: fast
Skipping backwards once: slow
1) Shows next tracks name somewhy for 1sec
2) shows current tracks filename
3) finally shows the previous track its supposed to
Skipping forward multiple times as long as its in the buffer is ok, but the moment its out of buffer its hellishly slow and mixes up the track and the playlist number and then it just doesnt play.
Same with backwards multiple times only you dont need to skip beyond the buffer since there is none as far as I understand for previous tracks.
And I just managed to make it hang by pressing stop while it was skipping backwards once.
I'm having these same issues. Â The first time I can remember this occurring when I upgraded from a build in late November to the 13 january 2008 build. Â I also started using .ogg files, and I quit using .mp3. Â I will try to create some .mp3s and put them on to see if the issue occurs with .mp3. Using build from 26 feb 2008
UPDATE: Â I created 3 mp3s (Breaking Benjamin - Saturate) using CDex using the following settings (VBR0 lame 3.97 beta 2) and back button works as it should. Â I skipped to the middle of the song, waited 10 seconds, hitting back once takes it to the beginning of the song, twice goes to previous song. Â This is different than when doing the same with .ogg files. Â Seeking back and forth in .ogg work fine, it is when trying to go to the previous song that it has issues... It go to the next song in the directory. Â Using Playlists have the same issue, as well as using the database to select songs...
UPDATE #2: using today's build (2/26), trying to go back to the previous song, I ended up crashing RB with the following error "data abort at 01F07E08 (0)" This did not occur at all when I played the .mp3, this occurred when I played the .ogg files. The current build seems to handle .mp3 correctly on my player, but not .ogg files on my player.
If I need to supply more information, please tell me...
Bryan Brake
modified: Â the bit about the ogg files... apologies...
-
Adding them to Ogg files IS corrupting the Ogg file. Just because your computer doesn't complain about the files being corrupted doesn't mean it's proper behaviour. Please don't post about unrelated problems in this thread.
-
Got the error today too. I'm using r16717-080319 with a huge playlist (not database), approx. 2200 files, all OGG Vorbis, Shuffle mode.
I just skipped three times pretty fast, then the tags went nuts with first showing the proper lines, then the tags from the next and previous songs, and then the crash with the aformentioned error-message.
I used oggenc 2.84 and 2.85 from rarewares.org with foobar2000 for encoding and taggging.
:-[
-
As far as responsiveness with quick file navigation (not database or playlists) skipping forward and bakward, I think the problem stems from r15816 onward. Â r15815 is pretty quick and nimble. Â I built them both and, to me, it's clear.
iPod Video 5.5G 80GB 11,000+ .ogg files