Rockbox

It sounds like a hardware problem. Especially considering the fact that it has taken you multiple reboots to fix it, since there’s nothing really preserved across reboots that would cause this sort of thing to persist.

If you really think it’s a Rockbox issue, despite being the only person experiencing something that sounds like it happens to you on such a frequent basis that if it weren’t hardware we should have plenty of reports, the best thing you can do is narrow it down to *exactly* which build does it rather than saying “The 10/22/07 build does not while the 1/03/08 build does” as, if none of us experience it, we can’t actually test to see which builds it happens in.

Needing multiple reboots to fix it could be a race condition with nondeterministic results.

With the october release, it hasn’t happened again. If it was a hardware problem that was occurring 19 out of
twenty reboots, wouldn’t it also occur with old software? Sounds to me that a bad hard drive wouldn’t care what was installed and would be unresponsive with any release.

I intend to run it for a week to be sure then start putting on newer and newer releases every few days until it starts occurring again.

It is possible the reason others haven’t reported it is due to the kinds of files I play. I play audiobooks mostly at variable bit rates averaging 64kbps and they often have tracks that are 70 minutes long and sometimes more than 600 minutes long. Maybe it doesn’t ever occur with the typical 128kbps 3 minute track.

FYI,  FS#8429  also reports the same problem.

I have Had this same problem. Im on a Mac and rockbox has been a week long effort for me. My Video Ipod whenever i use rockbox seems like its going crazy. I will also try to pause a song and it wont pause or skip tracks. Also I have multiple duplicates all my songs and also some music i didnt even put on my ipod is on there. I did open up my itunes music folder and just throw all the artist folders i wanted directly on my hard disk. If anyone can help me figure out I would appreciate it. Ive been running searches for solutions for like the last week

I have the same problem here with my 5.5G 80GB ipod Video as well running current 64MB SVN builds.

To me it looks like some sort of re buffering problem as my ipod video’s buffer never fills unless I pause playback on startup.

Reverting to any build before “2007-10-25: Metadata-on-Buffer committed; this involves a largely rewritten playback buffering engine.” fixes the problem.

As I have been running Rockbox without problems on my ipod video since 80GB ipods were supported I would say its not a hardware problem.

As part of my testing I have checked, built and tested an SVN from 2007-10-24 which works perfectly as expected.

The first build I tried after the new buffering engine was introduced is from the 2007-11-27 and shows the problem, so do all builds I have tried since.

This problem may be config related.

Does album art have any bearing on this? i.e. if you have AA on your WPS, try one without.
Also, if you have database auto-update enabled, try again with it disabled.
Make sure you have dircache enabled.

Does the problem happen if you Reset Settings back to default and reboot? Resist the temptation to change to a larger font or anything… ;)

I’ve tried numerous config setting variations with this, including the ones you mentioned. Nothing seems to fix it (even if a config setting did fix this, the scanning of the disk should not cause my music to skip… that’s a bug regardless). Pausing the music for a minute or two also seems to work for me. FYI,  FS#8448  (along with  FS#8429 ) also reports a similar problem.

I’m not disagreeing that it’s a bug, but it would be useful information if it only happened under certain circumstances. If it happens with the default settings (including font/WPS) then that’s also useful information. Just wanted to check.

I think Dwyloc is pretty accurate with his assessment. WPS/font settings really have no effect. I’ve tried changing dircache, database auto-update… no effect. The hard disk is really thrashing and you have to pause the music for a few minutes to let it catch up (which is difficult to do… having the player accept the pause request usually takes a couple of pushes of the button). The problem also appears to be more noticeable for larger files (80% of my collection is FLAC), which leads me to believe that this is a buffer issue like Dwyloc suggests.

Someone on the forums reported that it could be related to the directory structure: http://forums.rockbox.org/index.php?topic=15128.0 This makes me think that the problem could be database-related. More specifically, I think it could be with the “gather runtime data” feature, which makes the playback code call DB functions on each track (un)buffering event.

This makes sense, since some people reporting a problem like this have said that disk noise happens on every track change. It seemed strange to me, but I was thinking “the next track should be buffered, and there’s nothing to do for it” rather than “what do we do for the last track when it becomes unbuffered.”

