Rockbox

Are they not added to the playlist at all or are they skipped past in the playlist?

Will it play the skipped songs if they are selected directly?

I'm seeing this too on my Sansa c250 and tried to research a bit - playing mp3 of various formats (vbr, cbr and various bitrates, most have ID3v2.3 tags, some additionaly ID3v1.1) Here's what I found with the help of my own WPS which also shows next track info (but got the same thing with the text only default WPS, less visible though).

First off the problem affects certain folders consistently for me, no matter which track I'm starting the playlist with the track after the next will be skipped; starting with track 10 or 11 in a folder which contains 12 tracks will skip the last track and chosing track 12 often goes to the WPS for a split second but will immediatly stop and drop me back to the file browser sometimes it doesn't even go to WPS, just showing a bit "disk" activity in the statusbar but stays in the browser and doesn't start playback. In such a folder, "resume" will start playback from the track start of the next track.

What I can see is best explained with an example, let's say in my broken folder are track-1.mp3 to track-4.mp3. When I start the dynamic playlist by selecting track-1, the following happens:
- playback starts, WPS shows correct info of track-1.mp3, next track info is blank buffering is going on (disk activity shown)
- when it knows that there is a next track (indicated by a graphic in a %?Fn conditional in my WPS), it'll show the metadata of track-1.mp3 as next track info
^this indicates a "broken" folder, if it's a working one it either is still blank or it shows the metadata of a track that was next track in my previous playlist
- after a few more seconds of buffering (I assume when the metadata of track-2 is read in), the next info line will be updated correctly with track-2 but...
at the same time playlist position info switches to "2" even though position 1 is still playing, the playlist viewer also indicates track 2 as playing now
(this playlist position change is the one thing that is visible in the default WPS too)
- on track-1 > track-2 change: track-2 starts playing correctly, playlist position is again one off at "3", next track info shows track-4 info...
- track-2 changes to track-4 (so track-3 is skipped) everything else is in sync again too

As I said, in some folders there is no problem at all and I couldn't see any connection between working folders which makes them different to non-working ones or vice versa. (Checked for bitrates, ID3 types, folder names, number of files in a folder, other files in the folder, date I put them on my player - nothing specific to tell me if it's a broken one or not). After putting a new Rockbox version on today (and initialising the database 2 times), 2 of the directories I noted as problematic suddenly started working but this at least seems to stay this way. I have no idea why because I didn't touch the content of these folders. Most of these noted down ones are still broken though.

I am seeing this behavior also on my e280 (running r16179M-080127). I have discovered that this behavior seems to depend on the presence of album art. I had a directory that was previously well behaved when it contained an improperly named album art file. When I renamed it so that the WPS would properly display it the playback began to show the defects described -- the playlist shows track 2 as currently playing when track 1 is clearly playing. The WPS also claims that it is track 2. Strangely, removing the album art did not revert the directory to normal behavior. Can anyone else corroborate a correlation between the presence of album art and these glitches? The directories that have no album art on my Sansa seem to be the ones that behave normally.

Nevermind. I have contradicted that theory. I thought I might have found some other correlation with file type. But that doesn't hold up either. I cannot identify any determining factor for which directories will be affected at the moment. But I agree that certain directories have persistent problems and others persistently don't have the problem.

I can't replicate this on Sansa e200 w/ r16150 (+ DD v11 patch, but that shouldn't matter).

I can reproduce this problem with SVN (r16230), but could not reproduce it using the SansaE200-v15975-DDv14-BBv1 build.

FWIW, this just happened to me on H300 witrh r16131 (shamefully old I know). I was playing an album from the database. Tracks 1-9 played fine, but then it skipped back to track 8 (instead of 10). I assume this was at the first rebuffer, but wasn't paying enough attention to be certain; I wouldn't expect the rebuffering action to do anything which would affect playlist position, but I do have Gather Runtime Data enabled, so maybe that's doing something silly.

All files were CBR MP3. Album art was present, using Cabbie 2.0.

