Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bugs
  • Category Music playback
  • Assigned To No-one
  • Operating System SW-codec
  • Severity High
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by Blue_Dude - 2010-05-09
Last edited by Blue_Dude - 2010-05-09

FS#11255 - Resuming wav playback crashes the player

To reproduce:

Play a wav file.
Stop playback.
Turn of the player.
Turn on the player, then select Resume Playback.
Player crashes.

Occurs in r25904, discovered in e200 sim.

Closed by  Blue_Dude
2010-05-09 20:02
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 r25919

Cannot reproduce on Gigabeat S with r25904. Further details for reproducing, please.

The file I used to reproduce the bug can’t be posted here, but here’s the sim console information when selecting Properties on it:

wave header info —-

format: 0001
channels: 2
blockalign: 4
bitspersample: 16
samplesperblock: 1
totalsamples: 6849165
numbytes; 27396660

id3 info —-

frquency: 44100
bitrate: 1411
length: 155309

The typos are in the original by the way (semi colon for colon, “frquency”)

Also perhaps of significance is that there is other metadata in the wav file: artist and title tags.

Confusingly, the “Time” information in the properties screen is incorrect on all files. They’re different on all the wav files, and all the flac files show “2:00”. I don’t know what it’s supposed to represent, but in this file it says “23:40”. The Duration is correct at 2:35.

I made an identical wav file to the problematic one, this time without metadata. It worked.

The only difference between the two files is the one that behaves only contains audio chunks. The one that doesn’t contains a metadata chunk at the end. Other than the metadata chunk they are identical, except for two bytes in the header. Those two bytes are the low end bytes of a four byte integer describing the total chunk size of the wav file.

My guess is that for some reason, the parser is not ignoring the metadata but somehow tries to read it as an audio subchunk. In other words, the parser assumes that if a subchunk exists in the total count, it must be audio. Then it tries to read the metadata subchunk info as an audio subchunk and crashes.

The problem was in the metadata parser. Fixed.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing