Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bugs
  • Category Music playback
  • Assigned To No-one
  • Operating System Sansa Clip+
  • Severity Low
  • Priority Very Low
  • Reported Version Release 3.13
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by Zian - 2014-10-13
Last edited by saratoga - 2014-11-28

FS#13009 - Sansa Clip+ Seeking Fails When Playback Is Paused

When I try to seek to say, 18:05 in a WMA file that is 22 minutes and 45 seconds long, Rockbox starts playing from somewhere in the early part of the track (say, 00:05) rather than 18:05.

I was able to reproduce the problem with multiple WMA files that were encoded using Expression Encoder with the WMA codec and VBR. A sample file is available at https://onedrive.live.com/redir?resid=87EA02230C32BE40!724&authkey=!AFyvy4opeP7Ib9w&ithint=file%2cwma and if the link is dead, please let me know.

Steps to Reproduce:

1. Add a WMA file to the Clip+.
2. Disconnect the device from the computer by doing a “Safely Remove” or “Eject”.
3. Turn off the device.
4. Turn on the device.
5. Scroll down to “Database” and press the middle button.
6. Scroll to Album and press the middle button.
7. Press the Up button one time.
8. “What The Dog Saw” is probably selected unless you have albums that start with W, X, Y, or Z. If “What The Dog Saw” is not selected, the scroll until it is.
9. Press the middle button.
10. Press the middle button to start playing the first track.
11. Press the Up button to pause playback.
12. Press and hold the Right button to seek to somewhere around 11:00 or later.
13. Release the Right button.

Observe that the timestamp on the left now says something like “0:04” rather than the desired time.

System Details:
- Sansa Clip+
- Rockbox Version 3.13

Closed by  saratoga
2014-11-28 22:09
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

Fixed in aa2c55e.

MikeS commented on 2014-10-13 08:00

It doesn't seem to require being paused. Any seek passed about the 18 to 19 minute mark seems to fail.

saratoga commented on 2014-10-14 16:49

The file has an invalid bitrate listed in the ASF stream (average bitrate is greater than max bitrate), so all the seeking calculations are really inaccurate. I'll see if I can add some sanity checks that try to correct for bad headers like this.

saratoga commented on 2014-10-14 18:33

This fixes two problems for me:

1) It no longer trusts the listed bitrate, instead it computes it from the total number of packets and the packet size. This should be much less likely to fail because a stream with either of those parameters wrong is probably unparsable.
2) The parser read in the number of packets as a 16 bit big endian value at offset 31 in the File Properties Object. Looking at a few files in MS's ASF View tool (which is amazing!), it seems like the true value is at offset 32 in 64 bit little endian format. By chance, reading in the adjacent byte as part big endia just happened to give the right value for most files because the byte was usually 1 anyway.

I'm not 100% sure if #2 is correct. I'm sure the way we do it is wrong because the value is absolutely at least 32 bit (I have files with more than 65k packets). I guess this needs a bit of testing to see if it breaks anything…

Here is a build for the OP on the Clip+:

http://web.mit.edu/mgg6/www/rockbox_asf_clipplus.zip

Would be interested to know if it fixes or breaks anything else.

   asf_parser.patch (4.9 KiB)
MikeS commented on 2014-10-17 04:18

Indeed, I noticed it's quite inaccurate on this file even when successful. I also noticed the seek code ignores return codes from ci→seek_buffer as well, which is bad. Can the warn_unused_result attribute be added on the buffering API pointers as well as the declaration?

saratoga commented on 2014-10-19 20:08

I'm not sure if that is a problem. I think the parser will just error out and abort the seek. Probably this only happens on seeking past the end of truncated files or in this case where the header has incorrect information.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing