Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[RedJ]

Sometime recently, smartlists that haven't been changed in many months have started returning results with tons of (13-22) duplicate entries (they are all the exact same file - when I play one of the duplicates all turn bold).  I have checked and the library only shows one copy of the file when viewing from any other view, such as Album.

I know that I can add a remove duplicates modifier to the smartlist to make these go away, but this is changed from previous results and it seems like incorrect behavior to be returning duplicates of the same file.

Here's a representative smartlist:

Code: [Select]

[/[Media Type]=[audio] -[Genre]="Karaoke" -[Genre]="Children" ([Genre]="Pop" or [Genre]="Rock") ~n=100 ~sort=Random ~mix=1000,66%,{[Rating]=[4],[5]},34%,{[Rating]=[3]} ~sort=[Name]code]

Is it possible the something was changed in Media Center's search engine code that is causing this?
UPDATE: So, I noticed that the smartlists with this problem used a mix of a Limit and Mix parameters and I thought there was a good chance they were in conflict in some way.  By reversing the order of the Mix and Limit parameters the duplicate tracks problem resolved (this is also probably the more correct order of operations anyways).  I think that this may still be something to look into as I'm not sure limiting prior to a mix, regardless of the inefficient ordering of parameters, should return results like that.  For anyone wondering why I have a mix of 1000 and then limit to 100- I don't know, I shouldn't and I thought this list limited the number of tracks from the same artist or album, so I need to fix that.

[ferday]

it makes a bit of sense to me, i don't think anything is broken

by limiting to 100, all operations after the limit will only have 100 tracks to work with, so maybe there is a further issue trying to mix 1000 (when the collection only "has" 100 tracks at that point).  i'm not sure that it should create duplicates but it could just be the confusion of the code. 

of course by mixing the 1000 and then limiting to 100 it should work (why don't you just mix 100?).  i would also suspect confusion if you did a mix 100 and limit 1000 in that order...

[RedJ]

I did acknowledge that I had not intended (and have no need) to limit by number of tracks in this specific smartlist since it uses Mix.  It probably is an unintended remnant of an earlier evolution of this smartlist. 

However, I don't believe MC used to return a bunch of duplicate tracks or I would have noticed it in the many months of using this smartlist.  In fact, this problem made the smartlist suddenly non-functional on my frequently used DLNA client, which is how I discovered it.  I think the more graceful handling of this should be to output the lesser of all limits (if you only had 100 tracks in your library and your forward-looking Mix operation asks for 1000, you should only get a maximum of 100 tracks, not a bunch of duplicates (that also aren't instanced, so cause problems).

On a related note: I wish you could drag to rearrange the order of smartlist rules and modifiers.  As these smartlists evolve over time, sometimes you want to make tweaks or experiments that would be easier without opening the text view and cutting and pasting.

[RoderickGI]

If you create a new Smartlist that is identical to the original with the problem, does that problem occur in the new Smartlist?

If not, there is history/garbage in the Smartlist definition. If yes, there could be something wrong in MC, or, as you have found, it is really a result of the settings sequence not being logical.

[RedJ]

If you create a new Smartlist that is identical to the original with the problem, does that problem occur in the new Smartlist?

I experimented around trying to see what conditions might reproduce the results and was able to get the duplicates again by using a Limit that's smaller than the Mix parameters.

It's actually a semi-logical result in that it's trying to return the number being requested from a pool of tracks that's now smaller than what's being requested and has to duplicate results to reach that number.  However, I don't think this is the best way for this condition to be handled because it can break things when the smartlist is played remotely.