1072642 - [Music][OTA 2.2 -> 2.2] Song rating is not maintained after OTA update.

Status: RESOLVED WORKSFORME

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

Description

[Martin Shuman [:Marty]]

Description:
When updating the phone to a new build, the user will expect their song ratings to be maintained across the update.

Repro Steps:
1) Update a Flame device to BuildID: 20140923073003 (2.2)
2) Add/download a song to the device.
3) Open the Music app and rate the song.
4) Run the OTA update.
  
Actual:
Song is not rated after the OTA update.
  
Expected: 
Song maintains the proper rating after the OTA update.
  
Environmental Variables:
Device: Flame 2.2 Master 319MB
BuildID: 20140924040205
Gaia: ff6dbb006e4e60edba697639aa2a2a199b07069b
Gecko: 1e2993c99323
Version: 35.0a1 (2.2 Master)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0
  
Repro frequency: 2/2
Link to failed test case: https://moztrap.mozilla.org/manage/case/14040/

Comment 1

[Peter Bylenga [:PBylenga]]

[Blocking Requested - why for this release]:
Data loss regression of a core feature of the phone.  This will break user's sort ability by rating in music app.

I can confirm this issue does not occur on 2.1.  I updated to today's 2.1 from yesterday's and my song ratings are maintained.


QAWanted to see if this issue occurs from the first 2.2 Master KK nightly build we have OTA'ing to today's build.  Window might be too cumbersome for this one.

Comment 2

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

This issue occurs when updating from the earliest Flame KK Nightly build to the most recent.

Environmental Variables:
Device: Flame 2.2
BuildID: 20140923160207
Gaia: ff6dbb006e4e60edba697639aa2a2a199b07069b
Gecko: 30920bcb070a
Version: 35.0a1 (2.2) 
Firmware Version: 
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Comment 3

[Peter Bylenga [:PBylenga]]

Not going to block smoke on this issue.

Comment 4

[Jim Porter (:squib)]

I'm going to guess that what's happening here is that something has gone awry with the last-modified times for the files, and we're detecting them as *new* files instead of existing ones. I believe Dominic looked at a similar issue in the past.

Comment 5

[Hema Koka [:hema]]

Blocking, Agree with reasoning in comment 1

Comment 6

[Hubert Figuiere [:hub]]

