View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0012889 | MMA | Playback | public | 2015-10-08 19:50 | 2017-03-28 02:18 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | crash | Reproducibility | sometimes |
| Status | closed | Resolution | fixed | ||
| Product Version | 1.1.3 | ||||
| Target Version | 1.3.0 | Fixed in Version | 1.3.0 | ||
| Summary | 0012889: Playback sometimes gets into a state where crossfading doesn't work / MMA crashes | ||||
| Description | Initially, crossfading seemed to work correctly until a bug occurred at the end of TrackC; TrackD started playing, but the seek bar remained at the end of TrackC. Debug Log: Y8P62WLPVF (+ logs auto-generated at 4:01/4:02pm EST). TrackC: Invei Hagefen After this occured, MMA crashed soon after. On restart, crossfading seemed to not work reliably at all as described below. Rather than crossfading tracks, track A stops 2s early and Track B immediately starts right after (no overlap). Debug log: ZF2H1J2FIL TrackA: Yaalili TrackB: Im Ein Li Mi Li A user described a similar situation in which crossfading didn't work in build 480: http://www.mediamonkey.com/forum/viewtopic.php?f=21&t=82542 The only way to get out of this state was to reboot the device, however, even that was a temporary solution, as the faulty crossfading recurred after the second track played. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 650 | ||||
| related to | 0012876 | closed | rusty | Playback is broken on some devices |
| related to | 0012228 | closed | martin | Crossfade option |
| has duplicate | 0012871 | closed | martin | Crossfade has a break at shuffle mode / fails on lollipop (regression playback is broken on kitkat) |
| related to | 0013346 | closed | martin | Crossfading: Crossfading issues |
| related to | 0014152 | feedback | martin | Crossfading doesn't work |
|
|
Further testing shows that crossfading almost always fails just by playing a few tracks. Play track a, seek to within 30s of the end of the track Play track b, seek to within 30s of the end of the track Play track c, seek to within 30s of the end of the track etc.... eventually (usually after 3-5 tracks) one of the following occurs: - playback continues but seekbar doesn't move and MMA crashes - silent playback (i.e. seekbar moves but no sound) - crossfading stops working in the sense that there's no overlap between the tracks--the first track stops and the second fades in - crossfading stops working in the sense that the first track stops and the second track fades in at the 20s mark - on occasion MMA gets into a state where it can't start or stop and the only solution is to reboot. This appears to be the same sympton/issue described at 0012876 |
|
|
Tested 'new' build 483 and all of the issues described above still occur. Moreover, they occur with greater regularity--it seems that all that's needed to trigger them is any of the following: - use of the seekbar - change in track in the middle of a currently playing track Moreover, the severity of the symptoms on the new build 483 is worse--crashing of MMA occurs more often with this latest build. Here's a log ID generated after a crash occurred: BN1NJ49R35 Finally, I retested build 482, and it seems that this bug does occur with build 482 as well, though much less often (the issue described at 0012876 with build 482 is probably another manifestation of this bug). Note: With build 483, I haven't been able to replicate the bug on Kitkat devices. Strangely, although the issues are easily replicable on a Nexus 5, they don't readily occur on a Nexus 7 (both running Android 5.1.2). |
|
|
From BN1NJ49R35 It looks like ANR. 1)Current player fails releasing and then block another actions 2)Next player due to crossfading plays to the end as Next player 3)When Next player is completed, playback fails. Also other playback issue could have similar reason. I have added logs to next test build 484 to detect what it blocks. Don't you have some ANR logs in android console? |
|
|
Performed the following test with build 484: 1 Play Od Yishama in full --> faulty transition to next track (track kind of Stops playing early, and next track starts--no overlap) 2 Invei Hagefen plays -->faulty transition to next track (track stops playing early, and next track 'Yalili' plays silently. Debug log: V2ZMXAYWDK ANR traces sent via email |
|
|
Further testing shows that this isn't a regression--the bug occurs in early MMA 1.1.3 builds as well (e.g. 1.1.3.460). It just wasn't discovered as the issue is device-specific. Based on Martin's analysis of the debug logs / anr traces, the issue stems from an Android bug in the MediaPlayer class ( http://developer.android.com/reference/android/media/MediaPlayer.html ) when more than 1 player is in use. Sometimes there's a freeze at MediaPlayer._release , and sometimes the OnCompletion event is called too early (when second player starts play or when volume is changing). If this is the case, then this issue cannot be fixed until we switch to an alternate player engine (feature 0011907 ). In the meantime the recommended course of action would be to: - Set Gapless as the default audio transition (instead of crossfade) - Change the crossfade selection text to 'Crossfade (beta)' instead of just 'Crossfade'. - Change the crossfade description text to 'Crossfades adjacent tracks (beta-unstable on some devices)' |
|
|
Upper described actions updated in build 1.1.3.485 |
|
|
As requested, here's debug log in Marshmallow where the issue is that crossfading stops working in the sense that there's no overlap between the tracks--the first track stops 3s early and the second track just starts. Debug log: 12174T61B9 (build 484) Debug log: 7NAUQY5JFQ (build 485) Also one new clue: when I test by playing over bluetooth the bug never occurs--it only occurs when playing over the speaker/headset! Please just tag as fixed if there's nothing you can do about this as before. |
|
|
A user reported other similar crossfading issues at: http://www.mediamonkey.com/forum/viewtopic.php?f=21&t=84135 |
|
|
Hopefully fixed by re-implementation due to 0013346. I have never replicate it, we will see what users say. Fixed in build 1.2.1.650 |
|
|
Verified 657 |
