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#8634 : Gapless Playback on H140 does not work with new builds



FS#8634 - Gapless Playback on H140 does not work with new builds

Attached to Project: Rockbox
Opened by Avi (TrappyWappy) - Saturday, 23 February 2008, 18:14 GMT
Last edited by Steve Bavin (pondlife) - Thursday, 17 April 2008, 17:28 GMT
Task Type Bugs
Category Music playback
Status Closed
Assigned To No-one
Operating System Iriver H100 series
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


I have been having trouble with new builds (since January 2008, I cannot remember exactly what date, but the problem persists with all new builds) when it comes to gapless playback on my H140. I have Ogg Vorbis and LAME MP3s on my iRiver, but mostly Vorbis (about 8000 files or so). I use the database, and I have the load to RAM option set to "Yes." Whether or not I change this does not affect whether or not tracks play gaplessly or not.

Music plays gaplessly on the current build I am using (December 24) with or without a built database. Whether I update the build by overwriting or just deleting the old .rockbox folder, gapless playback stops working. I have tried formatting my iRiver, I have used both version 5 and 6 of the bootloader (currently using 6, problem originated with 5), but I have not been able to successfully use gapless playback with any new build of Rockbox.

Problem persists with both MP3s and Oggs.
This task depends upon

Closed by  Steve Bavin (pondlife)
Thursday, 17 April 2008, 17:28 GMT
Reason for closing:  Fixed
Comment by Paul Louden (Llorean) - Sunday, 24 February 2008, 22:06 GMT
What's the most recent SVN revision you've tested this with.
Comment by Avi (TrappyWappy) - Sunday, 24 February 2008, 22:45 GMT
Feb 13

I've also used various builds from January. The problem does not occur until I load the database, however.
Comment by Paul Louden (Llorean) - Sunday, 24 February 2008, 22:45 GMT
Please test with a current build. Please do not report bugs that you haven't verified in the current build. You posted this while using a 10 day old build, which is quite out of date by Rockbox standards.
Comment by Mike Holden (mikeholden) - Monday, 25 February 2008, 13:37 GMT
I can confirm a problem with Ogg gapless playback with a current build, on my 340. This is playing from m3u playlists, not tested other playback methods.
Comment by Paul Louden (Llorean) - Monday, 25 February 2008, 14:28 GMT
Please state actual SVN revisions, so we can know the specific version number it's tested up through. also, if you could track the bug backwards to when it started, it would also be very helpful.
Comment by Avi (TrappyWappy) - Monday, 25 February 2008, 14:38 GMT
I wish I knew all the specific version numbers that I had tested; it was random throughout January as I had faith that the bug would have been found and fixed after a couple weeks. I just tested again with the Feb 25 build and the problem is still persisting.

The last build I have that I know works is the December 24 build.
Comment by Paul Louden (Llorean) - Monday, 25 February 2008, 14:45 GMT
1) SVN revisions, not dates. Several builds come out every day, so the date is only very slightly useful, and doesn't actually provide much information.
2) You can go back and test older builds. This is what I was asking you to do. If you can track down exactly which SVN revision broke gapless, it will make it much easier for someone to fix it.
Comment by Avi (TrappyWappy) - Monday, 25 February 2008, 15:36 GMT
The Feb 25 build is SVN 16414, and unless I am not seeing something right the farthest back I can go is to Jan 26 (SVN 16170) which is a month after the problem really started occurring. Is there a direction you can point me to older builds?
Comment by Steve Bavin (pondlife) - Wednesday, 27 February 2008, 18:24 GMT
CBR MP3s encoded by LAME --nogap seem to play gaplessly on r16431 for me (on H300). Perhaps you could attach two tracks that exhibit the problem here?
Comment by Steve (stormwatch) - Thursday, 28 February 2008, 18:23 GMT
This is also the same problem on my ipod 5.5g using latest build r16441 playing m4a files of vaious bitrate, gone back to using an unofficial build from last july as I can't get any official builds prior to january that fix the problem.
Comment by Paul Louden (Llorean) - Thursday, 28 February 2008, 18:54 GMT
This is a patch tracker. It exists for people to work on FIXING the problem, not say "Me too, so I'm going to go back to an unofficial build." Why not compile older builds from source and track down exactly which revision caused this problem to start? Seriously, if you're not going to help out, please don't post, as it just clutters the thread up.
Comment by Steve (stormwatch) - Thursday, 28 February 2008, 19:30 GMT
I am just pointing out that the same problem exists on my ipod as well using a latest build. I wouldn't know where to start compiling. Seriously, please explain how your post 'Helps out' as opposed to cluttering the thread.
Comment by Paul Louden (Llorean) - Thursday, 28 February 2008, 19:34 GMT
Because I told you what needs to be done, by someone actually experiencing the problem, before it can be fixed. If you choose to not help out, that's your problem, but it requires someone who's actually having the problem to work on it.
Comment by Avi (TrappyWappy) - Friday, 29 February 2008, 00:57 GMT
"Why not compile older builds from source and track down exactly which revision caused this problem to start? Seriously, if you're not going to help out, please don't post, as it just clutters the thread up."