(In reply to Jim Porter (:squib) from comment #4)
> I'm going to guess that what's happening here is that something has gone
> awry with the last-modified times for the files, and we're detecting them as
> *new* files instead of existing ones. I believe Dominic looked at a similar
> issue in the past.

If the file have the same name and seem to represent the same song, should we really consider them as new?

Comment 7

[Jim Porter (:squib)]

If the timestamp changes, we need to reparse the file to see if the metadata has changed. While it might make sense to keep the rating/playback count if the metadata *hasn't* changed, the fact that the timestamp is changing at all is a bug.

Comment 8

[Dominic Kuo [:dkuo]]

Hope it's not the timestamp issue again and let me investigate this first.

Comment 9

[Hema Koka [:hema]]

Dominic,

Did you get a chance to investigate this issue?

Thanks
Hema

Comment 10

[Dominic Kuo [:dkuo]]

(In reply to Hema Koka [:hema] from comment #9)
> Dominic,
> 
> Did you get a chance to investigate this issue?
> 
> Thanks
> Hema

Not yet but I should be able to take a look tomorrow, before looking into it just want to clarify that, 2.2 is not branched and are we testing master before branching?

Comment 11

[Jim Porter (:squib)]

So, I've been thinking about this. Maybe it would make more sense for the rating and playcount to be in a separate DB from the music, and to have the key for this DB be "Artist - Album - Year - Title"*. That would prevent this from ever being an issue again, and would also mean that you could preserve playback stats even if you did things like swapping SD cards (which I believe would currently wipe out the stats).

* Feel free to argue about the fields we should have. We don't grab the year yet, but it'd be nice, since there are occasionally multiple albums by a given artist with the same name (e.g. Killing Joke has two self-titled albums).

Comment 12

[Hubert Figuiere [:hub]]

Track # and disc # are important too as you can have a track with the same name twice on the disc(s).

Comment 13

[Oliver Nelson [:oliverthor]]

Observed this issue on the newest base image: v18D
OTA from: 20141219040202
OTA to: 20141229010215

Environmental Variables:
----------------------------------------------
Device: Flame KK
BuildID: 20141229010215
Gaia: bdedbaf9f18a43c091ede770407d68d38582fe29
Gecko: 8850aa0f5332
Gonk: a814b2e2dfdda7140cb3a357617dc4fbb1435e76
Version: 37.0a1 (KK)
Firmware: V18D
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
----------------------------------------------
Repro Rate: 5/5

Comment 14

[Oliver Nelson [:oliverthor]]

Actual Results for comment 13:
Song is not rated after the OTA update.

Comment 15

[Hema Koka [:hema]]

Dominic: any update on this?

Comment 17

[Dominic Kuo [:dkuo]]

Sorry I totally forgot this! but I do remember I was able to reproduce this, and will need further investigation, I will update here after I found the root cause.

Comment 18

[Hema Koka [:hema]]

Where are you with this bug?

Thanks
Hema

Comment 19

[Dominic Kuo [:dkuo]]

Hey Hema, I tried to manually enable the OTA but couldn't success on recent builds, will try again and probably ask QA if I failed again, sorry about it.

Comment 20

[Kai-Chih Hu [:khu]]

Can we update the target milestone? Thanks.

Comment 21

[Dominic Kuo [:dkuo]]

I am setting the target milestone to March 20th because I always got b2g crashed while debugging this issue, which makes me unable to log and uncertain to fix it.

Comment 22

[Dominic Kuo [:dkuo]]

Attachment: Screenshot_after_OTA.png

Comment 23

[Dominic Kuo [:dkuo]]

Marty, attachment 8572557 [details] is what I got after I OTA from 2.1 to 2.2, I found the song ratings are still kept but the thumbnails seems disappear, would you please reproduce with the recent builds and see if you get the same result? thanks.

(And if it's about the ratings, I guess it might be bug 1134229 which is recently fixed, maybe you can try with the latest build as well)

Comment 24

[Martin Shuman [:Marty]]

This issue still occurs on the latest 2.2 and 3.0 builds.
Performing an OTA from 2.2 > 2.2 or 3.0 > 3.0 results in approximately 1/5 song ratings being lost.

Environmental Variables:
Device: Flame 3.0 (319MB)(Full Flash)
Build ID: 20150306010207
Gaia: 7a91c16bfa348be8b25e09719178efa051512988
Gecko: 0189941a3fd5
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

Environmental Variables:
Device: Flame 2.2 (319MB)(Full Flash)
Build ID: 20150305002528
Gaia: 89af288bad6751248ff84504fa898206fee127fe
Gecko: 6d8d294aa8f3
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 25

[Kai-Chih Hu [:khu]]

Any update?

Comment 26

[Dominic Kuo [:dkuo]]

(In reply to Kevin Hu [:khu] from comment #25)
> Any update?

I still got the same result in comment 23(OTA from 2.1 to 2.2) and I think we didn't upgrade the thumbnail's cache after OTA.

Jim, I remember now we are using asyncStorage to store the thumbnails and I guess we didn't perform the upgrade for thumbnails, right? or maybe you get a chance to reproduce this and see if you have a same result with me, thanks!

Comment 27

[Jim Porter (:squib)]

(In reply to Dominic Kuo [:dkuo] from comment #26)
> (In reply to Kevin Hu [:khu] from comment #25)
> > Any update?
> 
> I still got the same result in comment 23(OTA from 2.1 to 2.2) and I think
> we didn't upgrade the thumbnail's cache after OTA.

I don't think we need to upgrade the thumbnail cache. It should be in the same format. Even if it weren't, all that would happen is that we'd have stale entries in asyncStorage.

Comment 28

[Dominic Kuo [:dkuo]]

(In reply to Jim Porter (:squib) from comment #27)
> I don't think we need to upgrade the thumbnail cache. It should be in the
> same format. Even if it weren't, all that would happen is that we'd have
> stale entries in asyncStorage.

Thanks Jim, if it's not about the thumbnail cache, then I think I need to go to QA directly and see what's the actual result, the root cause should be some other reason.

Comment 29

[Dominic Kuo [:dkuo]]

Update:

I went to QA team and ask for help(Thanks Mike!), then followed the instruction of OTA, that's, change the Update channel in Developer menu from |default| to |nightly-b2g37|, but after OTA, I still cannot reproduce this bug(good news is I don't see the result in comment 23 any more), also I found Gerry commented in bug 1116069 comment 2, he couldn't reproduce it as well.

I am going to test it with Mike or Gerry tomorrow, see if this issue does exists or not.

Comment 30

[Mike Lien[:mlien]]

Verify with v2.2 OTA, I try two scenarios 1) 50 songs from my own 2) OTA settings from comment 0's case prerequisite
Both cases keep every song's rating after OTA

STR:
1) Full flash 20150403162503 build
2) ADB push music to device
3) Open the Music app and rate the song
4) Run the OTA update to 20150406162505 build
5) Verify rating in Music app

