folder watch

[hdradio]

I change my files using :
1st : musicbee
2nd : mp3tag and
3rd (not very often) mediamonkey.

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.

I just did the following test:
In PF I find the song "bla bla"
I see that is has rating 80 and I need to change it.
I open musicbee on my production pc, find this song and update to lower rating (changed also the genre).
I then go to OnAir instance.
I find again song "bla bla"
I see in result that shows rating 80 and a sec later it becomes 5 (which is normal because I changed that).
Then I go to MLS and click rescan.
As I expected the balloon showed me that 1 file needed to reread it's tag !

[hdradio]

Bernd don't bother testing those tools.
I tried PF Meta data editor and the result is exactly the same.

In fact it's worst !
While I have changed rating to 0 (it was 5), when I click enter to find that song, it finds it, it shows rating 5 and after a second it becomes 0.
I think that's because the internal tag read function of the find window reads the correct tag.
But MLS returns the previous value even if I have clicked rescan finding 1 file to reread it's tag !
PF Meta data shows rating 0. The same shows mp3tag.

[radio42]

?How could it be worst - as in my tests it works perfectly?
Before you also posted: "...Strange! I did a test here and it works as you describe...." - which means the AutoWatch feature was/is to some extend working!

The Find Window (result) once displayed re-reads the TAG data from the physical file again!
This is by design and wanted this way (as it purely comes from a remote lib) - which means (if it first displays 5 and then becomes 0): the effective find still uses the old value (the MLS returned a rating value of 5) - which means the AutoWatch is NOT notified for you file change!
So nothing is worst! It is the same as you posted originally - nothing new, nothing worst!

So to whatever reason, it simply proves that on your machine the AutoWatch notification is sometimes NOT working - which I am trying to investigate, why it seems to work in some case and for some others not!

[hdradio]

I say worst because in my previous test, at least when I clicked rescan, the values returned in find window were the same to a sec later when the internal tag scan triggered.

Some more info that might help you find the issue:
The track I am finding exists also in another folder.
For example :
\Album\Artist - title.mp3
\Compilation\Artist - title.mp3
Both have the same tag except the rating (one has 0 because I don't want it to be chosen by my scripts).

[radio42]

I did some further tests here, e.g. doing a mass change on 500 tracks...but that also worked out as expected.
Or could it be, that you just tested (searched for the new data) too quickly?
For example saving the TAG data to 100 tracks and re-reading those TAG data back in might take some time...?

[radio42]

Do both exist in the same lib or in different lib?
Are you search in both libs or only in one?
And note, that 2 physical files mean 2 different media entries!

[hdradio]

They are on the same library. And I search in All libraries.

[radio42]

Please try the new v3.0.14.3.

I still couldn't reproduce it here. But the only logical chance I see is that in your case the change notification (within the AutoWatch feature) comes earlier then the effective physical file change and as such the MLS tries to read the file which still contains some old values.
As such I have now deferred/delayed the TAG re-reading a bit...(actually by 1 sec. to give the system some time .
I hope this heals your issue.

[hdradio]

I updated to v3.0.14.3
PF does not even start now.
I open task manager to check if it really runs and I see PF for a few seconds and then disappears.

Restoring v3.0.14.2

[radio42]

Must have been a ZIP or FTP error.
I just re-zipped it and freshly uploaded it and now here it works...