896173 - [Music - MMS ] mp3 and amr files received via MMS doesn't show the original filename

Status: VERIFIED FIXED

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

Description

[Leo]

1. Title:  Original file names of mp3/amr music files recieved via MMS are not displayed , while playing 
2. Precondition: Have a couple of mp3 and amr files in the device.
3. Tester's Action: 
- Compose a MMS message , attach mp3/amr files and send 
- Once the MMS message is recieved , try opening the file to play
- Filenames displayed are "Unknown title" while playing
- In message view, the filename is correct.
4. Detailed Symptom (ENG.) :  When user receives a MMS-music file(mp3/amr format) , when playing it shows "unknown title" instead of the filename
5. Expected: Filename should be displayed instead of "Unknown filename"
6. Reproducibility: Y
1) Frequency Rate : 100%
7. Gaia Master/v1-train: Reproduced on v1-train
8. Gaia Revision: 3b2b0e422c3c772424d4b4e861986c81032d1d3f

Comment 1

[Steve Chung [:steveck]]

Currently, the title displayed on music app is parsed from metadata. If the file not exist on musicDB and the metaData doesn't contains file name, it will show "Unknown title" in this case. Open activity already have the filename parameter and utilized in file saving behavior. If we want display title in this case, extra logic forcing the title bar updated with given filename in music app is needed.

Comment 2

[Dominic Kuo [:dkuo]]

Thanks, Steve, I can confirm this.

I think this issue needs some UX inputs because:

1. For mp3, it's common that the file has ID3 tags which contains the "title" we currently displays for the open activity in music app.
2. For amr, the file doesn't contain metadata like title information, so look like it's trivial that we just display the filename instead of "Unknown Title".

But these two strategies seems hard to coexist, I am think that we can probably:

1. Display the "title" from the metadata if it exists. When there is no title, then use filename instead.
2. Display the filename no matter the title exists not not.

Rob, can you please help to give some inputs? thanks.

Comment 3

[Stephany Wilkes]

Also flagging Ayman since this is MMS more than music. Ayman, please feel free to reassign as necessary.

Comment 4

[ayman maat :maat]

