v3.0.13.5 - stable
Re: v3.0.13.5 - stable
I think that UseLastTrackOnFinalFail should be line specific and not script global.
Because if you have many lines with different filters, some lines might be important to return tracks and some other not so important and can be skipped.
Also if we need to check only script or only global log what option to set ?
I think it would be more simple to use for each line:
CheckScriptLog
CheckGlobalLog
AddToScriptLog
AddToGlobalLog
All checked by default. (CheckScriptLog and AddToScriptLog visible only if Script Max History > 0. Otherwise have no sense showing them).
Edit:
Now I am thinking that only
CheckScriptLog
CheckGlobalLog and
AddToGlobalLog are needed:
Also have no sense to check for script log if AddToScriptLog is not enabled.
So if CheckScriptLog is checked then AddToScriptLog is assumed.
Edit2:
After thinking a lot more about it, I believe that having those 4 options cover all scenarios.
Even both CheckScriptLog and AddToScriptLog needed.
Because a next line might need info about what the previous line has found even if previous had CheckScriptLog unchecked.
Because if you have many lines with different filters, some lines might be important to return tracks and some other not so important and can be skipped.
Also if we need to check only script or only global log what option to set ?
I think it would be more simple to use for each line:
CheckScriptLog
CheckGlobalLog
AddToScriptLog
AddToGlobalLog
All checked by default. (CheckScriptLog and AddToScriptLog visible only if Script Max History > 0. Otherwise have no sense showing them).
Edit:
Now I am thinking that only
CheckScriptLog
CheckGlobalLog and
AddToGlobalLog are needed:
Also have no sense to check for script log if AddToScriptLog is not enabled.
So if CheckScriptLog is checked then AddToScriptLog is assumed.
Edit2:
After thinking a lot more about it, I believe that having those 4 options cover all scenarios.
Even both CheckScriptLog and AddToScriptLog needed.
Because a next line might need info about what the previous line has found even if previous had CheckScriptLog unchecked.
Re: v3.0.13.5 - stable
Are you sure that if I disable the history check the resulting playlist won't have many duplicate entries?If that is the case, you can simply disable the history check at all, as it wouldn't make any difference to the result, if you finally want to use it anyhow.
1st because of possible duplicates in resulting playlistExample: Your history is set to 200 entries but your filter returns 50 possible tracks - after checking them all and finding out, that all are contained in the history, you want to use the last found track anyhow? Why not simply disable the history check at all for such a script-line? It would result in exactly the same.
2nd because the library I am filtering might be under construction. Today has 50 tracks but tomorrow might have 400 tracks.
That's why I said that will be checked by default.all your scripts(-lines) now do not use the history (as you have been unable to check it) and as such must all be edited.
Then two options AddToHistory and CheckHistory is the simplest way.Actually there was never a separate option to choose between using and/or adding to the global and/or script history. If consistent you would also need the same for the media lib history - making it a total of 6 options...not sure, if that is really needed.
Will add to Script, Global and Lib history and check all of them.
My opinion is that you have to use very simple words for options that anyone can understand.
I see that you have many customers all around the world. Me too I do not speak English well.
The word supress wasn't in the list of my known words and I had to find the meaning
(I find it in my dictionary suppress - I even now don't know what is the correct one)
If someones sees ForceScriptHistory what will understand ?
Read ? Write ?
ForceScriptHistory can be just UseScriptHistory. (why to use force here ?)
SupressHistory can be a simple unchecked CheckHistory.
But as you 've already said, it's basically a matter of taste.
I hope I am not the only one commenting here. I 'd like to listen to other user's opinion.
v3.0.13.5 - stable
Version 3.0.13.5 is out!
What's New?
Script Processing-Logic streamlined
The use of script-line (as well as FixTimeElement) options has been unified and is now consistent.
In previous versions certain options have simply been suppressed by certain modes (e.g. the 'Execute' script mode was so far never evaluating the 'SupressHistoryCheck' or 'SupressAddHistory' options, as so far this mode actually never checked the history or added entries).
This has now be changed to give a consistent behavior across all script-lines! In the past there has been a lot of confusion about history checks, when a script-line is been skipped or not etc.
So I hope, that the new processing logic is more easy to understand...unfortunately this means, that the logic has somehow been changed if necessary.
Here is the new behavior:
1) ALL script-lines now effectively check the (script and global) history for any resulting track!
This unless the 'SupressHistoryCheck' option is set, which suppresses the history check.
2) ALL script-lines now effectively add its resulting tracks to the (script and global) history!
This unless the 'SupressAddHistory' option is set, which suppresses the history check.
3) The 'ForceLibraryHistoryCheck' option has a new meaning:
It now ONLY enables media- resp. cartwall library checks, even if the 'SupressHistoryCheck' option is set.
It no longer defines, if a script-line is finally skipped or not!
This option only applies to the modes 'Random', 'Sequential' and 'Cartwall' !
4) New global Script Option 'UseLastTrackOnFinalFail' added ('Random', 'Sequential', 'Cartwall' only):
By default a script-line is now skipped, if all found tracks finally fail the (script and global) history check.
This is more consistent, as a script-line would also fail, if for example a media library wouldn't return any tracks at all (no matter because of a defined Filer-Rule being to strict or because of a failed media library history check).
Enable this (global script!) option if you instead want to use the last found track - meaning such a script-line might finally violate the (script and global) history, but ensures, that the script-line is not skipped. So far the 'ForceLibraryHistoryCheck' option was somehow used to define this behavior - which no one really understood I guess.
Summary:
'UseLastTrackOnFinalFail' option NOT set (default):
- all script-lines are always skipped if no tracks are retuned by that line or all tracks violate the history (if history checking is enabled)
'UseLastTrackOnFinalFail' option set:
- a 'Random', 'Sequential' or 'Cartwall' script-line is finally not skipped in case tracks are retuned by that line and history checking is enabled
- however, if no tracks are retuned by that line this line is anyhow skipped (this might also be the case, if a media lib history is used)!
5) No more 'File-Exists' checks:
So far a 'does this file physically exist' check was carried out - unfortunately not for all modes/script-lines - resulting in some confusion.
As such, these checks have been removed entirely! This means, that theoretically a track might be now be scheduled to a playlist even if it does physically exist.
This might be because your media libs are out-of-sync or you e.g. specified a 'LoadTrack' or 'LoadPlaylist' script-line which uses references to 'dead file links'.
Anyhow, do not worry, as the playlist resp. the DJ Players itself checks the physical existence of a file and might simply skip those playlist entries.
I hope, that this is much more in line of what you expect the several options are doing and is much more consistent!
However, some scripts might need to be checked again and might need some adjustments!
E.g. the 'Execute' script-line mode so far was never checking the (script and global) history nor adding the result to it - now it does.
So make sure to adjust the 'SupressHistoryCheck' or 'SupressAddHistory' accordingly.
What's New?
- Script Processing-Logic streamlined
- Filters rules bug-fix
- SHOUTcast v2 album art support bug-fix
- Various smaller optimizations
- Other smaller bug-fixes
- stable
Script Processing-Logic streamlined
The use of script-line (as well as FixTimeElement) options has been unified and is now consistent.
In previous versions certain options have simply been suppressed by certain modes (e.g. the 'Execute' script mode was so far never evaluating the 'SupressHistoryCheck' or 'SupressAddHistory' options, as so far this mode actually never checked the history or added entries).
This has now be changed to give a consistent behavior across all script-lines! In the past there has been a lot of confusion about history checks, when a script-line is been skipped or not etc.
So I hope, that the new processing logic is more easy to understand...unfortunately this means, that the logic has somehow been changed if necessary.
Here is the new behavior:
1) ALL script-lines now effectively check the (script and global) history for any resulting track!
This unless the 'SupressHistoryCheck' option is set, which suppresses the history check.
2) ALL script-lines now effectively add its resulting tracks to the (script and global) history!
This unless the 'SupressAddHistory' option is set, which suppresses the history check.
3) The 'ForceLibraryHistoryCheck' option has a new meaning:
It now ONLY enables media- resp. cartwall library checks, even if the 'SupressHistoryCheck' option is set.
It no longer defines, if a script-line is finally skipped or not!
This option only applies to the modes 'Random', 'Sequential' and 'Cartwall' !
4) New global Script Option 'UseLastTrackOnFinalFail' added ('Random', 'Sequential', 'Cartwall' only):
By default a script-line is now skipped, if all found tracks finally fail the (script and global) history check.
This is more consistent, as a script-line would also fail, if for example a media library wouldn't return any tracks at all (no matter because of a defined Filer-Rule being to strict or because of a failed media library history check).
Enable this (global script!) option if you instead want to use the last found track - meaning such a script-line might finally violate the (script and global) history, but ensures, that the script-line is not skipped. So far the 'ForceLibraryHistoryCheck' option was somehow used to define this behavior - which no one really understood I guess.
Summary:
'UseLastTrackOnFinalFail' option NOT set (default):
- all script-lines are always skipped if no tracks are retuned by that line or all tracks violate the history (if history checking is enabled)
'UseLastTrackOnFinalFail' option set:
- a 'Random', 'Sequential' or 'Cartwall' script-line is finally not skipped in case tracks are retuned by that line and history checking is enabled
- however, if no tracks are retuned by that line this line is anyhow skipped (this might also be the case, if a media lib history is used)!
5) No more 'File-Exists' checks:
So far a 'does this file physically exist' check was carried out - unfortunately not for all modes/script-lines - resulting in some confusion.
As such, these checks have been removed entirely! This means, that theoretically a track might be now be scheduled to a playlist even if it does physically exist.
This might be because your media libs are out-of-sync or you e.g. specified a 'LoadTrack' or 'LoadPlaylist' script-line which uses references to 'dead file links'.
Anyhow, do not worry, as the playlist resp. the DJ Players itself checks the physical existence of a file and might simply skip those playlist entries.
I hope, that this is much more in line of what you expect the several options are doing and is much more consistent!
However, some scripts might need to be checked again and might need some adjustments!
E.g. the 'Execute' script-line mode so far was never checking the (script and global) history nor adding the result to it - now it does.
So make sure to adjust the 'SupressHistoryCheck' or 'SupressAddHistory' accordingly.
Bernd - radio42
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
Re: v3.0.13.5 - stable
I guess that this option is anyhow only rarely needed, if at all being honest - as the scenario is rather only happening when your lib resp. filter returns so few entries and all of these entries are effectively present in the history. If that is the case, you can simply disable the history check at all, as it wouldn't make any difference to the result, if you finally want to use it anyhow.I think that 'UseLastTrackOnFinalFail' should be line specific and not script global.
Example: Your history is set to 200 entries but your filter returns 50 possible tracks - after checking them all and finding out, that all are contained in the history, you want to use the last found track anyhow? Why not simply disable the history check at all for such a script-line? It would result in exactly the same.
So I was even thinking of removing that option at all...that's why I moved it to script level.
I am not really sure about this, since sometimes people are actually copying scripts and/or changing histories...it might be dangerous to hide fields in the first place (making it impossible to set them)...and later on you would have to revalidate all your scripts. This is also the reason, why I called them 'Supress...' - as the default is actually to perform the check... so it leads to less config errors...CheckScriptLog and AddToScriptLog visible only if Script Max History > 0. Otherwise have no sense showing them).
In your case - the following might happen:
- you started with Max. History = 0; as such the fields would be hidden (making it impossible to select them)
- then you change Max. History and set it to something > 0
-> all your scripts(-lines) now do not use the history (as you have been unable to check it) and as such must all be edited.
But - sure - its an option, and is basically a matter of taste?!
Actually there was never a separate option to choose between using and/or adding to the global and/or script history. If consistent you would also need the same for the media lib history - making it a total of 6 options...not sure, if that is really needed.
Maybe just one option : "ForceScriptHistory" - which would enable the check and the adding from/to the script history in case SupressHistory was selected - that would basically work the same as for the existing "ForceLibraryHistoryCheck" option?!
You wanted things simple...now you adds even many more options
Bernd - radio42
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
Re: v3.0.13.5 - stable
WoW - that was my 1.000th post
Bernd - radio42
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
Re: v3.0.13.5 - stable
Maybe I am missing something here.
If a script line chooses random songs from a lib and do NOT check history is there a possibility to query the same track back to back ?
I suppose yes because it does NOT check any history.
Am I right ?
If a script line chooses random songs from a lib and do NOT check history is there a possibility to query the same track back to back ?
I suppose yes because it does NOT check any history.
Am I right ?
Re: v3.0.13.5 - stable
Of course, you are absolutely right.
I am just talking about the 'UseLastTrackOnFinalFail' option. And saying, that with this option turned on, the same track could also be played back to back.
I am just talking about the 'UseLastTrackOnFinalFail' option. And saying, that with this option turned on, the same track could also be played back to back.
Bernd - radio42
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
Re: v3.0.13.5 - stable
Yes, in that very particular case. When ALL of these (filtered) tracks fail the history check, but a final test will use that last tested track anyhow - then you already/also have as a result with a duplicate entry!Are you sure that if I disable the history check the resulting playlist won't have many duplicate entries?
See it that way: Assume you have created a dedicated media lib (instead of using a filter on a larger media lib; as that is in logically the same) - if this media lib is quite small (containing less entries than your history count) you might have a chance, that ALL entries of that lib fail your global/script history check!
If you now want to define, that this lib is so important, that in ANY case you want to pick a track of it (even as the last resort, if really all tracks fails the match)...then you can directly disable the history check for it...as picking the last tried track is basically the same as directly picking a random track in the beginning
This is by the way the ONLY reason (I can imagine) why you want to use a media lib history...
to 1st: if you do not want to skip that line, but use the last tested track - that also violates the check and results in a duplicate!1st because of possible duplicates in resulting playlist
2nd because the library I am filtering might be under construction. Today has 50 tracks but tomorrow might have 400 tracks.
to 2nd: once your lib grows you might want to change the rule - sure, then you can (re)enable the history check
Bernd - radio42
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution
ProppFrexx ONAIR - The Playout and Broadcast Automation Solution