I have no idea how to do that and the files I want to add as examples are too large to attach.
Comment by Paul Louden (Llorean) - Friday, 29 February 2008, 02:56 GMT

If you need help with it, feel free to ask in the forums.
Comment by Steve Bavin (pondlife) - Friday, 29 February 2008, 07:41 GMT
Hi Avi,

If you could, please e-mail me two sample tracks (i.e. before and after the gap) to
Comment by Sam (kubu4) - Monday, 03 March 2008, 04:53 GMT
This problem is still occurring with build r16493-080302 (fresh installs with newest version of the boot loaders) on the H140 as well as the X5. It should be noted that gapless playback works fine when playing via the file browser. Gapless playback is NOT working when playing via the database. Avi did not note this when he opened the bug report, but I believe it is an important piece of information. This is with OGG files.
Comment by Steve Bavin (pondlife) - Monday, 03 March 2008, 07:34 GMT
Did gapless playback ever work via the database? I'm not sure it's intended to.

I can't repro a problem (using the file browser), so to proceed with this I need 2 bits of info:
- which revision it stopped working in (do an SVN binary chop)
- sample files
Comment by Paul Louden (Llorean) - Monday, 03 March 2008, 07:48 GMT
I'm pretty sure the database *shouldn't* make any difference (I'm not saying it doesn't, I'm saying it shouldn't so if it does it's a bug) because the database should still just put the tracks in a playlist. During playback the tracks aren't coming from "the database" or "the filetree" but rather just by way of the dynamic (or loaded) playlist in memory. Gapless playback should simply be an issue of the playback engine and the buffer, I would think.

Unless Gather Runtime Data is involved, perhaps, or something like that. Just an idea.
Comment by Magnus Holmgren (learman) - Tuesday, 04 March 2008, 11:03 GMT
This could be the same as  FS#8667 . It would explain why it only happens when playing from the database. Playing from a playlist could also trigger it, I think.
Comment by Nils Wallménius (nls) - Sunday, 09 March 2008, 01:37 GMT
I closed  FS#8667  as it was a duplicate of  FS#8601 .

Avi, does the disk spin up on track change and does turning on Directory cache make the problem go away?
Comment by Avi (TrappyWappy) - Sunday, 09 March 2008, 01:52 GMT
I should have noted that yes, the problem only occured when the database was loaded, and the disk did spin up upon track change. I don't know if turning on the directory cache will change anything, but I won't be able to change it until I get back to school in 10 days so I can test it again.
Comment by Sam (kubu4) - Sunday, 09 March 2008, 01:56 GMT
I had contacted Steve (pondlife) privately concerning this issue. He asked me to post what I had written to him in order to provide further insight. A quick response to Nils, though, yes, the hard disk spins between songs (i.e. when the gap happens). For a more detailed description of what I've experienced with this issue, here it is:

Gapless playback will work via the file browser early on. I say this because I was listening to music today and noticed that, at some point, it was no longer playing back gapless, despite the fact that it had started out gapless. Unfortunately, I was listening at work, so I was coming and going and I don't know when it started to NOT work properly again. I have a sneaking suspicion it is somehow related to playlist size. I started out the day with one album in the playlist, but then added a few more albums at some point so that I wouldn't have to keep messing around with the H140 while I was working. Testing out gapless playback with only one album in the playlist works correctly (via the file browser, but not the database). EDIT: I just noticed that gapless isn't working any more (again, after rebooting and starting a new playlist which started out gapless) and the playlist size is only 17 songs. Also, just so you know what to look for, when gapless playback is NOT working, the HDD indicator light on the H140 lights up when there are 2 seconds remaining in the song. Additionally, the time remaining for the current song freezes at the 2 second mark, the song finishes, then there is a pause and the next song begins playing. Anyway, if the problem is not related to playlist size, maybe it's related to how long the player has been turned on, playing music?
Comment by Magnus Holmgren (learman) - Sunday, 09 March 2008, 17:09 GMT
If this is caused by the same thing as  FS#8601 , then the size of the playlist is largely irrelevant as you say. The question is, are the filenames in memory or not? If you just play a directory, they will be. If the dircache is enabled, they should be too (if I understand the code correctly). Otherwise, once you start inserting or removing tracks, they will no longer be (possibly delayed a bit; the playlist code may cache things for a while and I don't know the code well enough to tell for sure). Playlist and database playback will also not keep the filenames in memory (unless the dircache is enabled).

I'd say you probably don't need to do much more investigation at this point. Better wait for  FS#8601  to be fixed, and then see if this bug is fixed too.
Comment by Marc Guay (Marc_Guay) - Monday, 07 April 2008, 18:55 GMT
8601 is fixed. Update?
Comment by Nicolas Pennequin (nicolas_p) - Thursday, 17 April 2008, 16:54 GMT
any news?
Comment by Avi (TrappyWappy) - Thursday, 17 April 2008, 17:26 GMT
Playback works like it should now!

No gaps, no disk spin-up before playing, works well.