Rockbox

Please try again if that issue still happens.

It still occurs in the daily build from sep. 26th.

Does this happen with any particular file format, or all of them?

It occurs with .mp3, which is also the only format I've tried with. So I don't really know about the other formats.

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.

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?

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.

I should probably add that mine is a H120 as well.

The file is here: http://www.rozhlas.cz/leonardo/audio/_audio/00443746.mp3

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.

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 :-)

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

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.

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.

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.

BTW, the file structure that that files I've noticed this with is
/radio
/podcast
/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.

ack sorry, didn't come out right
/radio/podcast/..
../rush
../Narnia Fans
../other

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:
/Podcasts/RadioWest/foo.mp3

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.

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.

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.

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.

UPDATE: I am currently using a build from misticriver.net - 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.

Hi Matt,

Please can you check if this is in the current (standard) build or not? Thanks.

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.

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.

oops. s/"playback corrected resumed"/"playback correctly resumed"