FS#6068 - Position display resets (0:00) on resume

Attached to Project: Rockbox
Opened by Mikkel Bernhof Jakobsen (bernhof) - Tuesday, 26 September 2006, 14:03 GMT
Last edited by Brandon Low (lostlogic) - Saturday, 01 December 2007, 18:35 GMT
Task Type Bugs
Category Music playback
Status Closed
Assigned To No-one
Operating System Iriver H100 series
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


When I stop playback (not pause) and resume thereafter, the position sometimes resets to 0:00. I noticed that this occurs when I'm listening to a large file (e.g. a live set) and I've passed a certain point in the file. I tried stopping and resuming playback within the first 5-10 minutes, and this works just fine. But I tried again at around 14 minutes, and this time it reset the position to 0:00. At this point, if I try seeking, it starts playback at the actual position which is shown.
This task depends upon

Closed by  Brandon Low (lostlogic)
Saturday, 01 December 2007, 18:35 GMT
Reason for closing:  Out of Date
Additional comments about closing:  I'm closing this as if a similar bug still exists, it is most likely a new bug in code now that MoB is in. Please post a new bug if similar issues persist.
2007-12-02: A request to re-open the task has been made. Reason for request: This wasn't fixed in april. If you'd like me to retest on a huge file, I can. But it is insane to simply assume that some unknown other bug has fixed it if nothing has been done to address the issue.
Comment by Miika Pekkarinen (miipekk) - Tuesday, 26 September 2006, 14:45 GMT
Please try again if that issue still happens.
Comment by Mikkel Bernhof Jakobsen (bernhof) - Tuesday, 26 September 2006, 21:55 GMT
It still occurs in the daily build from sep. 26th.
Comment by Steve Bavin (pondlife) - Thursday, 28 September 2006, 18:27 GMT
Does this happen with any particular file format, or all of them?
Comment by Mikkel Bernhof Jakobsen (bernhof) - Saturday, 30 September 2006, 08:25 GMT
It occurs with .mp3, which is also the only format I've tried with. So I don't really know about the other formats.
Comment by Václav Brožík (pabouk) - Sunday, 01 October 2006, 17:00 GMT
I can confirm the bug. It happened once on my iriver H120 with 64 kbps mono MP3 approximately 45 minutes long. If you want to examine the file I can upload it to a webserver. The bug did not appear with files of the same bitrate and similar length.
Comment by Steve Bavin (pondlife) - Monday, 02 October 2006, 07:13 GMT
Yes, an example file would be very useful. I have tried to reproduce it wirh a 30 minute long MP3 (stereo, 128kbps), but nothing unusual has happened.

Does it ever happen with the first file you play, or might it only happen after other files have played?
Are you just pressing STOP, then PLAY to resume? Or are you closing down the player completely?
Comment by Mikkel Bernhof Jakobsen (bernhof) - Monday, 02 October 2006, 14:14 GMT
I have several files of similar length, bitrate etc., and I noticed just now that the only ones causing the position to reset, are those with no ID3 tag or with ID3 v1.1 or below. All files with ID3 v2.3 works fine. Don't know if it actually means anything, though.

The bug occurs in both the scenarios you mention: STOP then PLAY, and also on shutdown before resuming. It also occurs both first play and subsequent plays.
Comment by Mikkel Bernhof Jakobsen (bernhof) - Monday, 02 October 2006, 14:16 GMT
I should probably add that mine is a H120 as well.
Comment by Václav Brožík (pabouk) - Monday, 02 October 2006, 17:51 GMT
The file is here:

Unfortunately I cannot succesfully duplicate the bug:
- When I moved the file to a different directory the bug did not appear.
- I renamed the original directory, created a directory and subdirectories of the same names and copied the file there from a PC. The bug was there.
(The directory structure was "/_podcast/Český rozhlas - věda a technika")
- I renamed the directories to /_A/A and the bug was still there.
- I deleted the .rockbox directory, upgraded the firmware to the latest CVS and reset settings. The bug was there.
- I moved the file to the root directory. The bug was there.
- Deleted the file and transfered it from the PC again. The bug disappeared.
- I tested the file in the original renamed directory ("/_padcast/Český rozhlas - věda a technika") and the bug WAS THERE!
- I compared MD5 checksums of the files. THEY ARE THE SAME: 60a386834c35a777ee9c81c6116304e8.