(In reply to Dominic Kuo [:dkuo] from comment #2)
> Thanks, Steve, I can confirm this.
> 
> I think this issue needs some UX inputs because:
> 
> 1. For mp3, it's common that the file has ID3 tags which contains the
> "title" we currently displays for the open activity in music app.
> 2. For amr, the file doesn't contain metadata like title information, so
> look like it's trivial that we just display the filename instead of "Unknown
> Title".
> 
> But these two strategies seems hard to coexist, I am think that we can
> probably:
> 
> 1. Display the "title" from the metadata if it exists. When there is no
> title, then use filename instead.
> 2. Display the filename no matter the title exists not not.
> 
> Rob, can you please help to give some inputs? thanks.


Fropm a UX perspective I would go with solution 1: 'Display the "title" from the metadata if it exists. When there is no title, then use filename instead.' 

NeedInfo me if you require more input from me

Comment 5

[Stephany Wilkes]

Removing needinfo? for Rob since Ayman addressed this. Thanks, Ayman!

Comment 6

[Jim Porter (:squib)]

Does this still happen? I feel like we've fixed this already...

Comment 7

[Shally Li（leave from Mozilla）]

Hi Jim,

    I still can reproduce this bug on latest build of Flame v2.0&2.1&2.2&3.0 by the STR in Comment 0.


Actual results: The mp3/amr file received via MMS still shows "Unknown title" while playing.
Please see attachments: verify_v3.0.MP4 and logcat_1640.txt
Reproduce rate: 5/5

-----------------------------------------------------------------------------------
Device: Flame v2.0 build(Affected)
Build ID               20150607160203
Gaia Revision          5552bf529d3d6775a968942e9afa6c1d4037362c
Gaia Date              2015-05-21 14:42:19
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/73c77853d35d
Gecko Version          32.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150607.194510
Firmware Date          Sun Jun  7 19:45:21 EDT 2015
Bootloader             L1TC000118D0

Device: Flame v2.1 build(Affected)
Build ID               20150607001204
Gaia Revision          2304a1f6327c2ccf35d6995ee16f2231ed1f22a3
Gaia Date              2015-05-26 13:30:41
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/ebbace93b522
Gecko Version          34.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150607.035246
Firmware Date          Sun Jun  7 03:52:57 EDT 2015
Bootloader             L1TC000118D0

Device: Flame v2.2 build(Affected)
Build ID               20150607002503
Gaia Revision          8fc797527a3eca7665bc1d1828848f2fb77ca99f
Gaia Date              2015-06-04 07:46:11
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/d213237e11e9
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150607.035848
Firmware Date          Sun Jun  7 03:58:59 EDT 2015
Bootloader             L1TC000118D0

Device: Flame v3.0 build(Affected)
Build ID               20150607160204
Gaia Revision          1d62b32408567f9f7cf1c71c1e5a0c6593be757b
Gaia Date              2015-06-05 17:55:07
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/7d4ab4a9febd
Gecko Version          41.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150607.193246
Firmware Date          Sun Jun  7 19:32:58 EDT 2015
Bootloader             L1TC000118D0

Comment 8

[Shally Li（leave from Mozilla）]

Attachment: logcat_1640.txt

Comment 9

[Shally Li（leave from Mozilla）]

Attachment: verify_v3.0.mp4

Comment 10

[Jim Porter (:squib)]

Ok, then maybe it has something to do with AMR files. I'm not sure we support parsing metadata for those...

Comment 11

[No-Jun Park [:njpark]]

[Tracking Requested - why for this release]:
It's a low priority bug, but we would need to monitor it to fix it when resources are available.

Comment 13

[GitHub Autolander Bot]

Attachment: [gaia] jimporter:music-external-filename > mozilla-b2g:master

Comment 14

[Jim Porter (:squib)]

Comment on attachment 8678347 [details] [review]
[gaia] jimporter:music-external-filename > mozilla-b2g:master

This fixes the issue, and I also cleaned up some indentation. If you want a test, let me know, but this seems like the kind of thing that's unlikely to regress now that we bothered to do something about it.

Comment 15

[Justin D'Arcangelo [:justindarc]]

Comment on attachment 8678347 [details] [review]
[gaia] jimporter:music-external-filename > mozilla-b2g:master

LGTM

Comment 16

[Jim Porter (:squib)]

Landed: https://github.com/mozilla-b2g/gaia/commit/a129e5fb047d99f1810827cbf8bd09b95011bf57

Comment 17

[zouyi(Leave from Mozilla)]

Attachment: Aries KK v2.5.3gp.3gp

This bug has been verified as "pass" on the latest build of Flame KK 2.5 and Aries KK 2.5 by the STR in comment 0.

Actual results: Tap mp3 and amr files which are added as attachments of MMS, and play via the music app. Filename is displayed correctly at the header of now-playing view.

See attachment: Aries KK v2.5.3gp.
Reproduce rate: 0/10.

Device: Aries KK 2.5(pass)
Build ID               20151030012032
Gaia Revision          91cac94948094cfdcd00cba5c6483e27e80cb3b0
Gaia Date              2015-10-28 20:32:15
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/6d1e12f5725b56453e368b960e873261e0d48b5a
Gecko Version          45.0a1
Device Name            aries
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.worker.20151030.003706
Firmware Date          Fri Oct 30 00:37:14 UTC 2015
Bootloader             s1

Device: Flame KK 2.5(pass)
Build ID               20151029150245
Gaia Revision          91cac94948094cfdcd00cba5c6483e27e80cb3b0
Gaia Date              2015-10-28 20:32:15
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/1fbc958f75576446a57cf93406db87b51b12911d
Gecko Version          45.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20151029.182818
Firmware Date          Thu Oct 29 18:28:30 EDT 2015
Firmware Version       v18D v4
Bootloader             L1TC000118D0