View Issue Details

IDProjectCategoryView StatusLast Update
0002176MMW v4Burning / Disc Handlingpublic2005-11-27 04:37
Reporterrusty Assigned To 
PriorityimmediateSeveritymajorReproducibilityalways
Status closedResolutionreopened 
Summary0002176: Almost all files are 'red' (duplicates) when attempting to burn an MP3 DVD
DescriptionIn build 914, if the user:
-chooses 15 artists to burn to a dvd
-uses the mask Artist/Album/Artist-Title
-->Almost all of the tracks are listed as 'duplicates'

My guess is that this will be resolved when 0002068 is fixed, however, I figured this should be noted anyhow due to the severity of the problem.
TagsNo tags attached.
Fixed in build917

Activities

Ludek

2005-11-22 12:55

developer   ~0006314

Yes, there was the problem that songs were added for both Artist and Album nodes.
It was fixed in build 915.
Now, the album songs are added only if it isn't already contained in the artist node (Artist node contains this album and Artist node is checked normal - not mixed(square inside the checkbox) ).

rusty

2005-11-23 14:27

administrator   ~0006334

Tested in build 915 and indeed, the particular problem of Artist & Album duplicates being highlighted unnecessarily has been solved, however, duplicates are still highlighted unnecessarily whenever the following are both selected:

Location | Artist
Location | Album
Location | Playlist
Artist | Playlist
Album | Playlist

In other words, the current implementation's definition of 'duplicate' is much too strict, as it considers a duplicate to be any time the user has (inadvertently) selected a track via more than one node, whereas what is really required is for it to warn the user whenever DIFFERENT tracks have been selected that have DUPLICATE NAMESPACES.

For example:
In my library I have:
Artist: U2
Album: Joshua Tree

Artist: U2
Album: Best of

Now suppose I select:
Location
[x] /U2/

Album
[x] Best of (U2)

In the current implementation I will get a warning about duplicates _for every track that is on the 'Best of (U2)' album because the implementation considers that the tracks were all selected twice. HOWEVER, the user doesn't care that they've selected the tracks twice, the only thing that they should have been warned about is that 'D:/U2/U2-Where the Streets Have no Name' is a duplicate because 2 different tracks (one from The Joshua Tree and the other from Best of) map to the same namespace.

Ludek

2005-11-25 09:16

developer   ~0006365

Ok, I have changed it in sense that warning is given only if 2 tracks with different source on the HD map to the same filename on the CD/DVD.

Fixed in build 917.

Ludek

2005-11-25 15:42

developer   ~0006382

Last edited: 2005-11-25 15:46

But in case of two same tracks (same source on the HDD) coming from (Location | Album) map to one location on the CD/DVD and no warning of duplicates is given, it implifies that the number of burned tracks depends on the mask. If you change the mask, the number of tracks should be changed too in this case. It isn't contained in the build 917, but try to review and request feedback, cause it could be harder to implement.

rusty

2005-11-27 04:32

administrator   ~0006391

Tested in 917, and it's looking much better. There's still 1 major problem though:

If the user selects:
-Artist
. [x]-Air
. . . .-Moon Safari
-Album
. [x]-Moon Safari
-Playlist
. [x]-Moon Safari Playlist
-Location
. [x]/Music/Air/Moon Safari

And used only a 'normal' mask (i.e. no Playlist mask),

-->

Each of the tracks from Moon Safari appear 3 times in the burn list. What should happen is that they appear only once! (i.e. whenever the same track is selected via multiple locations it should still appear only once in the list).

In the above example, if the user enables the Playlist mask, then in the example above, the tracks should appear twice (once for the 'normal' mask and once for the 'Playlist' mask).

Note: The playlist mask should only cause tracks to be written a second time IFF the track has been selected via a Playlist node AND via a node other than the Playlists node.

rusty

2005-11-27 04:37

administrator   ~0006392

Closing.

The problem I described is not related to this particular bug. I'll cover it elsewhere.