View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0018791 | MMW 5 | Sync (MMS) | public | 2022-01-31 06:45 | 2023-09-27 15:09 |
| Reporter | barrym | Assigned To | |||
| Priority | urgent | Severity | feature | Reproducibility | always |
| Status | feedback | Resolution | open | ||
| Platform | Windows | OS | - | OS Version | 10 |
| Target Version | 5.1.1 | ||||
| Summary | 0018791: Request: Sync control seems inadequate | ||||
| Description | (originally reported as 018747: Request: Sync control seems inadequate in the MMA section by mistake) The MM tree sync control at D&S at the "Sync List Library --> Device" (aka "Library Content") panels is inadequate now that we can own 500gb phones, and can rent 2tb storage spaces at cloud locations at affordable rates. The current mechanism may have been suitable when people were syncing small amours of data, but it gets ugly to use in more complex or extensive situations. A design flaw is that the user has a single node to handle both: 1. selection of new items to be added to the sync list 2. management and review of items already sync'd to the device This creates two issues: a. visibility of what has been sync'd ... I browse collections while searching for new sync items ... once I have sync'd something I should not need to remember which Collection and node that I selected it from ... it should be added into a new top level node called >ItemsSyncedToDevice ... the existing "hide unselected items" checkbox does not work well; if I check it and then change nodes, the display is always empty even when their are checked items within ... Summary: finding what you have sync'd via half-visible half-checks in a multi-node tree maze control is not helpful b. flaky when items disappear ... I browse collections while searching for new items to sync ... the criteria for the collections may include variable attributes (eg. n days since ripped, or played < n times, or unplayed for n days ... these are all good indices to browse for this task) ... but once sync'd, these items can disappear from the Collection from which they were chosen due to Collection criteria .... this causes MM5 to want to delete the synced tracks ... maybe this is helpful if I sync'd the whole Collection, but IMO it is very unhelpful when I have specifically checked tracks or album to sync ... I want then remain at the sync location until I tire of hearing them ... the existing system is especially annoying when I have sync'd to an Internet location, because MM5 keeps wanting to delete the individual tracks ... the workaround is are to manually taking over all housekeeping of all sync'd items ... or to allow MM5 to delete the already synced tracks, and then re-synch them from a stable Collection like Music or ClassicalMusic ... neither workaround is scalable to modern device sizes IMO c. loss of control ... Even if I don't let MM delete the track, I have lost control of these items ... you can't see that they have been sync'd, and you have nothing to uncheck to de-sync them Suggestion: * existing functionality remains as it is * but also add a new top level >ItemsSyncedToDevice node to the two tree controls discussed above * rebuild the >ItemsSyncedToDevice node, in the background, whenever the D&S>Device node is opened * update this proposed tree, as tracks are checked and de checked in the existing control tree * in this proposed new node, list sync'd items in a Location sub-node, and|or in Album, AlbumArtist, Artist and Location nodes if you are feeling especially helpful * if the user unchecks any track for album in the >ItemsSyncedToDevice node, the track will be offered for deletion via the existing confirmation box when sync is triggered... where a track appears in multiple nodes, a single uncheck action, on any one of items appearances, is sufficient to cause deletion of the track or album from the sync location * changes made in the proposed >ItemsSyncedToDevice node is additional to any changes made in the existing tree More info at Ticket 0003356 Also why does the "Sync List Library --> Device" panel have another name in other D&S nodes? ... they are the same thing ... this anomaly does not help documentation writer, nor to a new user, nor to people trying offer assistance on the Community Forum | ||||
| Tags | No tags attached. | ||||
| Fixed in build | |||||
|
|
I'm not sure that I'm understanding the issues correctly. Can you clarify: a. Visibility of what has been synced: Are you saying that visibility is a problem because: . i the user has to switch between collections to see what is on the sync list for each collection? . ii OR is the problem that the tree isn't expanded and so the user must manually expand the tree to see which items are selected? . iii OR is it that there's no distinction between what was previously selected/synced and what edits the user is making to the sync list? b. Flaky when items disappear: I'm not sure I understand the problem: If a user syncs an auto-playlist which for which items disappear (and has 'Delete other files and playlists....' enabled) MM is _designed_ to delete the items that are no longer on the playlist. e.g. I have an auto-playlist of 1,000 randomly selected tracks rated 3.5+ Stars that haven't been played within the past 2 weeks. I have a second playlist of all 5-star tracks sorted randomly. Whenever I auto-sync, I expect that recently played tracks that are < 5 stars will be deleted from my device and new tracks matching the criteria will take their place. Which is how MM works. Could it be that the problem you're describing is that a playlist of 500 random tracks rated 3+ stars, is automatically resynced with a new random set of 500 tracks on each sync operation? If that's the issue, then would the auto-playlist's 'Random track' (instead of 'Random track (auto-refresh)') feature solve the problem? OR, is the problem that _manually_ synced tracks are deleted if they're not on the auto-sync list? c. Yes, it's true that when the user syncs by node/playlist there's limited visibility into what specific tracks are included in the sync list (only by hovering on the node can one see the specific tracks associated with the node). Are you suggesting that the auto-sync list should display individual tracks? d. "Sync List Library --> Device" panel has another name in other D&S nodes: are you referring to the fact that the 'Sync List (Device --> Library)' tab uses the terminology 'auto-sync' whereas 'Library --> Device' uses 'sync'? |
|
|
a.I and a.ii are both part of it. The problem isn't seeing what is sync'd ... it is finding an item, so it can be unsync'd ... more below. b: "disappearing" items explained below. c: better explained below d: the terminology for Internet locations and phone devices have different names for the same thing .. ie. Internet location "Library Content" is "Sync List (Library to Device)" for a phone ... they are the same thing aren't they? ... makes forum device support, and Help Text writing, more difficult that it needs to be. -------- Re-explanation: Maybe I am asking too much of MM sync facility? I have a phone with 12gb memory, and also 2tb available at Dropbox for streaming when away from home. I want MM5 to enable me to put a significant amount of trans-coded music at both locations, independently. I want to refresh parts of the music selections when I become bored with those albums. My criteria when choosing want to sync is multi-headed, ie:: a) pick some albums that are new to me ... ie. items handpicked from an MM5 collection based upon Added tag criteria limits b) also some older Albums that I have not listened to for a rolling period ... picked from another Collection based up Date Last Played limitations c) and all albums by a few Artists from whom I am currently doing a deep dive .. in a few months’ time I will pick an alternate group of Artists .. using AlbumArtist node for this d) and few albums that I picked while browsing other places That's within the MM5 Use Case? ... Substantial selections from multiple Collections and sub-nodes? It is easy browsing these locations, and picking a few hundred albums from each to be sync'd. But it all collapses in a heap when, three months later, you try and cycle out some of the albums; those which have become stale. 1. First there is the "visibility" problem when trying to house keep what has already been sync'd to a device or location. 2. And then there is an even worse situation, where MM5 design completely fails to handle the above objective. 3. And then there is a instability problem where MM5 loses track of what it has done, requiring manual clear out, and|or complete restart ... this is a PIA for a 12gb phone ... and is a absolute non-starter for a 2tb Internet location. I will start with point #2. Once MM5 has synced something, you can't just manually clear out the target location, because MM5 will re-sync the tracks. You need to find and uncheck your original request. I am not syncing playlists. I am selecting whole albums selected from the tree control in the Library Content tab @ D&S panel. So if you selected some "new" albums from a Collection whose criteria is Added in the last 3 months ... the album is going to disappear from that Collection in 3 months after it was added ... so if it was initially sync'd using that Collection, and it is still synced to the target when the album disappears from the Collection, you have now lost visibility and control over that sync request .. You now have no way of unsyncing the album (ie. no checkbox), nor any way of persistently clearing it from the target location. The same thing for any sync item selected from a Collection whose criteria is limited by Last Play date range. Once you play the album, it disappears from the Collection, and is now uncontrollable by MM5 sync facility MM5 completely lets you lets down in these situations; ie. Catch 22. Now to point #1 ... Even where MM5 has not let you down as above, it has a wholly inadequate UI IMO for the goal described above in anything but fairly trivial cases. You have to hunt through great long vertical tree lists to find which Collection, and from which sub node, an item was originally selected from. The "Hide Selected Items" facility should be your friend here, but it is a flaky and frustrating feature in MM5, although now I see that it has improved marginally since I made the original request. It seems that the tree becomes corrupted, and accordingly it cannot be relied on. See this video which demonstrates some of its problems .. https://www.dropbox.com/s/o4wya2vwrhhnpy7/Issues%20with%20Hide%20Unselected%20Items.mp4?dl=0 a) at the beginning I open the Composer sub-node which indicates that there is a selection somewhere .. at 0:10 I open The Composer node, and see that there are no selections at the beginning of the list, but at 0:16 when I open the first Composer, you see that there is a selection, same with the 2nd Composer ... so the initial view was unreliable b) at 1:16 I have Hide Selected turned off .. I open the Composer node .. it shows that I only have two Composers (?) ... I toggle Hide Selected on and off ... now I can see all of my Composers Other issues: c) There is no EntireLibrary node .. I have to hunt through every collection that indicates partial selection .. trying to remember from where I made the original selection 3 months ago .. up and down Collections, and their hierarchies, being ultra careful with clicking, so I don't unintentionally alter selections ... and wherever I originally selected anything using the Location node, I have click, click, click, click just to descend down to the NAS|Share|etcetc levels to get to where the album was selected ... at this point I am having to work for MM5; it should be working for me ... I would have been quicker to do the job myself by drag&Dropping using Explorer d) A couple of times the sync tree showed corruption by displaying many duplicate leaf nodes . this happened twice, but I don't know how to replicate e) And I had two MM5 crashes while retesting this Devices&Services facility today with the latest version ... the whole UI froze while trying to send you a dump file f) a MM5 crash when syncing seems to screw up the view that MM5 has regarding what it has sync'd to the target location ... there is a lot of manual micro-managing to recover from this situation, ie. MM5 doesn't seem to be able to rebuild its view of what it has sync'ed to the target device ... all unworkable with large diverse selection lists g) I also had an instance when the Sync list forgot that it has sync'd an album to the target location, without being caused by a crash (?!) ... I turned on The Delete Other Files" option to auto-house keep ... it prompted me to delete files that were outside of the File Locations mask recorded in the Sync Profile tab (?!) see https://www.dropbox.com/s/ri31eog7ytqvc4x/going%20out%20of%20bounds%20when%20offering%20to%20delete.mp4?dl=0 I think that the MM5 Sync facility needs to evolve, ie have two trees i) One tree for **making** selections; lots of nodes and sub-nodes to aid selection .. nb the tree can also (optionally) be used for deselections ..ie. what you have now ii) But also have a flat tree for housekeeping items which have already been sync'd to the device ... ie. items can be deselected, without having to determine where it was selected from, also removing the risk of items become uncontrollable, because they disappeared from the Collection from where they were selected .. this tree would contain only items which have been synced, and is only for the purpose of deselecting items ... deselections are auto-synced to the selection tree (i) iii) It would be good if the MM5 Sync facility audited and auto-healed itself ... ie. when it finds tracks, at the target location, where it has forgotten that it sync'd, it would correct itself ... the (defunct) MM5 facility that sync'ed Google Play Music was able to do this ... ie. it could seed itself where a customer had already sync'd a lot of tracks up to GPM before starting to use MM5 to takeover this function ... this safety net is required if someone is to consider transcoding their whole collection to an Internet location .. something that is feasible from a cost POV, and Internet bandwidth POV, but not from a MM5 robustness POV |
