Rockbox

What's the most recent SVN revision you've tested this with.

Feb 13

I've also used various builds from January. The problem does not occur until I load the database, however.

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.

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.

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.

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.

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.

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?

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?

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.

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.

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.

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.

"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.

http://www.rockbox.org/twiki/bin/view/Main/SimpleGuideToCompiling

If you need help with it, feel free to ask in the forums.

Hi Avi,

If you could, please e-mail me two sample tracks (i.e. before and after the gap) to 11r6iom02@sneakemail.com.

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.

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

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.

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.

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?

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.

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?

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.

8601 is fixed. Update?

any news?

Playback works like it should now!

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