View Issue Details

Jump to Notes
IDProjectCategoryView StatusDate SubmittedLast Update
0009650MMAGeneralpublic2012-09-06 03:082012-10-25 18:18
Reporterrusty Assigned To 
PriorityimmediateSeverityblockReproducibilityalways
Status closedResolutionfixed 
Product Version1.0.1 
Target Version1.0.1Fixed in Version1.0.1 
Summary0009650: Scanning never completes in some cases
DescriptionIn build 24, the scanning icon stays on and never disappears.

Content is visible in all nodes, except the Genre node which displays no tracks.

Note: this bug occurs on Gingerbread but not Jellybean (but this may be a function of the fact that the Gingerbread device had >1000 tracks and a playlist of > 900 tracks).
TagsNo tags attached.
Fixed in build50

Relationships

related to 0009572 closedmartin Music doesn't scan on clean install to Jellybean 
related to 0009883 closedmartin Navigating library while scan is in progress --> freeze 
related to 0010166 closedmartin Scans are never-ending for some devices/environments 

Activities

marek

2012-09-07 17:24

developer   ~0031826

Fixed exception in playlist sync

rusty

2012-09-07 21:35

administrator   ~0031838

Verified in build 26.

mambo-simon

2012-10-05 16:13

reporter   ~0032321

Same issue can be reproduced in build 37 in the following way
1. Clean all data, re-install app
2. When refresh is happening, force shut the app via the application menu
Expected: After restart, db refresh continues
Actual:
- Refresh icon appears and does not disappear.
- Number of songs in the list does not change (verify by using "select all" and checking count)

Device: Galaxy S3
Song number: 2000+

** Additional note - I know this is not a typical user scenario, but in testing we have seen similar scenarios but not consistently reproduced. I feel this scenario is a valid test of DB robustness which may prevent issues in more typical use cases.

rusty

2012-10-11 17:56

administrator   ~0032447

Note: this is no longer occurring in build 42.

jiri

2012-10-12 19:41

administrator   ~0032493

Assigned to Martin to review some possible issues internally...

martin

2012-10-15 20:44

developer   ~0032572

Never happened to me, after review and discussion with Marek I postpone it to happen again.

rusty

2012-10-17 22:10

administrator   ~0032628

Last edited: 2012-10-17 22:11

 In build 46, this seems to be happening on a GB device. Previously scans on that device took ~5 minutes. Now it's going on 10minutes+

note: this behavior is new to build 46 for me--I'd never observed it previsouly.

marek

2012-10-21 05:21

developer   ~0032693

Fixed in build 48

rusty

2012-10-21 21:45

administrator   ~0032703

Last edited: 2012-10-21 21:47

 Tested build 48, and scans on JB device with 200 tracks are fine, but scans on GB device with 1000+ tracks never end.

Uploaded debug logs at 10/21 5:46pm EST that hopefully illustrate where MM is stuck.

jiri

2012-10-23 13:36

administrator   ~0032743

Fixed in build 50.
 - Even though I can't reproduce the exact problem, setting as resolved, since I've just fixed a rather nasty sync problem caused by a buggy Android API. It caused many unnecessary sync operations in my case.

rusty

2012-10-25 18:18

administrator   ~0032794

Verified build 50.