Support and General Use > Audio Playback, Database and Playlists

Occasionally skip of track #3 in playlist

<< < (3/5) > >>

Chronon:
It's always worthwhile testing the current build to see if a change has fixed what you're seeing.  

Do you also see the other behaviors that crescentfresh described?  You might chime in on the Flyspray task since it's good to have a track record of which builds exhibit a given set of behaviors.

=====

This behavior is evident with current SVN (r16230).  Interestingly, I just tested the current Device-Disable build by Soap (SansaE200-v15975-DDv14-BBv1) and was not able to reproduce this behavior.  I'll add this to the Flyspray task also.

deadkenny:
Hi,

Just to say I tried a build from yesterday (r16239-080207) on my iRiver 6gb H10 and noticed what appears to be the same problem. I found tracks 3 and 10 got skipped, although the display was showing the correct count of tracks, just the wrong track names in places (e.g. it was saying track 9 was track 10, then played track 11 after the real track 9).

I don't know if it might have been affected by frequent pause/resuming, as I'm listening at work and often get interruptions.


I posted about it here: http://www.misticriver.net/forums/rockbox-h10-series/45096-h10-rockbox-progress-discussion-thread-52.html#post588046

Edit: Just to add, this isn't occasional for me. It's almost every album I play. And the same occurs whether I use the database or file system to play.

Plus I just played an album from the start without pausing/resuming and it still did it. Had an album of 4 tracks. It played track 1, then track 2 but called it track 3 and then plays track 4. i.e. skipping track 3.

Chronon:
I have had this problem persistently as well.  But I am not seeing any problems with r16299.  Track 1 is listed correctly and no skipping of the 3rd track on any of the directories that were formerly giving problems.  Will try with current SVN and report back.

*Oops, I don't have my cable for my e280 with me so I can't do this until the end of the day.

** scratch that.  I don't know what happened earlier -- still seeing this problem.

Strife89:
The problem is also affecting Sansa c200 builds (currently I'm using revision 16314, February 15).

crescentfresh:
This problem appears to be resolved.  According to flyspry, the fix was implemented in build r16392.  Today's daily build is working great for me on my 60 gig ipod photo.  According to flyspray, it is no longer occurring on the Sansa e260 either.

Navigation

[0] Message Index

[#] Next page

[*] Previous page