Comment 31

[Dominic Kuo [:dkuo]]

Looks like both Dev and QA cannot reproduce this anymore, so closing it as WORKSFORME.

Comment 32

[Martin Shuman [:Marty]]

I ran 6 separate OTAs on Master, with a total of 38 rated rated. 8/38 of these songs lost their rating in the OTA process.


OTA From:
Device: Flame 3.0 (319MB)(Full Flash)
Build ID: 20150406010204
Gaia: ef61ebbe5de8c2c9fc2a8f74a12455044c3b82e9
Gecko: 4fe763cbe196
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 40.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0

OTA To:
Environmental Variables:
Device: Flame 3.0 (319MB)(Full Flash)
Build ID: 20150407010204
Gaia: c710bac533b76635161315bf907d004e000549cb
Gecko: ab0490972e1e
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 40.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0

Comment 33

[Peter Bylenga [:PBylenga]]

Adding qawanted to check 2.2's current status.

Comment 34

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

This issue still occurs when updating from a 2.2 build to the latest 2.2 Nightly build.

Environmental Variables:
Device: Flame 2.2
BuildID: 20150407002501
Gaia: 5e09637414269728f6f1bc0152d0160f3b6b380e
Gecko: 245f37f44017
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
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 35

[Dominic Kuo [:dkuo]]

Marty, since Taipei side is unable to reproduce this bug for now, would you please provide the detail steps on how you perform the OTA? thanks.

(Mike and I used the 2.2 daily pvt builds to perform OTA, by changing the OTA channel from |default| to |nightly-b2g37| after we flashed one of the builds, so I guess we might have some steps/setup different then caused this)

Comment 36

[Martin Shuman [:Marty]]

These are the steps I use to reproduce this issue:

1) Update a Flame device to the previous day's Nightly build. Today, I used this one: https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/nightly/mozilla-b2g37_v2_2-flame-kk/2015/04/2015-04-07-00-25-01/
2) If needed, add 10 or more songs to the device via USB storage.  Often, the songs are already present on my device.
3) Open the Music app and rate each of these 10 songs. I then close and restart the Music app to ensure that the ratings for each song are applied properly.
4) Run the OTA update.  The builds I use are already set to |nightly-b2g37|, so I do not need to change the channel.
5) After the OTA, open the Music app and confirm the rating for each of the 10 songs.

Notes:
-Song ratings are not lost every time an OTA is run, so I typically run an OTA on 2-3 devices simultaneously, and repeat the process several times to ensure at least 5-6 OTAs total.  Song ratings appear to be lost approximately 50% of the times an OTA is performed.
-Not all songs lose their song ratings, and it isn't the same songs that lose their ratings each time.  On average, about 20% of the songs lose their ratings.

Comment 37

[Dominic Kuo [:dkuo]]

