View Issue Details

IDProjectCategoryView StatusLast Update
0006482MMW v4Collections (Filters)public2011-05-22 20:15
Reporterrusty Assigned To 
PriorityurgentSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version4.0 
Target Version4.0Fixed in Version4.0 
Summary0006482: Collections may be empty even when they shouldn't be
DescriptionOn upgrading from MM3 to MM4, all music that is labeled 'Classical' did not end up in the 'Classical' collection.

Also, scanning classical music doesn't cause the files to be added to the Classical collection.

Similarly, can you explain the logic re. how TV and Music Videos get assigned to the appropriate Collection (since it doesn't appear to be based on Genre)?
TagsNo tags attached.
Fixed in build1314

Relationships

related to 0007658 new TreeNodes: File Types 
related to 0007344 closedLudek Scanned Video Podcasts don't appear in the library as expected (regression) 

Activities

Ludek

2010-09-17 15:39

developer   ~0020544

The workflow is currently:


  if (Ext = 'M4B') or ( GenreIncludeWord( 'BOOK') and not IsVideoFile) then
    TrackType := TT_AUDIOBOOK
  else
  if GenreIncludeWord( 'PODCAST') then
  begin
    if IsVideoFile then
      TrackType := TT_VIDEOPODCAST
    else
      TrackType := TT_PODCAST;
  end
  else
  begin
    if IsVideoFile then
      TrckType := TT_VIDEO
    else
      TrckType := TT_MUSIC
  end;

i.e. Music Videos, TV Shows and Classical music aren't assigned at all until user assigns them manually via properties.

I would suggest for video files:
- that haven't album and artist fields empty to be classified as TT_MUSICVIDEO
- that have word 'TV Show' included within genre to be classified as TT_TV
- that have word 'Classical' included within genre to be classified as TT_CLASSICALMUSIC


What do you think?

rusty

2010-09-17 16:34

administrator   ~0020545

Last edited: 2010-09-17 16:38

-For all files: when you say that the logic searches for a genre e.g. 'Book' for classification, do you think that the logic should also search for localized variants of the term?

-For Music Video Files: If they have Album/Artist fields filled in, it might mean that it's a TV show rather than a Music Video, since TV Shows might be of the form:
Title=Episode 1 - The Dreamers, Album(=Series)=Weeds, Disc#(=Season)=01, Artist:--probably not used
I would suggest that if it has 'Music Video' in the Genre, it should be classified as such.

-For TV shows, the genre can be 'TV', 'TV Show', 'TV Series', 'Series', 'Television'.

-For Classical, sounds good (though I assume that you didn't mean classical videos)

-Most Importantly: it's likely that users will have a lot of Video files that need to be reclassified as TV or as Music Videos, however, the MM UI currently has no way to easily do this. D&D between collections would be simplest. What do you think?

p.s. I assume that the logic applies to scans/filemonitor and to db imports from MM3.

Ludek

2010-09-17 19:10

developer   ~0020546

Last edited: 2010-09-17 19:12

- using also localized variants of the terms sounds good
- yes, I meant classical music
- D&D between collections isn't good idea, because Collections needn't to be type related and are defined by Auto-Playlist rules. The type can be easily changed via Track Properties (also via mass edit). I think it is enough

rusty

2010-09-17 20:36

administrator   ~0020549

Sounds good.

Re. how to move Video Files into another collection: I expect that users will find it cumbersome to do this via a mass edit. Afaik, Type isn't even on the main Properties tab.

I guess we'll see...

jiri

2010-09-20 05:30

administrator   ~0020553

I agree with the suggested genre assignment, I'd just add that in all cases it should be an exact match (note that there can be >1 genre per track), in order to avoid some false matches (which would probably be worse than to not have some matches). So, I'd say that for Audiobooks we should accept only 'audiobook' or 'audio book' and for classical music only 'classical' or 'classical music'.

As mentioned, I think that Type should be on the first tab of Properties dialog, probably even the very first field.

As for d&d, as correctly noted by Ludek, Collections aren't related to Types in 1-1 relation. I'd suggest the following: If user drags some track(s) to a Collection node and the collection has exactly 1 Type in its definition, this Type is assigned to the tracks. In case there are 0, 2, 3, ... Types, a dialog is shown to the user and he/she can select which Type to assign.

rusty

2010-09-27 22:45

administrator   ~0020582

Note: tested build 1313 and scanned a directory containing many tracks with Genre = Audiobooks.

Bug: the tracks did not get added to the Audiobooks collection (even though that logic has already been implemented (I think).

Ludek

2010-09-27 23:19

developer   ~0020583

Last edited: 2010-09-29 11:08

Re: Assigment:
I don't think that it should be an exact match, because beside of genre "Audiobook" and "Audio book" there can be genres like "Audiobooks" or "Audio books" or "Michel's audiobooks" that should be IMHO considered as audiobooks.
Beside this there probably will be MM3 users that would like the genre including word "book" to be considered as audiobook (like it used to be in MM3) - we will see (probably not a big deal).

Otherwise I used also the localized variants of the words and the current assigment algorithm is:

 if (Ext = 'M4B') or ( GenreIncludeWord( ['Audiobook', 'Audio book']) and not IsVideoFile) then
    TrackType = AUDIOBOOK
  else
  if GenreIncludeWord( ['Podcast']) then
  begin
    if IsVideoFile then
      TrackType = VIDEOPODCAST
    else
      TrackType = PODCAST
  end
  else
  begin
    if IsVideoFile then
    begin
      if GenreIncludeWord( ['TV Show', 'TV Series', 'Television']) then
        TrackType = TV
      else
      if GenreIncludeWord( ['Music Video']) then
        TrackType = MUSICVIDEO
      else
        TrackType = VIDEO
    end
    else
    begin
      if GenreIncludeWord( ['Classical', 'Classical music']) then
        TrackType = CLASSICALMUSIC
      else
        TrackType = MUSIC
    end;

Re: D&D:
I constructed the workflow this way:
If a collection is defined by only one rule and the rule consist of "Type is" then the first type is considered as assignment (this works perfectly for the default collections) otherwise (if the collection consists of another rule(s)) the drop is not offered.

Implemented in build 1314.

peke

2010-10-22 20:57

developer   ~0020917

I'm not sure how to do future regression testing for this feature?

Can you please elaborate?

Wouldn't be more intuitive/friendlier to make genre Grouping feature and make that Customizable?

Note: I understand how it works, but it looks little bit limiting especially as Users can Assign own custom Type to Library entries.

Ludek

2010-10-23 00:22

developer   ~0020923

Last edited: 2010-10-23 00:22

Peke, I don't understand this:
"Note: I understand how it works, but it looks little bit limiting especially as Users can Assign own custom Type to Library entries."

This is just an algorithm that tries to init Track type (Audio, Video, Podcast), user can modify the Track type later so what is limiting?

peke

2010-10-23 10:58

developer   ~0020925

I meant that I understand the algorithm which tries to init Track type and that user can change it later. I'm more thinking on something like this:

- AudioBook
..|Podcasts
..|Audio book
..|AudioBooks
..|Michel's audiobooks
..|DJ Mixed track sets
..|...
- Video
..|TV Show
..|TV Series
..|Television
..|Series
..|...
- Classical music
..|Classical
..|Classicals
..|Orchestral
..|...
- ...

The more I think of that the more I'm thinking that it would be useful to make MM learn what particular user uses for Track Types and with time MM would more accurately init track type.

This is hardcoded right now and to add new case new MM version would need to be made. Some suggestion like above should solve that issue.

I was not sure how to test this bug unless I have with these predefined genres. I'm guessing that I was expecting something more like I wrote above than hardcoded predefined genres.

Ludek

2010-10-23 15:08

developer   ~0020927

Last edited: 2010-10-23 15:40

Sounds like interesting idea.
i.e.
1. Have a default set of genres to assign type, e.g.
For Audiobook: ['Audio book','Book', 'Audio Books']
For Podcasts: ['Podcast']
For TV Shows: ['TV', 'TV Show' 'TV Series', 'Television']
For Music video: ['Music Video']
For Classical music: ['Classical', 'Classical music']

And if user notices that track with genre = "Michel's audiobook" hasn't been added to audiobooks and he adds it manually then MM will add this genre to the set of genres to be considered as Audiobook.

BUT, problem is that genres like 'Show' can be sometimes considered as Music Video, another time as TV Show and another time as Video.
Similarly there are a lot of genres that are common to Video and Audiobooks, like 'novel', 'romance', 'drama', 'tragedy', 'commendy' etc. , but they can be differentiated based on file type (audio/video), but also TV Show can be 'novel' or 'comedy'. Similarly Classical Music can include genre 'Orchestral' as well as Music.
Because of such a problems it could be better to deffer this approach.
Hard to say which approach is generally better (probably requires a statistical analyze).

peke

2010-10-23 23:13

developer   ~0020929

I agree on leaving current approach in introducing customizable Track Types in MM 4.0 that uses predefined assignment detection algorithm you already made and generally efficient for most users.

In later MM versions (4.1?) we can introduce New MM tree sub nodes that will allow to change/assign Track Types like current it is done with Genre Tree node and D&D functionality (including feature when D&D is used with coalition of pressed CTRL, ALT, SHIFT,...)

Example:
- Music
..- Sub Types
...| Concerts
...| Unplugged
...| DJ Mixes
...| ...
- Video
..- Sub Types
...| Concerts
...| TV Shows
...| Series
...| ...

I got an idea while trying how to best test current approach and like you said we certainly have optimization/improvement space in the area, after we hammer current features to ensure that it will not degrade MM speed and functionality.

rusty

2010-10-24 19:51

administrator   ~0020935

Tagging as resolved. Let's wait and see--we'll collect user feedback on this.

peke

2011-04-12 22:02

developer   ~0024265

Verified 1363