Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bugs
  • Category Music playback
  • Assigned To No-one
  • Operating System
  • Severity High
  • Priority Medium
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by Anonymous Submitter - 2003-01-27
Last edited by zagor - 2003-04-15

FS#832 - playback 'skips'

In build 20030121.ajz [recorder], I have experienced
some strange skips while the player is subject to
moderate motion [moving car]. No problem whatsoever
if the player is stationary. I have reproduced this with
two different hard-disks. Version 1.4 does not show the
problem.

The problem: while playing back hour long radio
recordings, somewhat infrequently [once every 5-10
minutes or so], I get a half-second or so snip of
something that played a few minutes before, along with
a skip in the time-line of more than a half-second. If I
rewind and replay, no problem. One of the disks [an
ibm] ran the ibm diagnositc [long version] with no errors
[no test available for the other drive].

Just a guess, it looks like something very different is
being done on a re-read than with version 1.4.

Model jbr20101, fw version 2.8, build 20030121.ajz

clayschn@fast.net

Closed by  zagor
2003-04-15 22:42
Reason for closing:  Fixed
Project Manager
zagor commented on 2003-01-28 13:16

Try a later build. I never get that.

Anonymous Submitter commented on 2003-01-28 16:19

Have not been able to reproduce it with later build [0127], but
bugs that nobody can point to the fix tend to still be there…
[and come back when least expected].

Project Manager
zagor commented on 2003-02-06 00:24

Found this additional info from Clay on the funmp3 forum:

I believe I saw the same problem [still] in build 20030121
[recorder] on a 48kBit/s, 22,050Hz, Stereo file.

Project Manager
linusnielsen commented on 2003-03-27 20:30

This should be fixed now. Can you confirm that?

Project Manager
bagder commented on 2003-04-15 07:27

Lack of feedback. Assumed fixed.

mikeholden commented on 2003-04-15 08:18

Could this be due to the bug I raised in the mailing list a bit ago, where
the fileposition and cacheoffset values are not updated readwrite()
when we get a disk read error returned, but we successfully read
headbytes? It sound like the same problem.

We need to set
file→fileoffset += nread
and
file→cacheoffset = -1
before early returning.

Not setting these could result in the same headbytes being read on the
next read, thus repeating up to 1 sector’s worth (512 bytes) of playback.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing