Tags sometimes not being read

You have a question or need an advice about how to do something? Ask it here!
Post Reply
Thijmen
Posts: 92
Joined: 16 Jul 2019 20:19
Tags sometimes not being read

Post by Thijmen »

Dear Bernd,

I got the following situation. In my media library, I mark songs that I absolutely do not want to play with a rating of 20. In my script, I filter out those songs.

Every now and then, a song is being played with a rating that I know is 20. However, Proppfrexx only recognises the rating after I re-read the tags (See the image).

How can I make sure that Proppfrexx reads this tag properly? The tag is by the way edited via Proppfrexx itself.

Let me know how I can provide more information.

Best regards,

Thijmen
Attachments
Rating of player A becomes 20
Rating of player A becomes 20
I press Re-read tags
I press Re-read tags
Note the rating of player A
Note the rating of player A
Thijmen
Posts: 92
Joined: 16 Jul 2019 20:19
Re: Tags sometimes not being read

Post by Thijmen »

Hereby my filter in the script library, by the way.
Attachments
Screenshot 2023-06-23 at 10.11.04.png
Screenshot 2023-06-23 at 10.11.04.png (4.19 KiB) Viewed 913 times
User avatar
radio42
Site Admin
Posts: 8350
Joined: 05 Apr 2012 16:26
Location: Hamburg, Germany
Contact:
Re: Tags sometimes not being read

Post by radio42 »

The question is how (and where) you edit the meta data.
Note, that PF caches all meta data into memory for fast access. Ie. They are loaded directly at startup.
It now depends from where you edit the meta data - and this is by design and purpose.

Eg. when you edit meta data directly from the media library (ie you open the media lib) or you edit the meta data from within the Find Window. That meta data is directly available in the library!
If you edit them from somewhere else (eg. a Playlist, also see below) or even in an external editor outside of PF, then you would need to reload/rescan the media library to make those changes visible.

Regardless, when you open a playlist and add tracks to that playlist, an internal copy of that track is added to the playlist. Ie. changes made later to a media lib or even that track (outside that playlist) are not immediately visible!
The is true the other way around. A change to the meta data of a track in a playlist is first only visible in that playlist only!

As I don’t know your testing scenario, where and how you changed the mata data, but I assume, that what I describe here is exactly what you experienced.

So you either need to reload/rescan your media library or your playlist track.

However, once done, and you don’t change your meta data, your script (filter) should be consistent.
There is only one exception, why a ‚wrong‘ track might be selected and this is the script option ‚UseLastTrackOnFinalFail‘. This script option (if enabled) chooses the last tested track if no other track matches the condition, as else the script-line would fail.
Thijmen
Posts: 92
Joined: 16 Jul 2019 20:19
Re: Tags sometimes not being read

Post by Thijmen »

Hi Bernd,
The question is how (and where) you edit the meta data.
Note, that PF caches all meta data into memory for fast access. Ie. They are loaded directly at startup.
It now depends from where you edit the meta data - and this is by design and purpose.
It was being edited by TCP Command EXEC_TAG_FILE.

Eg. when you edit meta data directly from the media library (ie you open the media lib) or you edit the meta data from within the Find Window. That meta data is directly available in the library!
If you edit them from somewhere else (eg. a Playlist, also see below) or even in an external editor outside of PF, then you would need to reload/rescan the media library to make those changes visible.
The strange part is, this particular file has been changed since quite some time now, and I've restarted PF several times since then.
So you either need to reload/rescan your media library or your playlist track.
I would assume so that this is also being done while restarting/starting PF.
However, once done, and you don’t change your meta data, your script (filter) should be consistent.
There is only one exception, why a ‚wrong‘ track might be selected and this is the script option ‚UseLastTrackOnFinalFail‘. This script option (if enabled) chooses the last tested track if no other track matches the condition, as else the script-line would fail.
I never used the 'UseLastTrackOnFinalFail' option.

Is there anything else I can do, to debug this issue?
User avatar
radio42
Site Admin
Posts: 8350
Joined: 05 Apr 2012 16:26
Location: Hamburg, Germany
Contact:
Re: Tags sometimes not being read

Post by radio42 »

It was being edited by TCP Command EXEC_TAG_FILE.
This method changes the meta data in a file. I.e. it doesn't modify the meta data directly in any media library of ProppFrexx.
So it behaves identical, as if you would edit the file outside of ProppFrexx ONAIR e.g. with the ProppFrexx Tagger applicaton.
I just tested it, and it works as described.
I would assume so that this is also being done while restarting/starting PF.
No, this is not the case by default! A media library is not automatically rescanned (i.e. all TAGs are re-read) when ProppFrexx OANIR is started.

But you have several options in your general settings to control this.
E.g. there is an option 'Rescan at Startup' (for folder based libs).
You can set the 'AutoWatch' option for folder based media libs (recommended).
You can automatically Reload/Rescan libraries at defined times.
etc.

But by default, changing a file outside of ProppFrexx ONAIR (like the EXEC_TAG_FILE) will not modify any media library.
A restart would also not rescan media libs.
As such, a script could not immediately evaluate the changed rating value in your case.
Thijmen
Posts: 92
Joined: 16 Jul 2019 20:19
Re: Tags sometimes not being read

Post by Thijmen »

Hmm, it seems that I had the auto reload option enabled, however I had the "Except folder libs" option enabled too! Disabled that now, I'll monitor and will look for tracks that have been played that should not have played in the future. Thanks for your exceptional explanation, Bernd!

Post Reply