Mainly I wanted to note that this isn't just a Sansa, or flash-based target problem, or restricted to the File Browser.

Maybe a similar problem happens on the coldfire targets too - I think (not even sure) I saw the problem with resuming at start of the track instead of a mid track position on my M5 /once/ too since I tried but usually all works fine. On c200 I also had two occasions where one track was repeated, so the right track was skipped instead (the playlist showed the correct entries) but I wasn't able to reproduce so far. And this is the difference to the things I tried to explain in my previous post - they are very consistent for certain folders for me. It is always the 3rd track from start of the playlist that is skipped, btw. I also watched the buffering debug screen and there are more tracks in buffer (seen all differnt kinds of numbers, no obvious similarities there too).

About the album art suspicion: also one of my thoughts in the beginning. My WPS shows album art but I only have like 7 or 8 albumname.bmps and it happened in folders with and without them; even one of the folders that suddenly started working again contained album art. And as I said, I also tried with the text only default WPS and the same happens there.

> but I do have Gather Runtime Data enabled, so maybe that's doing something silly.
Hmm - I had it enabled too, it was also suspicious to me and I /thought/ I turned it off for my tests... but it was still enabled when I checked back right now. Turned it off and the first folder I tried, that had the problem, seems to play fine now.

P.S.: No, unfortunately this can't be everything, just tried a different folder and it's still there.

I've been experiencing the same thing on all daily builds for over a week now on my ipod photo. When I select the first song of an album, it pulls it up properly, but the track is being listed as track 2. It then goes properly to the next track, but lists it as track 3. After the second track, it seems to self-correct itself, skipping over the real track 3 completely, and going to track 4, as well as displaying that it is track 4. No matter what track I start up on, it always skips over/self-corrects the third track in the sequence (ex. - start at track 1, track 3 gets skipped over, start at track 5, track 7 gets skipped over). FYI, I don't actually create play-lists, but just go to a folder, and select the first file in it to start an album off.

If I pull track 1 up and it's displaying it as track 2, I can hit the back button to restart the track, and it starts displaying it as track 1 properly at this point, and the problem goes away. It's a simple work-around, but kind of a nuisance at the same time.

I have just tested on my iRiver H140 and Sansa e280 (both running build r16172-080126 - a day older than the start of this bug report) and I curiously I cannot reproduce this on either DAP - displayed tracks were coreect for the music playing at the time and track 3 played OK too.

Most of my albums are Ogg Vorbis at q6 (ripped with EAC and encoded with oggenc2). Also tried some MP3 albums too (downloaded not ripped) and they played correctly too.

Just updated both targets to r16231-080206 and repeated the above tests (same albums) - again everything played correctly on both targets. I am perplexed that I am not seeing the same behaviour others are...

If there is any info you want from my apparently working DAPs then let me know.

I also had my player set to gather runtime data. This may not be the entire story, but maybe it's fruitful for us to compare settings. Once again, I cannot test or provide my settings until I get home later.

I tried to research some more to find out more about the why and when, it wasn't too successfull so far but I'll post my results here - maybe it gives someone else an idea (and to avoid duplicating efforts).

About the "gather runtime" idea: considered it to be possible first BUT I've since deleted all .tcd files, initialised database again multiple times with this setting off and it is still happening in some of my folders. I also tried what happens when I enable this setting on my M5 and I couldn't see this behaviour there, every folder plays fine there - even a "broken" one that I copied directly from my c200 to the Iaudio. So now I think that it doesn't have to do with it.

Deleting a folder and copying the original from my PC again or placing a "broken" folder one level up in the directory structure did not have any influence - it remained broken on the c200.

About different settings in general: interestingly I could "break" 1 or 2 more folders by enabling settings which take more RAM (e.g. raising "Max files in dir", enabling "Cuesheet support" and ".last-FM log").