Gather runtime data should not be the reason for the slow database updating though. The “Always check for deleted files” change in r16081 could explain the report in the forum, though I would’ve expected enabling dircache would fix that. However, I don’t really know dircache building and database updating interact during startup, but if the tagcache auto update is running at the same time as the dircache is building, that could explain a lot.

I tried the things mentioned in http://forums.rockbox.org/index.php?topic=15128.0. Now playing flacs is fine. Since I am using r15832 it is not only a problem of the change in r16081 as learman stated.

A few more observations (r15832):
- Switching the IPOD on does lead to exessive disk activity (All *.tcd files still deleted).
- Auto resumeing the flac audio after switching on is still full of gaps.
- Selecting a new track (even flac) will play the track without gaps and disk activity stops in a shorter time (much longer than in elder releases, ~ 1min).

- I don’t use the database but I have tried deleting all the files for the database anyway (and have auto update disabled) but that dose not make a difference.
- I don’t use the “gather runtime data” feature either and keep it disabled.
- I don’t use Album art or large fonts and use the cabbie v1 wps (which is much better than the new v2 version).

- I use the resume playback on startup option and the player dose boost as expected on startup to try and fill the buffer but for some reason the buffer never seems to fill unless I pause playback.

If I try to pause playback right away strait after after boost playback continues for about 30 seconds or more before pausing and if I press any more button in that time all other key presses are ignored for a few minutes. The screen lights up as expected but the WPS screen dose not update.

I have tried clearing the config on boot then selecting the cabbie wps, enabling resume on startup, disabling audio fade on pause and resume, pause and resume on headphone unplug & enabling recent bookmarks and I still get the same problem if I shutdown them startup rockbox again as normal.

The problem is also not limited to FLAC files as I use mono mp3’s (audio books) and stereo Ogg Vorbis files (music) encoded at q5 on my iPod video.

Does it happen if you don’t have resume on startup enabled?

Switching off resume on startup seems to stop the problem from occurring but pausing and un pausing is still slower while the buffer is filling but instant after the buffer fill finishes.

I am getting the buffering and boost information from the “View buffering thread” screen in the Debug menu incase anyone else with the disk activity wishes to have a look and see if they really have the same problem or if its a different related problem.

Well yesterdays commit at 03:00 seems to have helped a bit buffering now completes successfully, but my player is still unresponsive while buffering this is most noticeable with resume on start up switched on.

While the player is buffering if I try to pause playback nothing happens for a few seconds.

Resume also seems to be broken for mp3’s with playback starting at the beginning of the file not the point were playback was stopped last time. Loading bookmarks also have the same problem with playback resarting at the beginning of the file not at the bookmarked location, but I am also having this problem with my flash basted e280 as well as my ipod so its not an ipod 5.5G 60/80GB only problem.

I can confirm the same problem here on a 5.5G 80Gb. I arrived a month or so back in the updates I think and it’s the same as the previous descriptions. I’ve tried
all variations of config setups but to no avail. (and the restart doesn’t stop the problem).
I’ve also noticed that it skips songs in my directory if I press next but not if I listen sequentially. not sure if that’s related though.

Has anyone tried to identify a bit more precisely when the problem appeared?

I tried to go as far back as I could with the current files but it’s still the same (they spread back to early jan I think). I think it’s sometime
in late dec/early jan the bug appeared but can’t be 100% sure of it. If there are older archives I’ll be happy to test them. I just don’t have them handy to check sadly :(

I’ve installed tdtooke’s underground build and it has removed the problem disk spin issue and the track skipping issues I had. Maybe a diff between the two would be effective (or has there been too many changes to make this feasible?)

You can test any version you want if you build from source. It’s the beauty of version control.
Knowing when the build you used was built would help a bit, but really not much. A diff between binaries is impossible, and even with the sources, there would be far too many changes for it to be of any help.

will look into building from source then. I run linux so I guess svn is the way to go.

For problems that are 100% reproducible, doing a binary chop with SVN revisions is surprisingly quick.

Is this issue present in a current build?

I think it has been fixed. I went to my typical audiobooks and had no lockups.
I think we can close the ticket. If I see it resurface in the course of further testing, I can always reopen the ticket.