Script line filter rule violation
Script line filter rule violation
I have set a script line to play from a library with a filter (RatingValue >= 80).
Today I noticed that a song was chosen that had rating 60.
Does it mean that it couldn't find a song and broke that rule ?
Is there any indication, log file note, or a way to find if that was the case ?
Today I noticed that a song was chosen that had rating 60.
Does it mean that it couldn't find a song and broke that rule ?
Is there any indication, log file note, or a way to find if that was the case ?
Re: Script line filter rule violation
Yes, that might be the case.
See here for details: viewtopic.php?f=9&t=675
If ProppFrexx can not find a track, which matches the Filter and/or matches the history...the only thing ProppFrexx can do is to either 'break' that rule and take a track anyhow (which is the default) OR skip that line. In order to change the default behavior and Skip the script-line the 'ForceLibraryHistoryCheck' option must be enabled.
However, there is currently no log which might explain this.
See here for details: viewtopic.php?f=9&t=675
If ProppFrexx can not find a track, which matches the Filter and/or matches the history...the only thing ProppFrexx can do is to either 'break' that rule and take a track anyhow (which is the default) OR skip that line. In order to change the default behavior and Skip the script-line the 'ForceLibraryHistoryCheck' option must be enabled.
However, there is currently no log which might explain this.
Bernd - radio42
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
Re: Script line filter rule violation
What I read in that post is that :See here for details: viewtopic.php?f=9&t=675
if the "Global Song History" check can never be satisfied for a certain script-line, this currently returns the last found track anyway.
If that is true (and I am not wrong), a track from that filter should return, even if that track had some time ago.
So in my script, a track with RatingValue>=80 should have been returned and not a track with rating=60.
It would be good to have logged this information about broken rules so we can fix the script lines that don't satisfy that rule. Otherwise we have to monitor our broadcast 24/7.
Re: Script line filter rule violation
All script line options are "None"However, if your script-line filter would for sure return matching tracks AND you do NOT have set any media library history AND you have not set the "ForceLibraryHistoryCheck" option - and as such your script-line is for sure not skipped, then you are correct, that this could/should never happen.
So I can only assume, that in your case the script-line might have been skipped?
This line is for sure not skipped because it returned a track.
The previous and next script lines have tracks from some other genre so I could understand the difference.
Re: Script line filter rule violation
Unfortunately I don't have screenshot of the playlist, but I have a rating column added. So I saw that a song with rating 60 was selected.
Re: Script line filter rule violation
Yes I updated that tag the previous day. Was 80 and I did it 60.
I am using Media Library Server and have set Auto watch to true.
Do I also have to refresh the library ?
How do you explain that the playlist entry was showing rating 60 ?
I am using Media Library Server and have set Auto watch to true.
Do I also have to refresh the library ?
How do you explain that the playlist entry was showing rating 60 ?
Re: Script line filter rule violation
Okay, that might explain things...
Is the media library on the MLS a playlist- or folder-based lib?
Note, that if it is a playlist-based media lib, the AutoWatch feature would monitor the playlist file itself, but not all tracks contained in that playlist!
In that case you must rescan the lib.
If it is a folder-based media lib, the AutoWatch should however actually automatically re-read the TAGs...(else it would be a bug)
...do you have access to the remote files or are they probably 'transferred' to your local machine?
Please check this under general settings, section 'Folders/Libraries' by clicking on the 'Remote Library Settings...' button.
If 'Allow Remote Data Access' is enabled and the gien TEMP folder does contain audio files from the remote MLS, those files have currently being cached.
The playlist always refreshes the TAG data it displays with the most recent data - meaning it re-reads the TAG data when it!
Is the media library on the MLS a playlist- or folder-based lib?
Note, that if it is a playlist-based media lib, the AutoWatch feature would monitor the playlist file itself, but not all tracks contained in that playlist!
In that case you must rescan the lib.
If it is a folder-based media lib, the AutoWatch should however actually automatically re-read the TAGs...(else it would be a bug)
...do you have access to the remote files or are they probably 'transferred' to your local machine?
Please check this under general settings, section 'Folders/Libraries' by clicking on the 'Remote Library Settings...' button.
If 'Allow Remote Data Access' is enabled and the gien TEMP folder does contain audio files from the remote MLS, those files have currently being cached.
The playlist always refreshes the TAG data it displays with the most recent data - meaning it re-reads the TAG data when it!
Bernd - radio42
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
Re: Script line filter rule violation
It's a folder-based media lib.
Yes I have access to the remote files.
All other options are the default. (Allow remote data access = checked)
Yes I have access to the remote files.
All other options are the default. (Allow remote data access = checked)
Re: Script line filter rule violation
I hope I have found the small existing 'hole' with the AutoWatch feature and the Media-Library-Server and the Filter Rule - check v3.0.13.3.
I was actually 'caching' the last Filter-Result for a media library on a MLS (for better performance) and forgot to reset that cache in case of an automatically detected file change (AutoWatch).
I was actually 'caching' the last Filter-Result for a media library on a MLS (for better performance) and forgot to reset that cache in case of an automatically detected file change (AutoWatch).
Bernd - radio42
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
Re: Script line filter rule violation
No, that is not fully correct - as a script-line might still be skipped.
Another user just almost had the same question, see here:
viewtopic.php?f=9&t=970
viewtopic.php?f=9&t=977
In short:
Even if you don't use the "ForceLibraryHistoryCheck" script-line option, your script-line may still be skipped, if
a) the script-line filter wouldn't return any resulting tracks
b) a media library history check fails
However, if your script-line filter would for sure return matching tracks AND you do NOT have set any media library history AND you have not set the "ForceLibraryHistoryCheck" option - and as such your script-line is for sure not skipped, then you are correct, that this could/should never happen.
So I can only assume, that in your case the script-line might have been skipped?
You might check this by looking at the 'SourceInfo' column within the playlist - which should reveal so more info.
However, I am also preparing an extra Debug-Log file for the next version which might be temp. enabled to log some more extra info.
Another user just almost had the same question, see here:
viewtopic.php?f=9&t=970
viewtopic.php?f=9&t=977
In short:
Even if you don't use the "ForceLibraryHistoryCheck" script-line option, your script-line may still be skipped, if
a) the script-line filter wouldn't return any resulting tracks
b) a media library history check fails
However, if your script-line filter would for sure return matching tracks AND you do NOT have set any media library history AND you have not set the "ForceLibraryHistoryCheck" option - and as such your script-line is for sure not skipped, then you are correct, that this could/should never happen.
So I can only assume, that in your case the script-line might have been skipped?
You might check this by looking at the 'SourceInfo' column within the playlist - which should reveal so more info.
However, I am also preparing an extra Debug-Log file for the next version which might be temp. enabled to log some more extra info.
Bernd - radio42
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution