Rockbox

Basically, after the directory change, it doesn't rebuffer again, from the sound of it. I thought this bug was supposed to be fixed... Hm. I shall ask.

I'm seeing exactly the same problem with CVS 060515. Identical symptoms, although I haven't tried it with mp3s. Just one thing to add though: it appears to be an intermittent problem. Some days it's there, some days it's not. Once it starts going wrong (which is most of the time, it stays that way for days. No idea what starts & stops the problem. Today it went through 4 or 5 folders no problem: yesterday it was stopping.

Seriously, 06-05-15 is 12 days old. Please, he reported it with a newer version than you did, so it's kinda pointless for you to say 'Oh yeah, it's around in older versions too.'

Please try with the latest build.

Abuse such as this is inappropriate and ill-advised. If I'd had time to put the latest version in I'd have done it: I'll probably be able to do that later today. In the meantime I was posting to let you know the problem is an intermittent one. My dayjob is troubleshooting problems like this (with different technology). If you can't understand the value of being informed a problem is intermittent when you hasn't previously been informed of it, then you will find yourself thinking you've fixed problems when you haven't.

I've now done some black box testing with CVS 060527, Repeat set to Off & Autochange Directory to Yes. The tests were with FLAC, WAV & OGG files, so I can't comment about MP3 etc. Conclusion: If the last track in a directory is a FLAC or WAV file, & the first track in the next directory is a FLAC, WAV or OGG file greater than about 12.5/13MB in size, then playback of the latter will stop at the 12.5/13MB point. If the last track in a directory is an OGG file, this appears to cause no subsequent problem. What the earlier tracks are in the first directory are appears not to matter: it's only the last track that affects the first of the next folder. If the first track of the second directory is smaller than 12.5/13MB, subsequent tracks in the same directory will also play OK, however long they are. The tests appear to give the same results each time, although I didn't run them all repeatedly. I couldn't get any tracks to fail that weren't the first track in a directory.
This should be easy enough to re-create so I won't post the details of the tests: if anyone wants more info, just ask.

The interesting thing is though, that before the fix it wasn't intermittent. It was constant. And the fix was made on the 16th. So every build for several days before the 16th had the problem.

As well, sometimes bugs aren't intermittent, and are just regressions, which is what this case may be. Either way there isn't value in reporting a bug in a version from before the first attempt to fix it.

Now if I'd known a fix had gone in for this on the 16th I'd have tried the fix version before posting. I did look though through what was supposed to have been fixed but must have missed this: I still can't see any ref to it in the build notes for the 16th though.

Actually, honestly, I'm wrong. I got two fixes mixed up.

Anyway, from the sounds of your test though it's either the same bug, or a very similar bug, so it looks like it was reintroduced possibly. The problem was that it only filled the buffer once after directory change (or didn't refill it beyond what was already in it, I can't remember) and from the sounds of it that's what's happening now. It just sounds like it's a more limited case. Maybe it wasn't wholly fixed.

The change that should have fixed this was in the daily build on the 15th (see B#5319). I tried reproducing this with the latest CVS build and was unable to. My directory structure is as follows:

Dir 1:
1-1.flac - 32MB
1-2.flac - 16MB

Dir 2:
2-1.flac - 16MB
2-2.ogg - 4MB
2-3.ogg - 4MB
2-4.ogg - 5MB
2-5.ogg - 5MB
2-6.ogg - 5MB

The ogg files played as expected after 2-1.flac completed. Either I'm missing a step or there's something special about your files. If you have a set of files that easily reproduce this, would you be able to provide them to me? Also, please post your current config just to make sure it's not some other setting that's affecting this.

That looks like the sort of directory structure I would find failing on my box. Where do you want me to send the files? bugs@rockbox.org? I don't want to post music to a public forum. All files were created with dbPoweramp by the way. And how do you want me to capture the config info? I can do it, but want to be sure you get all the info you need.

The easiest way would be to make the files available somewhere online and e-mail me the location (rockbox AT fastmail.fm). For the config info, just post the file created by Menu->Manage Settings->Write .cfg file.

OK. Whatever the problem is, it appears to be nothing to do with dbPoweramp. I just tried again, with the first directory containing the standard Windows ding.wav file, & the second directory a wav file ripped from CD with jetAudio. It stopped at 1m 15secs, as it always does with wav files. Here is ding.wav (for what it's worth!). I've got nowhere I can post a 30MB file though, but since I get the same effect with files created by both dbPoweramp and jetAudio I doubt there'a anything odd in the file contents. Also attached is a cfg file. The box is a 60GB unit.