User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:35.0) Gecko/20100101 Firefox/35.0 Build ID: 20141001030205 Steps to reproduce: Device: Flame Build ID: 20141001 BG2 Version: 2.0 1) Added approx 10 GB of Music to external microSD Card, placed SD in device. Rebooted 2) Opened Music App, Begins to scan/add music to application Actual results: Randomly freezes scanning/adding on songs. Force close application in order continue scanning. Repeats random freeze Expected results: Should add all music without issue

Please keep that collection aside - it might be needed for testing. Bug 841949 should fix lot of issues in metadata processing which seems to be what you are seeing, but we are very interested to see if you still encounter issues with your collection. Thank you kindly.

This seems like maybe an OOM issue? I'd be interested in seeing a profile for this. (One of these days I need to grab a 32GB SD card and just load it up with music...)

Removing the dependency, since bug 841949 just makes parsing more *correct*, but it doesn't make it perform any better or use any less memory. At least, I didn't intentionally improve any of that. My guess is that load album art is a significant source of jank and crashes.

^ Funny enough, about 90% of the music I uploaded has no art added.

(In reply to Stephen M [ste] from comment #4) > ^ Funny enough, about 90% of the music I uploaded has no art added. What file formats do you use? What fraction of songs fail to get their metadata parsed (you can tell this by how large the "Unknown Album" is)?

I will double check the format the files are. I expect them to all be mp3 or some other lossy format. The fail seemed to be random intervals. For example, I could open the Music app, it would begin to scan and add and pass through about 2-10 albums before getting stuck again. The next time it could only be afew tracks before it stopped scanning.

It like some audio files in the SD card might break the metadata parser, and that's probably caused an infinite loop which drains the battery, I have fixed a similar bug(Bug 1032638), but that was to fix the iso based files, maybe this time is caused by some other formats.

Update. I just tested this using 20141003 on Aurora(2.1) and it does persist but at a lesser extent.

I could reproduce here on master (with no patch) Barely 200 tunes on the phone.

The Music app gets a SIGTERM in my case.

Here is the stack trace Program received signal SIGTERM, Terminated. __futex_syscall3 () at bionic/libc/arch-arm/bionic/futex_arm.S:40 40 mov r7, ip (gdb) where #0 __futex_syscall3 () at bionic/libc/arch-arm/bionic/futex_arm.S:40 #1 0xb6f01020 in __pthread_cond_timedwait_relative (cond=cond@entry=0xb6b04674, mutex=mutex@entry=0xb6bcc240, reltime=0xf0) at bionic/libc/bionic/pthread.c:1117 #2 0xb6f01080 in __pthread_cond_timedwait (cond=0xb6b04674, mutex=0xb6bcc240, abstime=<optimized out>, clock=<optimized out>) at bionic/libc/bionic/pthread.c:1140 #3 0xb6f7dc5c in __wrap_pthread_cond_wait (cond=0xb6b04674, mtx=0xb6bcc240) at ../../../gecko/mozglue/build/Nuwa.cpp:1048 #4 0xb6aa42a4 in PR_WaitCondVar (cvar=0xb6b04670, timeout=4294967295) at ../../../../../gecko/nsprpub/pr/src/pthreads/ptsynch.c:385 #5 0xb4ee24be in Wait (aInterval=4294967295, this=0xb6b04664) at ../../dist/include/mozilla/CondVar.h:79 #6 mozilla::Monitor::Wait (this=0xb6b04660, aInterval=aInterval@entry=4294967295) at ../../dist/include/mozilla/Monitor.h:40 #7 0xb502f9d6 in mozilla::ipc::MessageChannel::WaitForSyncNotify (this=this@entry=0xb6b54448) at ../../../gecko/ipc/glue/MessageChannel.cpp:1439 #8 0xb5034388 in mozilla::ipc::MessageChannel::SendAndWait (this=this@entry=0xb6b54448, aMsg=aMsg@entry=0xaf4c5ba0, aReply=aReply@entry=0xbec2a12c) at ../../../gecko/ipc/glue/MessageChannel.cpp:723 #9 0xb5034b22 in mozilla::ipc::MessageChannel::Send (this=0xb6b54448, aMsg=aMsg@entry=0xaf4c5ba0, aReply=aReply@entry=0xbec2a12c) at ../../../gecko/ipc/glue/MessageChannel.cpp:630 #10 0xb504c5fc in mozilla::dom::PBlobChild::SendWaitForSliceCreation (this=this@entry=0xaf4ff510) at PBlobChild.cpp:170 #11 0xb5673386 in SendSliceConstructor<mozilla::ipc::PBackgroundChild> (aOtherSideParams=..., aParams=..., aManager=<optimized out>) at ../../../gecko/dom/ipc/Blob.cpp:1875 #12 mozilla::dom::BlobChild::RemoteBlobImpl::SliceHelper::RunInternal (this=this@entry=0xb046ba00, aNotify=aNotify@entry=false) at ../../../gecko/dom/ipc/Blob.cpp:1334 #13 0xb567342a in GetSlice (aContentType=..., aLength=65536, aStart=<optimized out>, this=0xb046ba00) at ../../../gecko/dom/ipc/Blob.cpp:1258 #14 mozilla::dom::BlobChild::RemoteBlobImpl::CreateSlice (this=<optimized out>, aStart=<optimized out>, aLength=65536, aContentType=...) at ../../../gecko/dom/ipc/Blob.cpp:1393 #15 0xb576d6ba in mozilla::dom::DOMFileImpl::Slice (this=this@entry=0xb043dc40, aStart=<optimized out>, aEnd=<optimized out>, aEnd@entry=65536, aContentType=..., aArgc=aArgc@entry=2 '\002', aBlobImpl=aBlobImpl@entry=0xbec2a3c8) at ../../../../gecko/content/base/src/nsDOMFile.cpp:493 #16 0xb577252a in mozilla::dom::DOMFile::Slice (this=<optimized out>, aStart=<optimized out>, aEnd=65536, aContentType=..., aArgc=2 '\002', aBlob=0xbec2a578) at ../../../../gecko/content/base/src/nsDOMFile.cpp:409 #17 0xb4ee97a2 in NS_InvokeByIndex (that=<optimized out>, methodIndex=<optimized out>, paramCount=<optimized out>, params=<optimized out>) at ../../../../../../gecko/xpcom/reflect/xptcall/md/unix/xptcinvoke_arm.cpp:164 #18 0xb513e33e in Invoke (this=0xbec2a508) at ../../../../gecko/js/xpconnect/src/XPCWrappedNative.cpp:2395 #19 Call (this=0xbec2a508) at ../../../../gecko/js/xpconnect/src/XPCWrappedNative.cpp:1747 #20 XPCWrappedNative::CallMethod (ccx=..., mode=mode@entry=XPCWrappedNative::CALL_METHOD) at ../../../../gecko/js/xpconnect/src/XPCWrappedNative.cpp:1714 #21 0xb513e7aa in XPC_WN_CallMethod (cx=0xb6b32530, argc=2, vp=0xbec2a6e0) at ../../../../gecko/js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1247 #22 0xb378db78 in ?? () #23 0xb378db78 in ?? () #4 seems to be the common point.

Would you be able to provide a Logcat of what is happening when Music is scanning the database? This would involve deleting the current database (with the shell on the phone) which will erase all the metadata / play count / etc. - which you might want to avoid ; and then using |adb logcat| when the phone is connected to the computer to get the output. This would help us determine if this is the same problem I am seeing here. Thank you kindly.

Basically what I'm seeing it the Music app is killed with a SIGTERM because of an IPC error. I/Gecko ( 207): I/Gecko ( 207): ###!!! [Parent][DispatchAsyncMessage] Error: (msgtype=0x120005,name=PBackground::Msg_PBlobConstructor) Value error: message was deserialized, but contained an illegal value I/Gecko ( 207): I/Gecko ( 207): IPDL protocol error: could not look up PBlob I/Gecko ( 207): IPDL protocol error: Error deserializing 'PBlobParent' I/Gecko ( 207): I/Gecko ( 207): ###!!! [Parent][DispatchAsyncMessage] Error: (msgtype=0x60004,name=PBackgroundIDBDatabase::Msg_PBackgroundIDBDatabaseFileConstructor) Value error: message was deserialized, but contained an illegal value Applying Jim's metadata patches (bug 841949) seems to not cause the problem. Now my question in comment #12 would help determine if that is the problem that the OP is having.

Bug 1075562 is similar but Music app there crashes not freezes, as the app goes away from the screen.

Comment 9: it crashes. But I'm starting to think that we've got two different problems. That mine is caused by bug 994190. While the OP has a different one.

Been offline for awhile. I have no access to the 32GB card at the moment but I can test with 4GB worth of audio files. Has anyone else picked up on this issue since?

I have 16GB of music here (will add more) and haven't had any issue with master. So we need samples that reproduce the problem.

My data was a mix of file formats. I can check what types I used if it helps. I recall that no file had an issue with playback so I'm sure they were all in the supported criteria for fxos

I am afraid another version of this bug is bug 1142876 (all my music files are MP3 at the moment).

It's possible there was a busted file somewhere, which caused similar problems and was fixed in bug 1171202. Can you try with a recent 3.0 build?

I have still this problem with 3.0 nightly (currently build 20150527004616)

(In reply to Matěj Cepl from comment #21) > I have still this problem with 3.0 nightly (currently build 20150527004616) Unfortunately, that's not recent enough. You probably need 20150606xxx or newer, since bug 1171202 just landed.

Is that bug 1191760. We have landed a fix that could be solving the problem.

No response from the original reporter, so resolving this. If you still see the issue, feel free to comment here and we can reopen the bug.