Closed Bug 796082 Opened 12 years ago Closed 12 years ago

[Music] Music player crashes when scrolling mix screen

Categories

(Firefox OS Graveyard :: Gaia, defect, P1)

x86
Gonk (Firefox OS)

Tracking

(blocking-basecamp:+)

VERIFIED FIXED
blocking-basecamp +

People

(Reporter: marcia, Assigned: dkuo)

References

Details

(Keywords: crash, reproducible)

Attachments

(1 file)

Seen while running the 20121001 build:

b2g revision= ca1f327d5acc198bb4be62fa51db2c039032c9ce
gaia=b2g = 5feb07b511ab907942731fc4961ccbce3958d021
releases-mozilla-central = 80b40bba7f30f6cea5cb148cbbdcbf008691972b
gonk-misc = 202d2c62443c098b125e5d9d7b42226d98230e44

STR:
1. Launch the music player app.
2. Scroll the mix list vertically until the page ends.
3. App crashes

Expected: No crash
Component: Gaia → General
Blocks: 796154
Marcia: I assume this is on the otoro, right?  Can you also reproduce it on the desktop?

How much music do you have on your device? Is it just the standard samples, or do you have a personal collection on the device?

(I'm wondering whether this is a generally reproducible bug or something specific about the music files on your phone...)
Marcia: Same as David said, can you provide us some sample files that you were using? and more detail about your test files? thanks.
Yes, this is on the Otoro device. In addition to the samples, I installed a 32 GB card and loaded up some other music. I have two phones set up with music, so I will try to see if the issue is reproducible on the other phone as well.

BTW, this seems to have started happening with the build the other day where it looks as if my "Mix" page changed.
This seems like a blocker to me.
blocking-basecamp: ? → +
So I have music loaded on two different devices. The one device that has more music is the one that crashes consistently. I did load some songs with unicode on both of the devices. I might also have some podcasts on the one crashing. I will try to narrow it down. I believe David is correct in that it may be something related to content on have on that particular device.
So I hit another bug while trying to narrow down which content might be causing it. When I delete content from my SD card while connected via USB, the 5 tracks I deleted are still showing up in my playlist on the phone (but not on the SD card). I reached out to dougt and I am supposed to get him my zipped up file for him to look at.
Doug Turner has a copy of my SD card so he is looking into what might be causing this crash.
This seems like a OOM for me. Can you try to check watch -n 1 'adb shell procrank | egrep "(RAM|b2g)"' and see if the device runs out of memory and if the 'Music' application process is crashed?
so, what is happening is this:

1) the music player enumerates all files on the sdcard
2) for music files, it extracts (slice()) image data
3) the image data is then assigned to a image element
4) we do not discard the compressed or decompressed image data


if your media collection is large enough (the data set that I have, just the image data in for thumbnails is ~20MB compressed), you will OOM.


There are bugs on file to make this problem less significant, but the simplest fix is for gaia to resize the thumbnails and store those in their media database.
Dominic,

Doug has investigated this and determined that the problem is in the clever way I handle album art in the metadata parser. Instead of extracting the image and storing it in mediadb, I just extract the offset and length of the image, and then use blob.slice() to extract the image when it is needed. 

The problem apparently is that many albums have very large album art embedded, and gecko isn't very smart about deallocating decoded images.  So we need to change this so that the metadata parser returns a resized image blob and stores it directly into mediadb.

Since the bug affects your app and my metadata parser, I'd like you to choose who should fix it. If you'd like to fix this, please assign it to yourself, and feel free to ask me for review.  Otherwise, assign it to me, and I'll fix it, with your review.
Flags: needinfo?(dkuo)
David,

I'd like to take this one, assigning to myself. I will ping you if I need some help, thanks.
Flags: needinfo?(dkuo)
Assignee: nobody → dkuo
Priority: -- → P1
Attachment #673822 - Flags: review?(dflanagan)
Comment on attachment 673822 [details]
Store cached album image to metadata

r=djf, if you address the nits in my github comments.
Attachment #673822 - Flags: review?(dflanagan) → review+
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Component: General → Gaia
Reviewed and verified 
on build: 2012123107020
"Unagi" device "Gonk" OS
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: