Rockbox

This is the bug/patch tracker for Rockbox. Click here for more information.

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

FS#9866 - .ogg file(s) reliably crashes Rockbox on Gigabeat F40

Attached to Project: Rockbox
Opened by MJT (buckw) - Tuesday, 03 February 2009, 00:44 GMT+2
Last edited by MichaelGiacomelli (saratoga) - Wednesday, 01 July 2009, 19:49 GMT+2
Task Type Bugs
Category Music playback
Status Closed
Assigned To No-one
Player Type Gigabeat F/X
Severity Low
Priority Normal
Reported Version Version 3.1
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Private No

Details

I have a Gigabeat F40 running version r19888.090130. I am not using the database feature. On certain .ogg files, the player freezes immediately (zero time elapsed), and must be restarted by switching the battery switch. It is a specific set of files that cause the freeze, and not all .ogg files have the same effect--some play fine. When converted to mp3, the files cause no problem.

I posted this initially in the forum (http://forums.rockbox.org/index.php?topic=20456.0), and was advised to open a bug. I can also send a file if you advise how and where.
This task depends upon

Closed by  MichaelGiacomelli (saratoga)
Wednesday, 01 July 2009, 19:49 GMT+2
Reason for closing:  Fixed
Additional comments about closing:  Should be fixed.
Comment by MichaelGiacomelli (saratoga) - Tuesday, 03 February 2009, 02:47 GMT+2
If possible, attach it to the task you just opened. If not, either upload it to some other hosting or email me a copy.
Comment by MJT (buckw) - Friday, 06 February 2009, 21:11 GMT+2
Have you received the file on RapidShare?
Thanks.
Comment by MJT (buckw) - Monday, 16 February 2009, 01:02 GMT+2
A sample file that causes the problem described can be found at
http://rapidshare.com/files/194475757/01_-_The_Eve_Of_The_War.ogg.

Thanks.
Comment by Magnus Holmgren (learman) - Tuesday, 17 February 2009, 19:05 GMT+2
This happens because:

* The Vorbis comments contain a big album art image. In this case, about 0.5 MB.
* The Vorbis decoder always loads all comments, even though Rockbox doesn't get them from the decoder (thus, memory is wasted; in this case, lots of memory).
* Rockbox has limited amounts of memory for dynamic allocations by the codec.
* The Vorbis decoder doesn't check for memory allocation failure in this case.

So, the quick fix is, dump the album art image. By the way, Vorbis comments are "meant for short, text comments, not arbitrary metadata". I can't say I like the practice of dumping images in them. :)
Comment by MJT (buckw) - Sunday, 01 March 2009, 20:15 GMT+2
Thank you!
Comment by Dave Chapman (linuxstb) - Sunday, 01 March 2009, 23:11 GMT+2
r20156 fixed this by truncating large comments, but the codec shouldn't be parsing/loading the vorbis comments in the first place - all it needs to do is skip them.
Comment by MichaelGiacomelli (saratoga) - Monday, 02 March 2009, 02:05 GMT+2
This patch sets the comments length to zero for all files to avoid wasting memory storing metadata in the codec itself. However, it does advance the file pointer past the comments. Somewhat surprisingly, this doesn't seem to matter for my couple files, but it would be nice if someone with a larger vorbis collection could test it out a bit just to make sure its ok for all files.
   tremor_comments_skip.patch (1.5 KiB) 
 apps/codecs/libtremor/info.c |   25 +------------------------
 1 file changed, 1 insertion(+), 24 deletions(-)

Loading...