View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0015137 | MMA | Navigation | public | 2018-10-08 02:18 | 2023-03-03 21:58 |
| Reporter | peke | Assigned To | |||
| Priority | immediate | Severity | major | Reproducibility | sometimes |
| Status | closed | Resolution | reopened | ||
| Target Version | 1.3.3 | Fixed in Version | 1.3.3 | ||
| Summary | 0015137: Android Auto: Browsing more than 500 Tracks, Artist, Albums Fail | ||||
| Description | Based on user reports MMA fail to serve listings larger than 500 leaving endless "Getting your selection..." More details in Forum Topic. | ||||
| Additional Information | https://www.mediamonkey.com/forum/viewtopic.php?f=21&t=91329 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 837 | ||||
|
|
Really, there is some size limit of a result on OS side. So in next build 1.3.3.829, MMA reflects the size of Playlist and Tracklist and if there are more items than 200, then the result will be divided to range subcategories e.g 1-200, 201-400, 401-655. For future versions, we can add subcategories also for alphabetic nodes. Fixed in build 1.3.3.829. |
|
|
Verified 829 |
|
|
Martin, I don't understand this issue entirely: 1) I don't have any problems accessing large playlists with Android Auto on my phone (I don't have Android Auto in my vehicle), so this change is actually very annoying. Ideally, this behavior should only occur if MM 'knows' that it's connected to an Android Auto device. If this isn't possible, would it make sense to make this behavior optional? e.g. Options > General: Limit list size for Android Auto [ ] Splits track lists into 200 track segments when connecting to Android Auto devices 2) The number of tracks that are split up seems inconsistent: - Users reported that the issue was for playlists > 500 tracks, but the implementation is to split playlists into < 200 tracks! - For a playlist of e.g. 499 tracks, the playlist gets split into 1-200, 201-499. If the limit is 200, then why is the second list composed of 299 tracks? |
|
|
1)The limit seems to be device specific, my Moto G5 with Android Auto app has no issue only with playlist < 450 items, my Nexus 5x can handle bigger playlist with >500 but has the same issue with a playlist containing around 1000 items. So the issue is not related to real Android Auto devices only. I guess that same issue will be also for other client using same interface like Android wear or Bluetooth devices, so the Options should be like Limit list size for remote clients [ ] Splits track lists into 200 track segments when connecting to Android Auto, Bluetooth etc. So both my devices can handle 400 tracks, so we can increase split from 200 to 400 items, do you agree? 2) re 1-200, 201-499. I wanted to avoid situation of split like 1-200, 201-400, 401-401 when the last segment contains one (or few) item only. So I implemented: if the last segment contains less then half of segment size then increase previous {last) segment. |
|
|
1) OK. But based on the data you've shared, we may want to make it configurable. e.g.: Limit list size for 3rd-party clients [ ] Splits track lists when connecting to Android Auto, Bluetooth, etc. List size limit for 3rd-party clients 400 Tracks 2) In such cases wouldn't it be better to divide the segments equally to reduce the risk of failure with the largest segment? e.g. for 499 tracks: 1-250, 251-499 |
|
|
1) What should be a default value? I am going to add these limit values to choose dialog (200, 400, 800, NONE) . 2) In your suggest solution none of the segment will have expected size specified in Options and calculation seems to me be a little complicated. I would prefer just decrease limit of modulo category a) to 10 items (max x+9 items in the last category and min 10 items in separate category) b )1/8*segment size (max x+(x/8)items in the last category and min x/8 items in the last separate category, where x is segment size). Maybe constant value to 10 would be better to avoid failure with the largest segment, right? |
|
|
1) I think 400 by default would work (though I'm tempted to set to 0 by default) Note: if we take the approach you describe (a single config entry), we'll have to revise the wording. e.g. List size limit for 3rd-party clients Splits track lists when connecting to Android Auto, Bluetooth, etc. (200 tracks | 400 tracks | 600 tracks | 800 tracks | disabled) Clicking the above, opens a config popup: List size limit for 3rd-party clients [200 | [400] | 600 | 800 | 1000 | unlimited] 2) I don't fully understand, but as long as the segments are roughly equal that's fine. |
|
|
I agree, but I think the current value should be visible in title similar as for crossfade options: List size limit for 3rd-party clients: %s Splits track lists when connecting to Android Auto, Bluetooth, etc. Agree? |
|
|
OK. |
|
|
Fixed in build 1.3.3.830 |
|
|
After more testing with other apps: 1)Browsing GoneMad, GooglePlayMusic behavior: There is no browsing of tracks, I mean e.g Playlist->Playlist1-> plays all playlist1 Also GoneMad Top Artists->Artist1->plays all tracks from Artist1 (no browsing Artist1 track by track) I think this behavior is due to a different limit of max items in a list. 2)About Queue, I get to know that also GoneMad fills the queue by more than 1 track, in fact, GoneMad fills queue by full tracklist, GoogleMusic player fills it by 1000 tracks, because all its playlists has max 1000 tracks. So I tried to fill Queue by our full tracklist with several thousands of tracks. Good news there is no issue with browsing limit like with playlists, albums etc. (Queue is filled by different API) Only I have to move a loading to this queue and do it asynchronously because loading of big tracklist takes some time. So my RECOMMENDATION how our node tree should look like: Tracks ->Play all ->Play (shuffled) Albums->Album1 ->Play all ->Play (shuffled) Playlist - Plallist1 ->Play all ->Play (shuffled) Now playing(Queue) -> Track1 Track2 ...Track Last (I mean all tracks from tracklist are visible when a user displays this view, the list is scrolled automatically to current track) |
|
|
The following describes some of the test results that fed into Martin's comments at 0015137:0051498 . It's followed by some additional implementation details discussed with Martin that elaborate on his comments: Tested build 830: Re 15137 [android auto can't support lists > x tracks] 1) When the user sets x < unlimited, usability is compromised since: a) it's impossible to Shuffle the entire list of tracks or an entire playlist b) it's a pain to browse a full list of tracks 2) When the user sets x = unlimited a) It may result in the 'getting your selection' error in Android Auto when Browsing b) There's no warning about this problem c) Even if the above error was somehow avoided when browsing, it may result in the 'getting your selection' error in Android Auto on playback since all tracks get added to Now Playing Re 14988 (bluetooth browsing): 1) Bluetooth can't handle mix of listings + commands: When I click 'Tracks' in Android Auto (running on the phone) --> 'Getting your selection' + endless hourglass (with split tracks set to unlimited--however this didn't occur previously when I clicked 'shuffle all'). I'm not sure why this is the case, but it's quite unfriendly and makes me wonder whether we should consider an approach that better warns the user of the consequences of switching to 'unlimited'. 2) [Truncated Now Playing is displayed automatically in Android Auto/Wear]: The new implementation shows both 'Now Playing(all)' and 'Now Playing' in Android Auto. Summary: MMA should support the following cases: 1) Browsing/Playback via Bluetooth Head unit [case I (default): device can't mix listings/commands; case II: device can mix listings commands | list lengths should be (optionally) capped to limit comms time, and so that NP list is usable] 2) Browsing/Playback via Android Auto [browsable lists must be cappable (default) or not] MMA's Android Auto implementation should support the above cases, and yet: a) splits tracklists in a 'friendly' way b) allow playback of _all_ tracks in a list. IMPLEMENTATION DETAILS ====================== Settings: --------- Limit list size for external apps Displays %s tracks when browsing via Android Auto, Bluetooth, etc. Values > 0 may be incompatible with some devices. Options dialog: Limit list size for external apps [ [0], 200, 400, 600, 1000, unlimited] Browsing: --------- If X=0, then browsing works exactly as described by Martin (tracks don't display in the browse menu). If X>0 then it displays e.g. as follows for both Android Auto and Bluetooth Head Units: Playlist <--PlaylistY (345) -> Play all -> Play (shuffled) -> Track1 -> Track2 ... -> TrackX ... In other words, MMA would display X tracks in the browser, (ideally followed by '...' signifying that it's not all displayed). The number of tracks '345' at the top is indicative of the total number of tracks--unconstrained by x. If the user taps Play all, Play (shuffle), or a particular Track --> Playback initiates for all of the tracks that are represented (not just those that are displayed). Now Playing: ------------ For MMA: As described by Martin, Now Playing in MMA is loaded directly from the DB (in its entirety) For Android Auto: As described by Martin, 'Now Playing' would display all tracks in the queue (there are no known issues re. limits on the number of tracks in the Android Auto Now Playing queue. This would be achieved by using the MediaSession queue ( https://developer.android.com/reference/android/support/v4/media/session/MediaSessionCompat#setQueue(java.util.List%3Candroid.support.v4.media.session.MediaSessionCompat.QueueItem%3E) ) since this global queue is included automatically in Android Auto, Wear and is automatically scrolled to the currently playing track. For Bluetooth head units: A customized 'Now Playing' list will be displayed consisting of a set number (41) of tracks that will be dynamically updated to reflect playback status. In other words if track Y of 500 is playing then this list will display: 20 tracks prior to y Track Y 20 tracks following y The list would have to be updated on every track change. Also, if the user presses BACK > 20 times, MM would continue to update the NP list and play the correct tracks (i.e. MMA's memory is of the full NP list and not just the segment that's currently displayed). Note: The rationale for the hardcoded value of =/- 20 tracks is that a larger list will make it difficult for users to see which is the currently playing track. If users want to see more of the list, we can make this value configurable in the future (or perhaps set it based on X). |
|
|
Re. the fact that the option title is too long: Limit list size for external apps Displays %s tracks when browsing via Android Auto, Bluetooth, etc. Values > 0 may be incompatible with some devices. Fixed in build 1.3.3.831 |
|
|
Verified build 831 vis a vis Android Auto. Changes in relation to Bluetooth should be verified at 0014988. |
|
|
The 'Getting your selection' bug in Android Auto is recurring in builds 835/833 using the Honor 5x that also replicates 0015198 1 Open Android auto and play a short playlist 2 Go to 'Tracks' and click 'Play' to play all 3800 tracks 3 Click 'Now Playing' in Android Auto and scroll through about 50 tracks --> All tracks display (note: in 1.3.2 only 20 tracks displayed) 4 Navigate 'Back' one level (so that it's possible to Choose Tracks, Genres, etc.) --> 'Getting your selection' appears for about 30s (probably due to the fact that the NP list is filling with a ton of tracks). Note: - Limit list size for external apps is set to 0 - The problem as replicated above doesn't occur with MMA 1.3.2 (probably due to the hardcoded 20-track limit for Now Playing) - The problem as replicated above also doesn't occur on a pixel device. It would seem that the device-specific issues on the Honor 5X that result in the manifestation of 0015198 may also be responsible for the manifestation of this bug. |
|
|
Tested 836 and the bug occurs exactly as in build 835 :-( Debug logs that are hopefully relevant are posted in 0015198 |
|
|
Fixed in build 1.3.3.837 |
|
|
Verified build 837. |
