View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005369 | MMW v4 | Burning / Disc Handling | public | 2009-03-11 03:40 | 2009-05-09 12:00 |
| Reporter | rusty | Assigned To | |||
| Priority | immediate | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 3.1 | ||||
| Target Version | 3.1 | Fixed in Version | 3.1 | ||
| Summary | 0005369: Burning common Playlist tracks and Pre-Selected tracks causes tracks to be burnt incorrectly | ||||
| Description | If the users burns a Data CD comprising tracks that are both part of the 'Pre-selected tracks' and part of a Playlist, causes tracks to be missing from the playlist and duplicated elsewhere. This is best illustrated by an example: 1) Create a playlist called ABC of tracks a, b, c, d, e, f, g, h, i, j 2) Select tracks 1, 2, 3, f, 5, 6 and click burn to burn a data CD 3) In the burn dialog, enable both 'Pre-selected tracks' and playlist 'ABC': Disc format: \Music\<Auto Number>-<Artist>-<Title> [x] Burn Playlist Tracks to: \Music\Playlists\<Playlist>\<Auto Number>-<Title> [x] Burn .m3u playlists (enable option for Library Playlists to: \Playlists\ using prefixes) --> Directory \Music has track f in duplicate ! --> Directory \Playlist\ABC is missing track f (that's OK--there's no need to duplicate it) --> Playlist - ABC.m3u is missing f! --> Playlist - Preselected.m3u has f in quadruplicate! Note: I didn't test whether similar problems occur with device synchronization (e.g. when selecting tracks common to multiple playlists OR playlist + Genre). | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1229 | ||||
|
|
Fixed in build 1227. |
|
|
Tested 1227: there's still a minor error remaining: The .m3u file for the pre-selected tracks is missing the file that is common to Pre-selected Tracks and Playlist 'ABC'. |
|
|
Rusty, based on the specification from MM 2.5 the track should be duplicated only if the Playlist mask is active ([x] Burn Plalists tracks to), i.e. in this case: The track is in both \Music\f \Playlist\ABC\f and in the Pre-selected.m3u the track f is as '\Music\f' reference and in the ABC.m3u is as '\Playlist\ABC\f' reference. I think this is all right (because of consistency) - e.g. both these tracks are named diferrently based on the masks and fit the playlists based on the auto-number as well. e.g. the track f can be '\Music\004 f' in one playlist and '\Playlist\ABC\006 f' in another. |
|
|
The reason for not duplicating tracks in the directories is because of space issues (e.g. if a track was on playlist a,b,c,d, it shouldn't appear four times on the disc--doing so would quickly fill up the disk unnecessarily). However, the tracks that are in duplicate _should_not_ be removed from the .m3u playlist--since then the user doesn't get the playlist that they expect. |
|
|
Ok, but if a track is on playlist a,b,c,d, it DOESN'T appear four times on the disc, because Playlist mask is common to all these playlists. i.e. for all the playlists the track is in one location Music\Playlist\ABC\f and is not duplicated. The track is only duplicated in the case when: 1. 'Burn Playlist Tracks to' checkbox is enabled 2. the two music masks are different (I mean 'Disc format' and 'Burn Playlist Tracks to' masks) 3. the track is part of a selected playlist and in addition is part of another selected item (but not a playlist - e.g. album) at the same time This is the ONLY situation where the track is duplicated and it is right that the track is burnt into two different locations, because the two masks are different and the user (like me) wanted to have this track into different locations otherwise he would not enable the 'Burn Playlist Tracks to' checkbox. I think that changing this would be a regression. I have never seen any complaint regarding to this behaviour since MM 2.5 where we added this ability to burn tracks coming from a playlist into another location. |
|
|
I understand your point about the fact that MM should create duplicates if the user has specified masks that trigger duplicates, though I'm not sure I agree (especially when it comes to portable devices, which is what the feature was originally design for). But we don't have to discuss that now. The bug that I'm describing, is the fact that files are _missing_ from the m3u playlist, even when both masks are enabled. Do you not see that behavior? |
|
|
No, after my fix in 1227 it works exactly as described: 1) Create a playlist called ABC of tracks a, b, c, d, e, f, g, h, i, j 2) Select tracks 1, 2, 3, f, 5, 6 and click burn to burn a data CD 3) In the burn dialog, enable both 'Pre-selected tracks' and playlist 'ABC': Disc format: \Music\<Auto Number>-<Title> [x] Burn Playlist Tracks to: \Music\Playlists\<Playlist>\<Auto Number>-<Title> [x] Burn .m3u playlists (enable option for Library Playlists to: \Playlists\ using prefixes) --> Directory \Music\ contains: 001-1 002-2 003-3 004-f 005-5 006-6 --> Directory \Playlist\ABC contains: 001-a 002-b 003-c 004-d 005-e 006-f 007-g 008-h 009-i 010-j --> Playlist - Preselected.m3u : Music\001-1 Music\002-2 Music\003-3 Music\004-f Music\005-5 Music\006-6 -->PLaylist ABC.m3u : Music\Playlist\ABC\001-a Music\Playlist\ABC\002-b Music\Playlist\ABC\003-c Music\Playlist\ABC\004-d Music\Playlist\ABC\005-e Music\Playlist\ABC\006-f Music\Playlist\ABC\007-g Music\Playlist\ABC\008-h Music\Playlist\ABC\009-i Music\Playlist\ABC\010-j Could you try to re-test? I guess that it really should works same way for you, I don't see a reason why it should behave differently for the same test case. |
|
|
Rusty, I've tried another test with more playlists and there are still some issues (I found that it is a regreassion related to 0004796), assigned to me for investigation. |
|
|
All is fixed and in addition I implemented the solution you suggested that track should not be duplicated even if masks trigger duplicates. All should work fine according your suggestion, but I am still not sure whether this will satisfy most of users, hard to tell. Fixed in build 1229. Note that anything changed in this issue will not influence device synchronization, all changed here is only related to burning (there is no '[x] Burn Playlists tracks to' option on the device sync dialog) |
|
|
Verified 1244 |
