v3.0.13.5 - stable

This forum will contain general news and announcements made by radio42.
Post Reply
User avatar
hdradio
Posts: 625
Joined: 10 Apr 2012 17:36
Location: Crete, Hellas
Re: v3.0.13.5 - stable

Post by hdradio »

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.
User avatar
hdradio
Posts: 625
Joined: 10 Apr 2012 17:36
Location: Crete, Hellas
Re: v3.0.13.5 - stable

Post by hdradio »

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.
Are you sure that if I disable the history check the resulting playlist won't have many duplicate entries?
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.
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.
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.
That's why I said that will be checked by default.
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.
Then two options AddToHistory and CheckHistory is the simplest way.
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.
User avatar
radio42
Site Admin
Posts: 8295
Joined: 05 Apr 2012 16:26
Location: Hamburg, Germany
Contact:
v3.0.13.5 - stable

Post by radio42 »

Version 3.0.13.5 is out!

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.
User avatar
radio42
Site Admin
Posts: 8295
Joined: 05 Apr 2012 16:26
Location: Hamburg, Germany
Contact:
Re: v3.0.13.5 - stable

Post by radio42 »

I think that 'UseLastTrackOnFinalFail' should be line specific and not script global.
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.
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.
CheckScriptLog and AddToScriptLog visible only if Script Max History > 0. Otherwise have no sense showing them).
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...
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 ;-)
User avatar
radio42
Site Admin
Posts: 8295
Joined: 05 Apr 2012 16:26
Location: Hamburg, Germany
Contact:
Re: v3.0.13.5 - stable

Post by radio42 »

WoW - that was my 1.000th post ;-)
User avatar
hdradio
Posts: 625
Joined: 10 Apr 2012 17:36
Location: Crete, Hellas
Re: v3.0.13.5 - stable

Post by hdradio »

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 ?
User avatar
radio42
Site Admin
Posts: 8295
Joined: 05 Apr 2012 16:26
Location: Hamburg, Germany
Contact:
Re: v3.0.13.5 - stable

Post by radio42 »

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.
User avatar
radio42
Site Admin
Posts: 8295
Joined: 05 Apr 2012 16:26
Location: Hamburg, Germany
Contact:
Re: v3.0.13.5 - stable

Post by radio42 »

Are you sure that if I disable the history check the resulting playlist won't have many duplicate entries?
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!
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...
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 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!
to 2nd: once your lib grows you might want to change the rule - sure, then you can (re)enable the history check

Post Reply