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#8508 : Ogg Files: Pressing 'previous' moves to 'next' song



FS#8508 - Ogg Files: Pressing 'previous' moves to 'next' song

Attached to Project: Rockbox
Opened by Sean Brennan (sean_b) - Thursday, 24 January 2008, 20:50 GMT
Last edited by Nicolas Pennequin (nicolas_p) - Monday, 14 April 2008, 10:52 GMT
Task Type Bugs
Category Music playback
Status Closed
Assigned To Nicolas Pennequin (nicolas_p)
Operating System All players
Severity Medium
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


Build used: r16137-080122.
Player: iRiver iHP-140

Folder contains a number of tracks in ogg format

Use browser to select a track (say track 3)
- track begins to play.
Press 'next'
- next track begins to play (now track 4)
As playback starts on new track press 'prev'
- next track plays (track 5)
As playback starts on new track press 'prev'
- next track plays (track 6)

It seems that as the next track is being buffered pressing 'prev' causes it to move to the 'next' track. (this is a guess)

This only seems to happen for ogg files. I can't make it happen on mp3

This task depends upon

Closed by  Nicolas Pennequin (nicolas_p)
Monday, 14 April 2008, 10:52 GMT
Reason for closing:  Fixed
Additional comments about closing:  r17107
Comment by x (vmh) - Friday, 25 January 2008, 20:56 GMT
I have the same problem with my h100, but with the difference that I cannot reproduce it each time. Sometimes 'previous' is correct ('previous') and sometimes pressing 'previous' will change to the next track.
I also tested it with mp3 files and have the same result as you: 'previous' works correctly.
Comment by Giles (gilesn) - Monday, 28 January 2008, 08:21 GMT
(iPod5G, itunes file structure, playlist of 38 AACs)
Pressing previous sometimes goes to next followed by a lot of disk activity then a temporary freeze i.e. screen shows track is playing but it's stuck at position 0.00, no response from buttons. Then toggling between play and pause, the track doesn't start.
Comment by Giles (gilesn) - Thursday, 14 February 2008, 09:19 GMT
(iPod5G, itunes file structure, playlist of OGGs)
Pressing previous moves to next, then after a couple of more presses I got 'Undefined instruction at 058A2174 (0)'
Comment by Giles (gilesn) - Thursday, 14 February 2008, 09:21 GMT
My previous issue was with a recent build (16304)
Comment by Steve Bavin (pondlife) - Tuesday, 04 March 2008, 17:41 GMT
Is this still a problem? I suspect it's been fixed.
Comment by Sean Brennan (sean_b) - Tuesday, 04 March 2008, 17:42 GMT
I have tried this with the latest build - r16509-080304 - and the situation has gotten a little stranger.

The 'pressing previous gives next tract' behaviour i originally described still occurs.

The new wrinkle is that that 'track x of y' display on the wps decrements while the actual track playing increments.


- i have a folder with 12 tracks and start on track 3, display shows 3/12
- and do the 'next' followed by 'previous' dance above...
- track 5 plays while the display shows '3/12'
- prev then plays track 6 while the display shows 2/12
- prev then plays track 7 while the display shows 1/12
- prev 1 more time plays track 8 while the display changes to 25/25 (which is the number of tracks in the folder 'before' the current folder)

while all of this is going on the WPS displays the correct id tag info for the file that is actually playing


here's where it gets weird.....

if i now press stop (while playing track 8 in my original folder) and the press play...

track 25 from the previous folder plays, but it starts at the time index where i stopped track 8.

I've also noticed that if i let the track play for a while (how long, i'm not sure but 5 to 10 secs seems to do it) and then press prev... it moves to the previous track as identified by the WPS 'track x of y' indicator and not the track prev to the one that is playing....

so if track 5 is playing and the wps says 3/12, and i wait for the track to play for 10 secs and the press prev... track 2 plays and the wps says 2/12


so if track 5 is playing and the wps says 3/12, and i wait for the track to play for 10 secs and the press stop and then play... track 3 starts playing from 10 seconds in....

it looks like the buffering is getting out of sync with the 'current position' pointer, but it does re-sync on a stop/start.

