Closed
Bug 961953
Opened 11 years ago
Closed 11 years ago
[Sora][Music player][MMS]the name of saved audio file is wrong when open in music player
Categories
(Firefox OS Graveyard :: Gaia::SMS, defect, P1)
Firefox OS Graveyard
Gaia::SMS
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: sync-1, Unassigned)
Details
Attachments
(2 files)
Mozilla build ID: 20140105004001
DEFECT DESCRIPTION:
The audio file title display 'unknown title'
REPRODUCING PROCEDURES:
1.Recived one mms that attachment is audio files;
2.Open this MMS;
3.Press this attachment,it switch to music player screen.
EXPECTED BEHAVIOUR:
The audio file title should be name of this recording file.
ASSOCIATE SPECIFICATION:
TEST PLAN REFERENCE:
TOOLS AND PLATFORMS USED:
USER IMPACT:
REPRODUCING RATE:5/5
For FT PR, Please list reference mobile's behavior:
tel:13061903616
Comment 1•11 years ago
|
||
qawanted: can you please test the behavior on v1.1, v1.2, v1.3, v1.4 ?
Thanks!
Keywords: qawanted
Comment 2•11 years ago
|
||
(In reply to Julien Wajsberg [:julienw] from comment #1)
> qawanted: can you please test the behavior on v1.1, v1.2, v1.3, v1.4 ?
>
> Thanks!
This needs to be requested to the partner, not Mozilla QA. See https://wiki.mozilla.org/B2G/Triage#Blocker_Nomination_Notes.
Keywords: qawanted
Comment 3•11 years ago
|
||
Jason, I especially wanted to know if the issue happened on our builds.
Comment 4•11 years ago
|
||
(In reply to Julien Wajsberg [:julienw] from comment #3)
> Jason, I especially wanted to know if the issue happened on our builds.
Mozilla QA will not commit to this process - we do not want to be in business of checking every single partner bug against our gecko & gaia.
Comment 5•11 years ago
|
||
If the received message was sent from other non-firefox OS devices, there are some possible root cause in this issue:
1) Message sender didn't wrap the music attachment correctly. Receiver might also got wrong file name in other OS. It should be very easy to verify and there is no way to handle it since it's sender's bug.
2) Message sender wrap the message into attachment/SMIL with other unexpected structure. Message app in other OS might be able to handle this case correctly, we can add this edge case in our SMIL/attachment parsing for sure, but we need to know how the sender app wrap their mms SMIL. We will need some debug log to know the SMIL result.
We need more info from bug reporter about:
1) The message is sent from FFOS device or not. If not, we need to know if same file sent from FFOS will work correctly, and the same sender app/file sent to other OS will work or not.
2-a) If attachment is sent from FFOS, please verify if other music file will be failed as well.
2-b) If attachment is sent from other OS and same attachment sent to other OS devices will work correctly, please needinfo us and we can provide some way to dump he debug log we need.
Flags: needinfo?(sync-1)
(In reply to Steve Chung [:steveck] from comment #5)
> If the received message was sent from other non-firefox OS devices, there
> are some possible root cause in this issue:
>
> 1) Message sender didn't wrap the music attachment correctly. Receiver might
> also got wrong file name in other OS. It should be very easy to verify and
> there is no way to handle it since it's sender's bug.
>
> 2) Message sender wrap the message into attachment/SMIL with other
> unexpected structure. Message app in other OS might be able to handle this
> case correctly, we can add this edge case in our SMIL/attachment parsing for
> sure, but we need to know how the sender app wrap their mms SMIL. We will
> need some debug log to know the SMIL result.
>
> We need more info from bug reporter about:
> 1) The message is sent from FFOS device or not. If not, we need to know if
> same file sent from FFOS will work correctly, and the same sender app/file
> sent to other OS will work or not.
>
> 2-a) If attachment is sent from FFOS, please verify if other music file will
> be failed as well.
>
> 2-b) If attachment is sent from other OS and same attachment sent to other
> OS devices will work correctly, please needinfo us and we can provide some
> way to dump he debug log we need.
Dear Steve Chung,
Yes, I use an Android phone to send veido message to a FFOS phone, which lead this bug. This same video can't work correctly on android os either.
BRs,
TIAN Min
Per https://bugzilla.mozilla.org/show_bug.cgi?id=961953#c6, it works fine when sending MMS between FFOS mobile phone. Hence it is a Android system problem. update the status to RESOLVED
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
Send a audio file to myself on ffos v1.3, then received the same audio file. Its name can't be get when I tap the audio file and listen to it. Although is display its name well outside when I didn't tap it as like I received a right named audio file.
Comment 10•11 years ago
|
||
Is it another issue ?
Comment 11•11 years ago
|
||
(In reply to Julien Wajsberg [:julienw] from comment #10)
> Is it another issue ?
No. I just want to prove audio file's name can't be got sometimes even from ffos phone to ffos phone.
Comment 12•11 years ago
|
||
If you can help us, we'll need something better than "sometimes", I mean a reliable STR, to fix it.
Thanks!
Comment 13•11 years ago
|
||
(In reply to Julien Wajsberg [:julienw] from comment #10)
> Is it another issue ?
Sounds like another issue. Please create another bug for this issue with some detailed information that might help us to figure out the possible root cause more quickly: Is this reproducible for all type of attachments or only on some specific files?
And reliable STR would help most for sure.
Flags: needinfo?(sync-1) → needinfo?(buri.blff)
Comment 14•11 years ago
|
||
Please use this audio file to send a message to yourself on ffos v1.3, you will reproduce this problem.
You need to log in
before you can comment on or make changes to this bug.
Description
•