1095190 - "Ringtone not created" error when trying to set a Ringtone from a Music track

Status: RESOLVED FIXED

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

Description

[Marcia Knous [:marcia]]

Attachment: ringtones.txt

Flame, while running:

Gaia   068b9711277b06c7d633517f9e1fcb5624bb39b3
SourceStamp a074c0112919
BuildID 20141106040207
Version 36.0a1
v 188

STR:
1. Open the Music app and select a ringtone.
2. Set the ringtone as the default
3. Go back and select a different track
4. Received the attached error

Logcat attached.

Comment 1

[Marcia Knous [:marcia]]

Attachment: Screenshot of error on Master

Comment 2

[Sue]

Attachment: logcat_1537.txt

This issue could be repro on lasted build of Flame 2.2
STR:
1. Launch Music app.
2. Select a music to play.
3. Tap share button -> Ringtones.
4. Tap Save button.
**It will remind "Ringtone Not Created".
Found time:15:37
See attachment: logcat_1537.txt

Flame 2.2 build:
Gaia-Rev        3554ea9504046646b4679e3a61317c49fc55ca87
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/67c42c076393
Build-ID        20141228010205
Version         37.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141228.045435
FW-Date         Sun Dec 28 04:54:46 EST 2014
Bootloader      L1TC00011880

Comment 3

[Jim Porter (:squib)]

You're hitting a quote in indexedDB:

12-29 15:37:39.143 W/Ringtones( 6899): [JavaScript Error: "QuotaExceededError" {file: "app://ringtones.gaiamobile.org/gaia_build_defer_share.js" line: 323}]

Probably fallout from bug 1083927, based on the dates.

Comment 4

[Jim Porter (:squib)]

(In reply to Jim Porter (:squib) from comment #3)
> You're hitting a quote in indexedDB:

Oops, I mean "quota".

Comment 5

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Do all the apps involved have the correct storage permissions already? If not then we should add them.

Otherwise, maybe Jan has an idea?

Comment 6

[Jim Porter (:squib)]

Here are the permissions for the ringtones app, which should be the only relevant app in this situation: https://github.com/mozilla-b2g/gaia/blob/master/apps/ringtones/manifest.webapp#L11-L17

Were new permissions added for storing large blobs in IndexedDB? Or should we migrate away from storing them in there?

Comment 7

[Ben Turner (not reading bugmail, use the needinfo flag!)]

I think the ringtone app probably needs the "storage" permission also. Try it at least.

Fabrice, thoughts?

Comment 8

[[:fabrice] Fabrice Desré]

(In reply to ben turner [:bent] (use the needinfo? flag!) from comment #7)
> I think the ringtone app probably needs the "storage" permission also. Try
> it at least.
> 
> Fabrice, thoughts?

Yes, it should ask "storage" to get unlimited indexedDB storage (since we don't implement prompting).

Comment 9

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Thanks fabrice.

Jim, I think adding the 'storage' permission to your manifest will fix the issue.

Comment 10

[Jan Varga [:janv]]

Right, add the permission.

Comment 11

[Jim Porter (:squib)]

Attachment: Fix it

This fixes things.

Comment 12

[Hubert Figuiere [:hub]]

Comment on attachment 8546146 [details] [review]
Fix it

r=me

Comment 13

[Jim Porter (:squib)]

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

Comment 14

[Sue]

Attachment: verify_video.MP4

This issue has been verified successfully on Flame 2.2
STR:
1. Launch Music app.
2. Select a music to play.
3. Tap share button -> Ringtones.
4. Tap Save button.
**Music can be save as Ringtones.

Flame 2.2 build:
Gaia-Rev        f5e481d4caf9ffa561720a6fc9cf521a28bd8439
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/bb8d6034f5f2
Build-ID        20150111010223
Version         37.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150111.043244
FW-Date         Sun Jan 11 04:32:55 EST 2015
Bootloader      L1TC000118D0

Comment 15

[Sue]

Attachment: logcat_1806.txt

I have verified it again after restarting device, and I found the verification failed on Flame 2.2. I don't know the reason why it is verified successfully in the first time.
Found time: 18:06
See attachment:logcat_1806.txt and 1806.MP4

STR:
1. Launch Music app.
2. Select a music to play.
3. Tap share button -> Ringtones.
4. Tap Save button.
**It will remind "Ringtone Not Created".

Flame 2.2 build:
Gaia-Rev        f5e481d4caf9ffa561720a6fc9cf521a28bd8439
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/bb8d6034f5f2
Build-ID        20150111010223
Version         37.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150111.043244
FW-Date         Sun Jan 11 04:32:55 EST 2015
Bootloader      L1TC000118D0

Comment 16

[Jim Porter (:squib)]

It's still a quota issue. Make sure you've flashed a completely fresh build; this includes wiping your old profile. If you don't do that, it won't work.

Comment 17

[Sue]

1. After flash build, launch Music app and set a music as ringtones successfully.
2. Restart device, and verified it again, it will remind "Ringtone Not Created".

Comment 18

[Jim Porter (:squib)]

I'm unable to reproduce this issue after the fix landed. Could QA take a look and see if they can reproduce?

Comment 19

[Yeojin Chung [:YeojinC]]

I was able to reproduce this issue on an earlier build (BuildID: 2015011201022) on Flame 2.2. However, after trying about 20 times, I was unable to reproduce the issue on Flame Master and 2.2.

Result: Ringtones are created as default without any error messages.
 
Device: Flame Master
Build ID: 20150224010314
Gaia: 31ac1cd7a029d5e46dd7c92537b5c973c5d9826e
Gecko: 368c62292249
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 39.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0

Device: Flame 2.2 (KK, 319mb, full flash)
Build ID: 20150224002637
Gaia: 8e98fe665f3821d10d4d982cbb14cbe5b94d0be5
Gecko: 2b70d9d62799
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 37.0 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Comment 20

[Jim Porter (:squib)]

From comment 19, it sounds like this is indeed fixed. Closing.