Now I am getting crazy. My last Idea was that it could be somehow caused by dircache but it is turned off after resetting the settings. Do you have any idea?

Some more notices: The bug also appears after resuming a bookmark (attached). The bug does not appear when you are resuming a point closer to the beggining of the file (maybe less than 28 minutes?) but it seems that this limit changes.
Comment by Václav Brožík (pabouk) - Tuesday, 03 October 2006, 17:25 GMT
My next idea was that the bug depends on the position of the file in the directory (on the filesystem level). It worked :-) So I hope that there are directions to reproduce the problem:

1. On Rockbox HDD create directory "/a".
2. Create an empty file "a.txt" inside the directory.
3. Copy the downloaded 00443746.mp3 into the directory.
4. Play the file.
5. Seek forward at least to 3:00.
6. Stop the playback.
7. Resume the playback (by pressing play on iriver).

Then after stopping and resuming it resumes at the correct point but
the time shown on the display always starts at 0:00.
After deleting the "a.txt" file the bug is still there.
The bug probably depend on the file position in the directory table.

If the bug does not appear try to seek further into the file please.

Let me know if you can replicate the bug please :-)
Comment by Steve Bavin (pondlife) - Wednesday, 04 October 2006, 07:11 GMT
Hi Vaclav,

Sorry, but I still couldn't reproduce (on my H340). Maybe it's related to dircache or some other settings? Could you please post back with your settings (i.e. a .CFG file).
Comment by Václav Brožík (pabouk) - Wednesday, 04 October 2006, 18:25 GMT
Hi Steve,

I did some more tests:
1. Upgraded to the latest CVS build
2. Created directories __a __b and __c
3. Copied the file into the directories
4. While booting the new build I cleared the settings.

The directory "a" from the previous test was still there so I tested the file.
I realized that the time point after which the bug appear had moved! In the table below
you can se the time point intervals from the previous test (A), after booting and after switching
the configuration to my settings (they did not move after switching) (B), after rebooting with
my settings (C). You can see that every file has the point at a different place and that the point moves
probably after changing the HDD content.

dir A B C
a 2:00-3:00 27:55-27:57 21:00-22:00
__a --------- 40:31-40:41 24:00-30:00
__b --------- 43:00-43:10 01:10-01:12
__c --------- 04:03-04:05 00:39-00:41

The bug appears with default settings too. My settings are included for completenes.
When trying to reproduce the bug try to seek close to the end of the file.
Comment by Václav Brožík (pabouk) - Thursday, 05 October 2006, 06:58 GMT
Probably I wrote the description to quickly yesterday. Here is a better explanation for the table:
* The time point after which the bug appears is constant probably when you do not write to the HDD.
* The time point moves probably after writing to the HDD.

* The lines are the different instances of the testing file 00443746.mp3 in the directories /a, /__a, /__b, /__c.
* The three columns represents the three testing situations I mentioned yesterday. The time points did not change during the testing situations but they changed between them.
* The time points were located in the time intervals in the table. Some intervals are wider because it was work-intensive to narrow them down.
Comment by Peter Olson (Peter200lx) - Friday, 06 October 2006, 17:20 GMT
I'm getting the same problem. I stop playing and shut the player (H120) down in like the middle of a podcast. I'll start it back up and then press play/pause to resume and it starts playing fine. But the bar and the time counter are both at 0. I can listen fine to the rest of the podcast, but if I try to skip back a couple seconds to hear somthing I missed, it jumps to however long I've been lisening since I started.
Comment by Peter Olson (Peter200lx) - Friday, 06 October 2006, 17:29 GMT
BTW, the file structure that that files I've noticed this with is
/Rush *
/Narnia Fans *
/other *

