Post Reply 
 
Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
MinimServer Conflicting Values in Filter Warning
03-09-2017, 17:59
Post: #1
MinimServer Conflicting Values in Filter Warning
I have recently created a tag ENCODINGTIME for all my music files to allow indexing of the month they were added to my collection. I initially populated it with yyyy-mm strings for my new rips. Then I got more adventurous and ran a batch process to dump every file's creation date in yyyy-mm-dd hh:mmConfuseds format to the ENCODINGTIME tag (checking for errors where the day was not consistent for a whole album: some creation dates did not correctly reflect the original rip date).

I then added -EncodingTime:Month Added to the indexTags property. Finally, EncodingTime.yearMonth.index to the tagOptions property.

Now I'm seeing warnings in the log, such as:
Warning: sort value conflict for EncodingTime filter 2009-09
first conflicting value is '2009-09-16 10:36:30' in item 'Bruckner: Symphony #7 In E, WAB 107 - 1. Allegro Moderato'
second conflicting value is '2009-09-16 10:34:16' in item 'Bruckner: Symphony #7 In E, WAB 107 - 2. Adagio: Sehr Feierlich Und Sehr Langsam'

It seems that at least one of the conflicting pairs is in long yyyy-mm-dd hh:mmConfuseds format so I'm wondering if the tagOption yearMonth is not coping with strings longer than yyyy-mm-dd? There are over 100 warnings in the log but I don't see any pairs (there are only ever two conficting values) where both are in yyyy-mm format.

Any clues?
Find all posts by this user
Quote this message in a reply
03-09-2017, 18:01
Post: #2
RE: MinimServer Conflicting Values in Filter Warning
(03-09-2017 17:59)qblack Wrote:  I have recently created a tag ENCODINGTIME for all my music files to allow indexing of the month they were added to my collection. I initially populated it with yyyy-mm strings for my new rips. Then I got more adventurous and ran a batch process to dump every file's creation date in yyyy-mm-dd hh:mm:ss format to the ENCODINGTIME tag (checking for errors where the day was not consistent for a whole album: some creation dates did not correctly reflect the original rip date).

I then added -EncodingTime:Month Added to the indexTags property. Finally, EncodingTime.yearMonth.index to the tagOptions property.

Now I'm seeing warnings in the log, such as:
Warning: sort value conflict for EncodingTime filter 2009-09
first conflicting value is '2009-09-16 10:36:30' in item 'Bruckner: Symphony #7 In E, WAB 107 - 1. Allegro Moderato'
second conflicting value is '2009-09-16 10:34:16' in item 'Bruckner: Symphony #7 In E, WAB 107 - 2. Adagio: Sehr Feierlich Und Sehr Langsam'

It seems that at least one of the conflicting pairs is in long yyyy-mm-dd hh:mm:ss format so I'm wondering if the tagOption yearMonth is not coping with strings longer than yyyy-mm-dd? There are over 100 warnings in the log but I don't see any pairs (there are only ever two conficting values) where both are in yyyy-mm format.

Any clues?

Edit: Don't know how hh:mm:ss was mutated above. Trying again: yyyy-mm-dd hh:mm:ss.
Find all posts by this user
Quote this message in a reply
03-09-2017, 20:52
Post: #3
RE: MinimServer Conflicting Values in Filter Warning
The short answer is that you need to change EncodingTime.yearMonth.index to EncodingTime.yearMonth.index.sort. To understand why, read on....

Suppose your library contains albums tagged with a mixture of the following:

COMPOSER=Johann Sebastian Bach
COMPOSER=Bach, J.S

You decide that you want to see all these in your composer index as J.S. Bach, so you configure MinimServer to set all the index values to J.S. Bach. Because this doesn't change the sort values, you would get index entries for J.S. Bach in both the B and J sections of the Composer index. The J.S. Bach entry in the B section would contain everything tagged COMPOSER=Bach, J.S and the J.S. Bach entry in the J section would contain contain everything tagged COMPOSER=Johann Sebastian Bach.

