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

Attached to Project: Rockbox
Opened by Zian Choy (Zian) - Monday, 13 October 2014, 04:47 GMT
Last edited by MichaelGiacomelli (saratoga) - Friday, 28 November 2014, 22:09 GMT
Task Type Bugs
Category Music playback
Status Closed
Assigned To No-one
Operating System Sansa Clip+
Severity Low
Priority Normal
Reported Version Release 3.13
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


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!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
This task depends upon

Closed by  MichaelGiacomelli (saratoga)
Friday, 28 November 2014, 22:09 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed in aa2c55e.
Comment by Michael Sevakis (MikeS) - Monday, 13 October 2014, 08:00 GMT
It doesn't seem to require being paused. Any seek passed about the 18 to 19 minute mark seems to fail.
Comment by MichaelGiacomelli (saratoga) - Tuesday, 14 October 2014, 16:49 GMT
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.
Comment by MichaelGiacomelli (saratoga) - Tuesday, 14 October 2014, 18:33 GMT
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+:

Would be interested to know if it fixes or breaks anything else.
Comment by Michael Sevakis (MikeS) - Friday, 17 October 2014, 04:18 GMT
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?
Comment by MichaelGiacomelli (saratoga) - Sunday, 19 October 2014, 20:08 GMT
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.