I hope this helps... (and isn't TOO confusing)

Comment by Giles (gilesn) - Wednesday, 05 March 2008, 09:53 GMT
Still a problem on ipod5G, playlist of 3 OGGs A, B, C, whilst playing B, clicking previous twice goes to track C instead of expected A. Display briefly shows A but then shows C and plays C. Clicking previous again multiple times then just moves to the beginning of the current track (C).
Comment by Jon (lemonman) - Thursday, 13 March 2008, 21:09 GMT
I'm seeing this on my 5G ipod also. I use ogg files.

It seems the 'previous' button action is correct if the buffer is empty, so after repeated presses it will function correctly again.

I don't use file view, so I don't know if it occurs there. I see the bug using albums in the database, though.
Comment by Greg Erwin (Gregory) - Wednesday, 02 April 2008, 12:49 GMT
I have a sansa e200 with the latest version of rockbox and I am using ogg files. I'm sorry if my discription is hard to follow, but I am trying to be as descriptive as possible.

After I start playing any song from any playlist and then skip to the next track and then try to go to the previous track, the wps will show the previous track for a moment, and then it starts playing the track after itm as if I had hit the next button instead.

At this point, the player "thinks" it's on track 1, as it will not go back any more and the playlist shows it's on the first track while it is clearly playing the 3rd.

Startng on, lets say, the fifth track from an album or playlist and hitting previous first works fine. If after that though, I go to the next track and then try going back, it has the same problem, as well as subsequent presses of the previous button.

Once the player reaches the last song of the playlist (by pressing previous ), pressing previous again causes it to start playing the track shown when looking at the playlist. in other words, it plays the track it would play as if all the previous button presses had worked normally.

Now, after this, hitting previous will actually go to the previous track, but if I skip to the next track by pressing forward and then hit previous, the same thing happens.

The version is the latest, and a format and reinstall does not help either.

Letting the player just play through the first song and then hitting previous does the same thing.
Also, selecting an album from either the file viewer or database makes no difference.

I'm guessing that figuring out which build this bug started in would be of good help?
Comment by Nicolas Pennequin (nicolas_p) - Thursday, 03 April 2008, 21:46 GMT
I think this might be fixed by r16955. Could someone confirm?
Comment by Sean Brennan (sean_b) - Friday, 04 April 2008, 14:57 GMT
Sorry, not there yet.

Although you have reverted to the behaviour of the r16137-080122 build as it was in my original comment, which has eliminated the additional weirdness from the r16509-080304 build.
Comment by Sean Brennan (sean_b) - Friday, 04 April 2008, 16:43 GMT
I have more information that may help.

I download the rockbox nightly build often, but don't install it often. As luck would have it, i can narrow down when this was introduced to within 2 days...

The problem with back moving to next does NOT occur in the r16011-080107 build.

It does occur in the r16029-080109 build.

I hope this helps.
Comment by Nicolas Pennequin (nicolas_p) - Friday, 04 April 2008, 17:00 GMT
hmm, there were a few commits that changed playback.c within that timeframe: r16019, r16025 and 16028 (r16027 was just comments). r16019 is the one I recently reverted, so that leaves r16025 and 16028 as the possible causes.
Could you maybe try to determine which was the responsible by trying r16025? You'd need to build from source after having used 'svn up -r16025'.
Anyway, I'll need to start trying to reproduce.

For reference, here is the changelog to playback.c up to r16029:
Comment by Sean Brennan (sean_b) - Friday, 04 April 2008, 17:41 GMT
Unfortunately i have no capability to do builds. Sorry.

All i've got are the nightly builds that i download as zip files at the time.

It's pure chance that I still had the Jan 7th 8th and 9th builds on my hard disk, so i've only checked this today for the first time. The build from the 8th crashes on boot on my player, so i've deleted it.

I'd never loaded these builds, i just grab the nightly zip file when i remember. The Jan 17 was the first one i'd loaded in since around last october. I first noticed this problem after a few days use so i downloaded and installed the Jan 21 build to confirm the problem was still there so that i was reporting on a 'current' build.

Comment by Sean Brennan (sean_b) - Friday, 04 April 2008, 17:49 GMT
It's just occurred to me...

If you have the capability to build those versions, we could save your time trying in trying reproduce the problem by making the binaries and i'll try them here.

I only need the executable file. I'll drop the folders/etc. from the 9th on the machine first so the folders and config are correctly set up for the binaries from that time period.
Comment by Greg Erwin (Gregory) - Saturday, 12 April 2008, 23:40 GMT
The bug was introduced with build r16025. Something is this code caused it:
Comment by Greg Erwin (Gregory) - Sunday, 13 April 2008, 06:07 GMT
Patched:  FS#8882