(In reply to Martin Shuman [:Marty] from comment #36)
> These are the steps I use to reproduce this issue:
> 
> 1) Update a Flame device to the previous day's Nightly build. Today, I used
> this one:
> https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/nightly/mozilla-
> b2g37_v2_2-flame-kk/2015/04/2015-04-07-00-25-01/
> 2) If needed, add 10 or more songs to the device via USB storage.  Often,
> the songs are already present on my device.
> 3) Open the Music app and rate each of these 10 songs. I then close and
> restart the Music app to ensure that the ratings for each song are applied
> properly.
> 4) Run the OTA update.  The builds I use are already set to |nightly-b2g37|,
> so I do not need to change the channel.
> 5) After the OTA, open the Music app and confirm the rating for each of the
> 10 songs.

Thanks Marty!

> Notes:
> -Song ratings are not lost every time an OTA is run, so I typically run an
> OTA on 2-3 devices simultaneously, and repeat the process several times to
> ensure at least 5-6 OTAs total.  Song ratings appear to be lost
> approximately 50% of the times an OTA is performed.
> -Not all songs lose their song ratings, and it isn't the same songs that
> lose their ratings each time.  On average, about 20% of the songs lose their
> ratings.

So does it means you did have some OTAs that successfully update the Music's database without any song ratings lost? this is important because we need to make sure Music handles the database upgrade properly, but caused this issue with some other root cause.

Also when some of the OTAs lost the song ratings, does Music re-scan the songs in storages? (you will see on the top there will be a bar indicating the scanning songs)

Thanks again.

Comment 38

[Martin Shuman [:Marty]]

(In reply to Dominic Kuo [:dkuo] from comment #37)
> So does it means you did have some OTAs that successfully update the Music's
> database without any song ratings lost? this is important because we need to
> make sure Music handles the database upgrade properly, but caused this issue
> with some other root cause.

Correct, sometimes the OTA is entirely successful, and no song ratings are lost.

> Also when some of the OTAs lost the song ratings, does Music re-scan the
> songs in storages? (you will see on the top there will be a bar indicating
> the scanning songs)

This does appear to be happening. I see a spinner up in the corner, briefly displaying song names, right when I launch Music the first time after an OTA.  I don't see every song name on the device displayed here. It seems that the only song names I see displayed are the ones that have lost their rating.

Comment 39

[Dominic Kuo [:dkuo]]

(In reply to Martin Shuman [:Marty] from comment #38)
> > Also when some of the OTAs lost the song ratings, does Music re-scan the
> > songs in storages? (you will see on the top there will be a bar indicating
> > the scanning songs)
> 
> This does appear to be happening. I see a spinner up in the corner, briefly
> displaying song names, right when I launch Music the first time after an
> OTA.  I don't see every song name on the device displayed here. It seems
> that the only song names I see displayed are the ones that have lost their
> rating.

Thanks Marty, it sounds like some of the songs lost their ratings and did rescanned by the Music app, and this is a good hint.

Comment 40

[Hema Koka [:hema]]

Dominic: any update o narrowing down the issue?

Thanks
Hema

Comment 41

[Dominic Kuo [:dkuo]]

(In reply to Hema Koka [:hema] from comment #40)
> Dominic: any update o narrowing down the issue?
> 
> Thanks
> Hema

Not yet, still figuring out how to reproduce it on my side, but I just finished one of the performance bug and several reviews so should have time to back on this.

Comment 42

[Dominic Kuo [:dkuo]]

While I am re-testing this bug, I think it's better to request qa for help, so adding qawanted and see if it's still reproducible with the latest build, because until now, we couldn't reproduce on my side and the Taipei qa team.

Comment 43

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

I could not reproduce this issue with the help of the original reporter making an update from yesterday's build to today's  0/15 attempts between the two of us.

Environmental Variables:
Device: Flame 3.0
BuildID: 20150423010203
Gaia: 9d4f756aa35cb7f030a92f3c1f65fb55254ddd1d
Gecko: 0b202671c9e2
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 40.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0


Environmental Variables:
Device: Flame 3.0
BuildID: 20150424010200
Gaia: 0c5e2ee1173f3c53379ef3cd10de714836258fe8
Gecko: 22a157f7feb7
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 40.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0

Comment 44

[Dominic Kuo [:dkuo]]

(In reply to Jayme Mercado [:JMercado] from comment #43)
> I could not reproduce this issue with the help of the original reporter
> making an update from yesterday's build to today's  0/15 attempts between
> the two of us.

Thanks for re-testing this!