The files in the rush folder are just encoded with Win-LAME, no ID3 tag at all, and the ones in the Narnia Fans folder I'm not sure what ID3 they have.
Comment by Peter Olson (Peter200lx) - Friday, 06 October 2006, 17:31 GMT
ack sorry, didn't come out right
../Narnia Fans
Comment by Bryant (buraianto) - Friday, 08 December 2006, 20:15 GMT
I have noticed this bug on my Nano 1G, when pressing play immediately after booting to resume a podcast. The timer and progress bar will both show 0:00 but the podcast may be in quite a ways.

I saw this with Rockbox build cvs-061208.

Example file path:
Comment by Ben Keroack (bk) - Tuesday, 12 December 2006, 16:34 GMT
Yes, this bug still exists on Nano 1G (but not my X5). It occurs with MP3 but not Ogg Vorbis (no other codecs tested). It happens consistently when resuming into the middle of a long (3-5 hour) MP3 file immediately after startup.
Comment by Adam Felson (adamf663) - Friday, 05 January 2007, 16:00 GMT
This bug is still in rockbox as of 1/2/2007, seen on an iaudio x5.

It is with very large .mp3 files and prevents resuming from bookmarks as well.

One bit of wierdness is that sometimes rockbox will successfully resume, but will fail to properly display the track time, displaying time starting with 0:00. For example, advance to a position 7 hours into a 15 hour .MP3 and shut down. Upon restarting, it might resume playback where it left off, but will diosplay 0:00 and counting. If the user tries to fast advance from that point, playback will resume at the displayed time.
Comment by Matt Gottlieb (cracksbacks) - Sunday, 14 January 2007, 00:51 GMT
This bug is still in the h300 player. I have seen it in the various custom builds out there. It occurs when the player shuts down and restarts, when a bookmark is selected or when I return to a file after using the radio function. Same presentation as everyone else. The player continues at the bookmarked point but the time tracker says 0:00 and any attempt to fast forward or rewind results in a reversion to the actual time.
Comment by Matt Gottlieb (cracksbacks) - Thursday, 18 January 2007, 19:18 GMT
UPDATE: I am using a build from a few days ago (1/15/07) and the bug seems to have worsened. It seemed that before, this bug only would occur after about 30 minutes of the track. Now it occurs regardless of the time elapsed.

To make things very clear, when a bookmark is executed the resulting time counter says 0:00 while continuing where the bookmark left off. Sometimes, if the file is progressed more than a half hour or so, attempting to resume a bookmark results in the occasional bookmark of the last second of the file to be created.

This bizarre behavior has been going on for about five months. I see it is being reported on multiple players. I lack coding skills so I will continually update my status as I try new builds and the behavior changes.
Comment by Matt Gottlieb (cracksbacks) - Wednesday, 31 January 2007, 21:40 GMT
UPDATE: I am currently using a build from - the norbusan build from 9/14/06 - and it seems to be without the bookmark bug. This thread was started on 9/26/06 so the problem must have surfaced during that time.
Comment by Steve Bavin (pondlife) - Monday, 02 April 2007, 15:53 GMT
Hi Matt,

Please can you check if this is in the current (standard) build or not? Thanks.
Comment by Matt Gottlieb (cracksbacks) - Monday, 02 April 2007, 15:59 GMT
I have actually since switched players. I am using a rockboxed gigabeat f40. The bug is there slightly, long files resume from bookmarking at the proper area with no effects noticed on the timer bar. The only anomaly I see is the file stops instantly but it is easily resumed. I have sold my old iriver so I cannot test the newest iriver builds. I will post if anything changes in the gigabeat build.

Thanks for responding.
Comment by Adam Felson (adamf663) - Monday, 02 April 2007, 16:35 GMT
Tested with a 20 hour mp3.
Advanced to around 4 hours, shutdown creating bookmark.
Powered up, playback corrected resumed including correct display.
Went back to around 2 hours, shutdown creating bookmark.
Powered up, playback corrected resumed including correct display.
Switched to first bookmark: playback resumed to correct place, but display showed 0:00
Advancing from this point lost playback location and resumed somewhere near 0:00.
Comment by Adam Felson (adamf663) - Monday, 02 April 2007, 16:36 GMT
oops. s/"playback corrected resumed"/"playback correctly resumed"