862140 - [Buri][Music Player] an audio file (wma file) with wrong extension (set to mp3) causes device to become painfully slow . This also happens for large number of MP3 files.

Status: RESOLVED WORKSFORME

(Firefox OS Graveyard :: Gaia::Music, defect, P2)

Description

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

DEFECT DESCRIPTION:
 (1)Insert one SD card with about >500 music files ( There must be 100 *.wma file renamed into *.mp3). This bug may not appear for small number of music files. You need to rename as many as 100 wma file into mp3 file. 
 (2)Go to Music, it start scanning. You will see it is parsing wma renamed into mp3 files successfully.
 (3)The scanning will be blocked at some song, never going on (It can be wma file or Mp3 file) . Now you need to kill music player .--- NOK1
 (4)try to launch the Music player again, it will start scanning again, but it will stopped at some other wma file or mp3 file.  ...same NOKs appear again.
 

 
 REPRODUCING PROCEDURES:
 
 EXPECTED BEHAVIOUR:
 
 ASSOCIATE SPECIFICATION:
 
 TEST PLAN REFERENCE:
 
 TOOLS AND PLATFORMS USED:
 
 USER IMPACT:
 Serious, the music player nearly useless, if user want to listen to some music in this case, the phone will totally slow for other functions.
 
 REPRODUCING RATE:
 100%(with the dedicated SD card)

Comment 1

[Alex Keybl [:akeybl]]

Tapas - what's the minimum number of renamed files that causes this issue? Unless it's a handful, this wouldn't be a blocker.

Comment 2

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

If I use 20 renamed files then I see it only once (Rebooting or killing music app does not produce same error in next launch). If I use 100 renamed files then i can produce it always.

The problem is that it can parse some renamed files and it stuck randomly on some renamed file after that. This problem has some kind of randomness. It can be reproduced with large number of renamed file always.

Comment 3

[Mike Lee [:mlee]]

Hema, this appears to be an issue with incorrect file types leading to some expensive processing. Is a fix for this targeted in any upcoming release?

Comment 4

[Hema Koka [:hema]]

We are working on a new version of the music player currently targeted for 1.4. Marking this with a flag so we ensure this is addressed.

Comment 5

[Geo Mealer [:geo] -- This account is inactive after 2015-07-07]

Is this still an issue now?

Comment 6

[Hema Koka [:hema]]

this is part of music2 bug backlog (some other priorities trumped work on next version of music app so far, but it is currently in the plan for 2.1/2.2)

Comment 7

[Hubert Figuiere [:hub]]

This sound like it failures in the metadata parsing. We should be able to actually deal with that and just skip the file. Something like that.

I'll see if I can create a test sample as I have no WMA files.

Comment 8

[Hubert Figuiere [:hub]]

the samples I have make Gecko crash.

We should fix this.

Comment 9

[Hubert Figuiere [:hub]]

Not that was large number of actual MP3 (or a mix of MP3, MP4 and OGG) I didn't see any performance problems.

Comment 10

[Hubert Figuiere [:hub]]

The only problem I see is that we actually wrongfully import the WMA file believing they are MP3.

Tested on master.

Feel free to reopen if you have a better test case to reproduce.