Notice: A non well formed numeric value encountered in /sites/ on line 96 Notice: A non well formed numeric value encountered in /sites/ on line 96 Notice: A non well formed numeric value encountered in /sites/ on line 96 Deprecated: Function create_function() is deprecated in /sites/ on line 104 Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /sites/ on line 845 Deprecated: Function create_function() is deprecated in /sites/ on line 111 FS#5415 : Auto change directory, playback stops



FS#5415 - Auto change directory, playback stops

Attached to Project: Rockbox
Opened by Anonymous Submitter - Monday, 22 May 2006, 15:54 GMT
Last edited by Dave Chapman (linuxstb) - Thursday, 25 May 2006, 23:09 GMT
Task Type Bugs
Category Music playback
Status Closed
Assigned To No-one
Operating System iAudio X5
Severity High
Priority Normal
Reported Version
Due in Version Version 3.0
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


standard settings + "Auto-change directory = on", "Repeat = off".
(cvs 2006-05-22 06:57) says " 22-May-2006 09:00"

when playing the last file in a folder it jumps nicely to the first file of the next folder, but only plays like 2 min of that song then playback stops (for flac files, mp3s seems to play longer, sometimes even a few songs, but also eventually stops).
to continue you can either skip to the next track or select a track from the filebrowser, but you can't skip back to the beginning of the track it stops on.
to me it seems like the codec-bar in "Info->Debug (Keep Out!)->View audio thread" ends up empty to early, also the "boost ratio" falls down and ends on 0% at the same time as the codec-bar turns empty and playback stops.
This task depends upon

Closed by  Hardeep Sidhu (hardeeps)
Saturday, 03 June 2006, 17:26 GMT
Reason for closing:  Fixed
Additional comments about closing:  Thanks for the detailed steps. This is fixed in latest CVS.
Comment by Paul Louden (darkkone) - Tuesday, 23 May 2006, 01:16 GMT
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.
Comment by Andy Robinson (Andy R) - Friday, 26 May 2006, 22:03 GMT
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.
Comment by Paul Louden (darkkone) - Friday, 26 May 2006, 22:05 GMT
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.'
Comment by Hardeep Sidhu (hardeeps) - Friday, 26 May 2006, 22:06 GMT
Please try with the latest build.
Comment by Andy Robinson (Andy R) - Saturday, 27 May 2006, 11:31 GMT
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.
Comment by Andy Robinson (Andy R) - Saturday, 27 May 2006, 18:00 GMT
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.
Comment by Paul Louden (darkkone) - Saturday, 27 May 2006, 18:01 GMT
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.
Comment by Andy Robinson (Andy R) - Saturday, 27 May 2006, 18:09 GMT
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.
Comment by Paul Louden (darkkone) - Saturday, 27 May 2006, 18:13 GMT
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.
Comment by Hardeep Sidhu (hardeeps) - Tuesday, 30 May 2006, 18:27 GMT
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.
Comment by Andy Robinson (Andy R) - Tuesday, 30 May 2006, 21:13 GMT
That looks like the sort of directory structure I would find failing on my box. Where do you want me to send the files? 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.
Comment by Hardeep Sidhu (hardeeps) - Tuesday, 30 May 2006, 21:49 GMT
The easiest way would be to make the files available somewhere online and e-mail me the location (rockbox AT For the config info, just post the file created by Menu->Manage Settings->Write .cfg file.
Comment by Andy Robinson (Andy R) - Thursday, 01 June 2006, 14:21 GMT
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.