View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004286 | MMW v4 | Synchronization | public | 2008-01-14 20:11 | 2008-01-15 15:13 |
| Reporter | rusty | Assigned To | |||
| Priority | immediate | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 3.0 | ||||
| Fixed in Version | 3.0 | ||||
| Summary | 0004286: Autosync list: Hierarchical Playlist selection fails -- MM syncs deselected playlists | ||||
| Description | In MM 3.0.1, if there is a hierarchy of playlists (e.g. Parent A, Child A1); if the user selects A and A1 is not selected, then MM syncs and reselects A1 anyhow. Note: it's OK that selected A would select A1, but it's not ok that deselecting A1 results in it subsequently being reselected by itself. Here's the full report from a user: In MM 3.0.1 I sync to a Zen Vision M using playlists exclusively. All of the playlists I sync are built by linking to other playlists. For example, I have playlist A, which includes all songs contained in playlist B and playlist C. I organize these playlists in the left side tree control by making the contained playlists (B &C) children of the container playlist (A) node. When I configure my device for synchronization I specifically check playlist A, and uncheck playlists B & C. If I then synchronize my device I find that not only is playlist A listed on my device, but so are playlists B & C. If I then reopen the configuration screen for my device in MM, I find that playlists B & C are again selected. Work around: If playlists B & C are changed from being children of playlist A node to being siblings of playlist A in the left side tree control, I can then go into sync configuration, select only playlist A and sync and get the desired results – only playlist A appears on my device. As I have around 20 playlists that are used only for building other playlists, I really like to hide them as children nodes of the containing playlists. While I can work around this issue, it does make the playlist node very large and unwieldy having to keep them all as root level playlists. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1130 | ||||
