ProppFrexx ONAIR User-Forum

It updated ok now.
But now results are messed up:
I have in two different folders the same file but with different year and rating.
I look for it in PF Find dialog.
It finds the 2 files which is ok.
Then with windows explorer I go to folder 1 and I delete one of them.
I find again in PF.
Now it finds again those 2 files !!!! but one has changed it's name !!!.
I double click on it and (of cource) it can not play it because it does not exist.
Loot at the screenshot.
https://www.dropbox.com/s/36nez1i9dndfh ... _26_04.jpg
Note that the 1st song had the same name as the second before my deletion.

Did you also update the MLS? Or only PFOA?
Note, that you also need to update the MLS!

What about the other scenarios you posted before?! (changing TAGs in existing files - are these working?)

This seems to be something different to test and as such might also have a different result...I need to investigate what now happened.
In order to do that I need to know your exact folders structure and how all your libs are configured.
- Are all libs folder-based libs?
- Has it been two physical files or are we talking about any logical links?
- Are all Libs pointing to mutual exclusive folders (not that LIB-A points to "C:\Music" and LIB-B points to "C:\Music\Sub")?
- what lib have you configured on your MLS?
- what lib have you configured on your PFOA machine?

As in your picture I see, that you are searching in 'All' local PFOA libs; may be you have still somewhere another remote lib configured and even a parallel local folder media lib pointing to the same folder as the MLS...and as such you have accidentally configured a folder twice? And/or did not set both folders to AutoWatch...


Making a quick test here I again can NOT reproduce that issue.
In my example I used 2 libs on the MLS:
1. C:\Folder1
2. C:\Folder2
I then copied various files to both folders. Finally I copied the same source file 'test.mp3' over to both folders. Then I TAGed both these files differently.
I started PFOA and configured 2 remote libs one pointing to MLS-C:\Folder1 the 2nd pointing to C:\Folder2.
I did a search in the Find window using 'test'...which returned me 2 entries as expected.
Now I went to C:\Folder1 and deleted its test.mp3 file and waited 2 seconds (I even took a look to the MLS tab moved my mouse over and that now showed me the reduced number of tracks in that one lib).
I did a search again in the Find window using 'test'...which this time returned me 1 entry only - as expected.

And, how quickly did you do the test?
Note, that the file is deleted immediately; but the MLS might take 2 seconds to remove it from its lib...

One more note/question: have you unchecked the following 2 settings in the MLS (as suggested previously)?
- 'Use UNS Paths'
- 'Use Absolute Paths'
Please uncheck these to boxes and make a complete Rescan then...
Then try again!

Use UNC paths is unchecked
Use Absolute Paths is unchecked
I 've updated PFOA and MLS
Libs are folder based libs.
It has been two physical files.
I have only 2 libraries that point to different folders.

?what lib have you configured on your MLS?
I don't understand your question.
In MLS I have cofigured "M:\OnAir\Ελληνικά" named "Ελληνικά"
Ιn PFOA I have only configured remote media libraries and have selected "Ελληνικά"

I let some delay before checking again. Even waited half an hour.

You say you have defined 2 libs, but then you list only one.

What I mean is:
a) you define libs within the MLS
b) you define your libs within PFOA

So have you configured 2 libs in both a) and b). Or have you configured only one lib in a) and one in b) ?

Sorry for the misunderstanding.
I 've defined 2 libraries:
"M:\OnAir\Ελληνικά" named "Ελληνικά"
and
"M:\OnAir\Ξένα" named "Ξένα".

Then on PFOA I have defined to use the remote libraries "Ελληνικά" and "Ξένα".

OKi I see....

I can actually reproduce your issue, IF I have enabled the 'Use UNC Path' option in the MLS, as the AutoWatcher currently seems to have some issues with handling UNC paths.
When the 'Use UNC Path' option is enabled, the _synced.pfp file would contain UNC path/filenames for the tracks...and in such case (when deleting files) it couldn't correctly find those in your media libs, as the AutoWatcher always works on non-UNC (local) paths...

However, if the 'Use UNC Path' option is unchecked, the _synced_.pfp files should NOT contain any UNC paths anymore...and the AutoWatcher should work fine!
This is at least what I can find and reproduce...

So do you mind checking the content of your _synced_.pfp files, if it still contains UNC paths.
If, you might stop the MLS, simply delete the _synced_.pfp files - and restart it...to be fully re-created...
Then it should / must work...

Bernd I think we 've found the issue.
I think that the problem was that in previous version MLS was using UNC paths and had saved _synced_.pfp using UNC paths.
I deleted _synced_.pfp files and rescanned the libraries.
Now I delete a file and I can not find it in Find Dialog as expected.
I also changed the tag of a file and it correctly updated the result.

I did the above test on my backup pc.

Now my backup pc is playing on air to update the main OnAir pc.

On my OnAir pc I deleted _synced_.pfp files and run MLS.
A strange here is that while it found about 110000 tracks in my 2 libraries, it shows 220000 tags to read.
It's still reading....
I 'll wait to finish and see what is wrong.

Maybe you initiated the reload/rescan twice?
The TAG Reading is a simple queue...new TAG reading requests are just added to the end of the queue...

radio42 wrote:Maybe you initiated the reload/rescan twice?
The TAG Reading is a simple queue...new TAG reading requests are just added to the end of the queue...

No because I closed MLS, I deleted _synced_.pfp files and then run MLS again letting it to do it's job. I didn't click anything.
Anyway...
It finished tag reading on my on air pc and the size of _synced_.pfp is the same to my backup pc. So I guess there is no problem.
I hope everything is working smoothly now because I am leaving for holidays.
I won't change anything from now on until I come back.
Thank you Bernd for the support.