Then I tested with different builds and found out that this behaviour definitily /occured/ with revision 16105 (16104 and earlier doesn't show any problems) but I'm not convinced that this is the root cause (admittedly more of a feeling though). To investigate further I isolated some commits to playlist/playback/buffering and reversed them as patch to revision 16246 - only one commit at a time individually and in reversed chronological order. No changes until revision 16019 but when reverting the changes between 16018 and 16019 I at least get a different behaviour: now the first track is skipped almost immediately. That means - I select track-1 > Rockbox shows WPS with track-1 for a second and then jumps to track-2, so at least playback and playlist position are the same. And this again happens only but consistently in those "affected" folders, others still play fine.

I still have not the faintest idea what determines a broken folder, I hope this inspires someone...

Apart from the outright song skipping I had been experiencing "codec failure" with the SPC codec. The first track played would always fail. In rev 16104 it worked fine, in 16105 it would simple freeze up completely, sometimes with a "codec failure" left on the screen. The freeze continues until 16154 when jhMikeS added checks for it, and it then it does the codec failure on first track but continues working on subsequent tracks.
Tests were done with .rockbox completely wiped each time, so no settings not default. Test directory had 9 SPCs and a non-music file at the end.
Maybe jhMikeS's comments in the 16154 commit will be helpful?

A bizarre result:
The same directory, copied a few levels higher in the hierarchy, plays the first track fine.
So if the directory is in /, /musica, or /musica/emu it works. If it is in /musica/emu/spc or /musica/emu/spc/a it does not.

Path length may be having something to do with it. "/musica/4 Nin Shogi 4nsOOOOOOOOOOO" (11 Os) works, but rename it to "/musica/4 Nin Shogi 4nsOOOOOOOOOOOO" (12 Os) and it doesn't. However, 13 Os works, too! (14 does not, etc).
Up to 7 Os works (for a path of 23+7=30) but 8 (31) doesn't, 9 (32) does, 10 (33) *does*, 11 (34) does, 12 (35) doesn't.

---
This doesn't seem to be fully consistent, I can't get arbitrarily named directories of these lengths doing the same thing.

I'm getting the same problem on my iRivier H10 6GB.

It happens when playing from a directory or from the database, and it happens almost all the time for me.

Typically it will play through track 1, then play track 2 but it will show on the display as track 3. The 'next' track is therefore listed as track 4 and it promptly plays track 4. Thus skips the real track 3.

Also happened to me on track 10 with one album, although it might be related there to stopping/starting frequently. i.e. maybe it's just always the 2nd track?. Unfortunately at work I have to stop/start frequently.

My albums and tracks are arranged in the format '/Music/Artist/YYYY - Album Name/NN - Track Name.mp3' (where YYYY is the year and NN is the track number, e.g. 01).

All MP3s are converts with LAME by Foobar2000 from Flac rips off my original CDs using EAC.

I'd say the severity of this is higher than 'low' as it really prevents listening to albums which I do a lot, unless there's a workaround.

I'm also experiencing this when using the database, or even an m3u playlist, so I don't believe this bug is only affecting when you play direct from the "files" view, like the description above claims.

Just to add that I'm also finding it very hard to play the last track in an album, although perhaps this is down to the last being track 10. It gets to (for example) track 9 out of 10, starts to play track 10 and stops. Then going back to play track 10 just makes it stop again. If I play track 9 it's shown as track 10, and after a number of attempts I get track 9 to display as track 9, then it might play track 10 if I skip to the next track.

Something of note with all of this is it appears to take a while to update the 'Next' track for display. It may initially get it entirely wrong and then after 10 seconds or so it updates. Still has a problem with track 3 and 10 though.

People are also having trouble playing directories/playlists that only contain a single track. See this forum thread: http://forums.rockbox.org/index.php?topic=15289.0

This was hopefully fixed with r16392. Can someone confirm?

I just loaded up today's daily build (16402), and the issue is no longer occurring on my ipod photo 60 gig. Thanks to everyone who worked on this issue.

Fixes the SPC issue I had complained about on my Sansa e260 and iPod Color. Thanks!