Sluggish Responsiveness, Resume Playback Inconsistent

[NicolasP]

This issue seems to have appeared with r15444. It is described in FS#8260. I posted a patch there that reverts the changes in r15444, and it seems to fix the problems.

[simulant]

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

[Wrathernaut]

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.

[Wrathernaut]

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.

[Febs]

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.

[Strife89]

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 ), 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.

[Febs]

So why didn't you work on fixing it?

[Strife89]

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!! The problems seem to be fixed!! Thanks again!

[Llorean]

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.

[Strife89]

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 for my attempt to give to the project, albeit in the one programming language I ever figured out: TI- Basic.

[Wrathernaut]

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.

[Speedy64i]

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

[hoho]

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.

[rockboxacdc]

well it depends what version of rockbox did you install?  

[Febs]

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.