View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005963 | MMW v4 | Properties/Auto-Tools | public | 2009-09-17 01:05 | 2009-10-15 21:23 |
| Reporter | user_chrisjj | Assigned To | |||
| Priority | urgent | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Platform | Windows | OS | XP | OS Version | - |
| Fixed in Version | 3.1.2 | ||||
| Summary | 0005963: Track Properties: Removing a playlist entry removes all references of the track from the playlist | ||||
| Description | The bug is that for any given track, Properties > Classifications > Playlists shows a playlist for each time the track appears in the playlist, BUT unchecking one instance, causes all instances of the track to be removed from the playlist. | ||||
| Steps To Reproduce | 1) Select a track that appears multiple times within PlaylistX. 2) Right click > Properties > Classification , in the Playlists section, multiple instances of PlaylistX appear (reflecting the numerous instances of the track within the playlist). Untick the first reference and click ok. --> in PlaylistX _all_ instances of the track have been removed Expected: only the first instance should have been removed. | ||||
| Additional Information | See http://www.mediamonkey.com/forum/viewtopic.php?f=7&t=40926 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1270 | ||||
|
|
Note that this bug exists only when you remove a playlist entry via Song Properties -> Classification -> Playlists pane. This is speculative, probably there should be only one playlist entry in the properties panel and unticking this playlist would cause _all_ song entries to be deleted from the playlist. @Rusty, do you agree? |
|
|
> probably there should be only one playlist entry in the properties panel Sure, removing the bugged feature would 'fix' the bug, but that would be a sad loss of functionality. |
|
|
I don't think there would be a loss of functionality. If you see that a track is in a playlist and you wish it to not to be part of the playlist then you want to remove all the instances of the track from the playlist. If you want to remove only one instance then go directly to the playlist and remove the concrete instance from there. I think that what I suggests makes sense. i.e. There should be only one playlist instance that removes all the track instances from the playlist, because there is (in fact) only one instance of the playlist in the DB, so why we should show more instances of the playlist if there is only one ?? Rusty? |
|
|
Rusty, I think you have misunderstood what this dialog shows. It shows REFERENCEs from playlists. It shows multiple entries of a single playlist when there multiple REFERENCEs from that playlist. This the only way to get a compact view of these references, and editing should work properly because otherwise users would be forced to call up each playlist individually (defeating the point of this dialog control) and scroll down possibly miles searching by eye for the references to the particular track. Possibly you don't have playlists with hundres of tracks and repeat references, but I and other power playlist users most certainly do: e.g. here is a small case: http://chrisjj.com/tango/cjjsets/2009-09-04_Wolfson.html |
|
|
PS The proposed 'fix' is worse than the current bug because it will lose the display functionality. If Devs won't fix the bug, please at least don't implement the 'fix' |
|
|
Ludek, I agree with Chris. It's useful to see the number of times that a track appears within a playlist, _and_ it would also be expected that removing one instance would remove _only_ that instance. If it's too difficult/risky to fix the problem for now, then a temporary hack would be that whenever the user selects/deselects a playlist instance (in Properties > Classifications > Playlists) _all_ instances of the playlist should be selected/deselected. That way the user is at least made aware of what will actually happen. |
|
|
And what if there are 2 same named playlists? Therefore I think that approach I suggest is logical. Two same named playlists, two playlist entries. |
|
|
hmmm... that's a new aspect of the bug that I hadn't thought of. I guess there are a couple of possible approaches: 1) Disallow identically named playlists 2) Differentiate between identically named playlists in the Properties > Classifications > Playlists UI by indicating where they appear in the playlist e.g. [x] Playlist X [x] (#1) [x] (#9) [x] (#37) [x] Playlist X [x] (0000023) [x] (#79) 3) Clearly indicate the number of times a track appears in a playlist, but only allow an all-in or all-out choice. e.g. [x] Playlist X {3x) [x] Playlist X (2x) I think that 2) is the best choice, but it depends on the effort--I don't think that this is that a severe problem, so 3) would be my second choice. |
|
|
Fixed by using solution 3) 1. For performance reasons: on large DBs solution 2) would take extra time 2. The second reason is that user can get immediately to the playlist in order to edit the playlist just by clicking on the playlist ;-) Note that this fixed also another bug: If multiple instances of one track exist in one playlist then 'Find more from same' -> 'Playlist' menu shows the playlist multiple times! Fixed in 1268. |
|
|
> And what if there are 2 same named playlists? That's a more general problam http://www.mediamonkey.com/forum/viewtopic.php?f=4&t=38514&hilit=playlist+path#p198274 which I suggest should be fixed anyway. |
|
|
> Fixed by using solution 3) Disappointing. This fix is worse than the bug. |
|
|
Re-opening because of a small regression that was introduced by the fix: Some tracks now have an empty playlist entry in the Classification tab. Fixed in build 1270. |
|
|
verified 1273 |