This doesn't seem like a good idea, so MinimServer doesn't allow multiple tag values with the same index value and different sort values.

In your case, the sort values are so close together ('2009-09-16 10:36:30' and '2009-09-16 10:34:16') that this problem is unlikely to arise. However, the sort values are different, so MinimServer produces a warning to tell you about it.
Find all posts by this user
Quote this message in a reply
04-09-2017, 10:14
Post: #4
RE: MinimServer Conflicting Values in Filter Warning
(03-09-2017 20:52)simoncn Wrote:  The short answer is that you need to change EncodingTime.yearMonth.index to EncodingTime.yearMonth.index.sort. To understand why, read on....

Suppose your library contains albums tagged with a mixture of the following:

COMPOSER=Johann Sebastian Bach
COMPOSER=Bach, J.S

You decide that you want to see all these in your composer index as J.S. Bach, so you configure MinimServer to set all the index values to J.S. Bach. Because this doesn't change the sort values, you would get index entries for J.S. Bach in both the B and J sections of the Composer index. The J.S. Bach entry in the B section would contain everything tagged COMPOSER=Bach, J.S and the J.S. Bach entry in the J section would contain contain everything tagged COMPOSER=Johann Sebastian Bach.

This doesn't seem like a good idea, so MinimServer doesn't allow multiple tag values with the same index value and different sort values.

In your case, the sort values are so close together ('2009-09-16 10:36:30' and '2009-09-16 10:34:16') that this problem is unlikely to arise. However, the sort values are different, so MinimServer produces a warning to tell you about it.

Simon,

Wonderful! Detailed response in what seemed like minutes... on a Sunday! I've been using MinimServer for some years but only now do I feel I understand the difference between .sort and .index (in other applications I tend to think of indexing as sorting, I guess). So this has been invaluable, such a basic concept to finally grasp…

The reason I sought help on the warnings above was due to weird behaviour I was getting at my control point after creating some Groups in various albums and changing some Minimserver properties at the same time. I thought the warnings may have been another symptom of the one problem. Getting to these newly-created Groups by first selecting Month Added (ENCODINGTIME alias) at the first screen, then Composer, etc. brought up a Group I couldn't "get into.", though tapping it said "3 tracks added" (Naim app). Nothing actually happened. Getting to this Group via another route (say Composer first), worked as expected. Anyway, I suspect now that this was a caching problem and it was solved by a restart. Which brings me to the next point: how does Rescan in MinimWatch actually work? I notice sometimes that a rescan is quick, as if incremental, when what is needed is a complete rescan of the whole library (to fix problems such as that above). Is Restart the action needed for the latter?

As always, many, many thanks for your wonderful product, support and engagement. Your product is the icing on the cake.
Find all posts by this user
Quote this message in a reply
04-09-2017, 11:48
Post: #5
RE: MinimServer Conflicting Values in Filter Warning
Thanks very much for your kind words.

A rescan is a complete scan of the library with the assistance of a cache file created during the previous scan. For each library file, if the length and modification date match the values stored in the cache for this file, the file is not scanned but the required data is taken from the cache instead. In all other cases (including where there is no cache entry for the library file), the library file is scanned.

A restart uses the cached values for all files without looking at the library files. It is useful when you have changed MinimServer property settings but have not modified the library files.

It can occasionally happen that the cached information is wrong. This would only happen if you have modified a library file but the length and modification date for the file have not changed. Some tagging programs have a setting to do this. If you suspect that this might have happened, you can set the startupScan property to 'full' and do a rescan (not restart). This ignores the contents of the cache and rereads everything from the library files. Remember to reset the startupScan property after doing this.
Find all posts by this user
Quote this message in a reply
04-09-2017, 14:33
Post: #6
RE: MinimServer Conflicting Values in Filter Warning
Yay! Thank you; that's very useful information.
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)