- Status Closed
- Percent Complete
- 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
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
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.
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
It doesn't seem to require being paused. Any seek passed about the 18 to 19 minute mark seems to fail.
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.
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.
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?
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.