• Status Closed
  • Percent Complete
  • Task Type Bugs
  • Category Music playback
  • Assigned To No-one
  • Operating System Gigabeat S
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by Llorean - 2009-04-18
Last edited by Buschel - 2009-04-20

FS#10139 - Broken seeking in very long audio files.

I've tested this on Gigabeat S, though it seems reasonable that it's a swplayback / buffering issue.

Tested in r20728.

File length is ~21hrs long (audiobook). I have a bookmark 17.5 hours into the file. If I resume the bookmark all is well. If I seek, for example, one second from where I am, I get audio completely unrelated to where I am. If I stop and then resume playback, it resumes that unrelated audio, but the progress bar is now showing that I'm playing from 5.5 hours into the file (which is approximately correct judging from the part of the book I'm now hearing).

Closed by  Buschel
2009-04-20 19:11
Reason for closing:  Fixed
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

Fxied with r20755

Can you give some more details about the file (format, samplingrate, bitrate, VBR/CBR, filesize)? The seek is implement different for each codec, so there are main differences in the handling. From what you describe I expect some int-overflow as the amount of samples (assuming 44.1kHz is used) or bits (assuming 128kbit/s is used) exceeds uint32.

44.1khz 144 Kbps avg VBR MP3 with a filesize in the 1.3 GB range.

i cannot code from this PC, but please try the following: In file "/apps/codecs/mpa.c" in function "get_file_pos(int newtime)" please change lines

percent = (newtime*100) / id3→length;
remainder = (newtime*100) % id3→length;

to (e.g. this is used for mp3 cbr files in within the same function)

percent = ( (newtime/1000) *100) / (id3→length/1000);
remainder = ( (newtime/1000) *100) % (id3→length/1000);

or to (convert newtime to int64, convert result back to uint32)

percent = (unsigned int) ( ( (int64_t)(newtime)*100) / id3→length);
remainder = (unsigned int)(((int64_t)(newtime)*100) % id3→length);

As far as I can see newtime is sent in milliseconds. Your 17.5h lead to 17.5*3600*1000 ms which are then multiplied with 100. This overflows the uint32-variable "percent". The modulo part is 5.5h long…So, theory seems to match the bug.

I used (newtime)%(id3→length / 100) and it seems to work fine.

A cleaner and better readable solution. Can you please test?

Edit: v01 was faulty, please use v02.


Available keyboard shortcuts


Task Details

Task Editing