folder watch

[hdradio]

I edit the title of a song from my production pc (second pf instance).
Then I went to my on air pc and tried to find that song and I couldn't with the new name.
I thought that it would be updated as I have set MLS to auto watch folder.
When I clicked "Rescan" it worked as expected.
(When "Rescan" finished, the balloon showed also that MLS found my other 350 changes I did yesterday).
Am I missing something here ?

[radio42]

I need to test with those tools (MusicBee and/or MP3Tag) what they exactly do...
So far I was testing (as explained) with PF-Tagger and there I do not get this behavior.
That was the reason, why I asked what tools you are using, as with PF-Tagger I can not reproduce the issue.
Maybe they do not touch/change the file's modification date properly...I don't know and need to double-check...

So just to be sure (for your test case): You are only changing/saving TAG data but do NOT rename a file or folder?!

In the next MLS version I think that you have to add a LED indication like PF lower left, so I can tell if changes are triggered or not.

That is already there (but as a text info) on the 1st tab (TCP Server). In the upper 'Server' group (onto the right side) you'll see a text telling you the number of libs currently being rescanned and the number of TAGs currently being re-read.
If that text is NOIT displayed - nothing is happening anymore...

[radio42]

I need to double check this, but if the media lib is set to AutoWatch, if should actually work as you explained it...

[hdradio]

Yes Auto watch is enabled.
I have mapped the shared folder (example \\OnAir\Audio) to M:
Then I 've added M: as library to MLS.
I don't know if mapped drives do no trigger the change notification.

[radio42]

Mapped drives should also work fine - at least here!

Can you explain your detailed steps how you tested things, so that I might be able to reproduce it...
How do you edit you tracks (with PFOA, with the Tagger, with an extra tool)?
Do you change the TAG data inside the audio file or meta data file?
How do you validate, that the MLS does not properly re-read changed TAG data?
E.g. are you using exactly the steps I explained above...or are you testing things differently?

[hdradio]

Strange! I did a test here and it works as you describe.
I don't know what was wrong.
Maybe because I did a mass change on more than 100 files at once.
I 'll have my mind on it and keep you informed.

I 've noticed now, that in find window even if I uncheck "Search also in filenames" it continues to result files that have the search text in filename.

[radio42]

The AutoWatch feature is an OS system feature I am using and the docs say, that there is a slight change in case of mass changes, that some changes might not be captured.
Normally a certain error handler is invoked which I am catching, to trigger a re-scan by self.
So I'll also further check any mass changes again, maybe the error handler is not invoked and I need to find another way to determine lost change notifications...

And yes, currently the remote media lib always also searches in filenames on the MLS. I'll see if I can pass that info from the PFOA client to the MLS somehow...

[radio42]

I just tested the scenario here, but the AutoWatch feature was working as expected.
E.g.:
- I edited the TAGs of a file with the ProppFrexx Tagger (i.e. I changed the Artist name to something funky).
- That in turn triggered the 'AutoWatch' feature of the MLS, which re-read the TAGs respectively.
- I then went to PFOA and used the Find window to search on that remote media lib for that new, funky Artist name; and that was found immediately

How are you testing things?
And are you really sure, that the AutoWatch feature is enabled on the media lib on the MLS!?
E.g. double-click on the related media-lib in the MLS to edit its settings and see, if 'AutoWatch' is effectively enabled...

[hdradio]

I checked in the morning but my modifications were the previous night.

When I click rescan on MLS after a minute a balloon shows :
Recan completed for /LibraryName in 0h:01m:08s
Entries Checked 50336 (0 dead)
TAGs (re)read: 76 triggered.

What does it mean ?
Does it mean that have to read 76 tags ?
If auto watch was working those 76 tags should be read automatically on file change.
Or this balloon has some other meaning ?

[radio42]

When rescan says, that it needs to read 76 TAGs, that means, that the file modification date of 76 files is 'younger' that the date when the TAGs have been last read in for it.
ProppFrexx and the MLS keep a date and timestamp for each media entry when the TAG data was last read in.
If the AutoWatch feature is notified about a file change, it will trigger a re-read of the TAG data. If successful that date will be advanced.

So there are 2 theoretical possibilities (as I still do not know exactly how you change you files as asked in my previous posts):
a) the AutoWatch feature did not receive a change notification
b) the file's last modification date was changed afterwards by some process (after the AutoWatch feature triggered the TAG re-reading)

To me b) seems very unlikely.
But you might validate it, if you follow my steps above.
If a Find/Search on the MLS using the newly provided TAG data is successful on a remote media lib - then the AutoWatch feature works okay and the newly TAG data has been read in correctly and as such only b) might be the case.

However in my Tests here (scenario and steps as explained above) the AutoWatch feature was working correctly and as such a Rescan always reported "TAGs (re)read: 0 triggered."