Make Smart Blocks capable of filtering by relative dates about libretime HOT 14 CLOSED

@korotkov13 I think you can partially achieve this with the "Last Played" criteria:

from libretime.

As a prerequisite, it really appears that depending on the data type of the field selected for the Select criteria's data type, the Select modifier and value fields should be context sensitive since some of the options may not make sense for all data types. In addition, the value field could display the appropriate help icon "i" and a template in the fill-in to aid the user what can be entered.

So when a user selects a date-based field such as Last Played, specific date and time-based selection criteria would be activated that would provide user input helps and validation.

For entering relative dates and times, using the ISO 8601 standard (number 4 - durations) could be a good way to go as it provides a simple way to enter a time duration. However, as mentioned previously by @Robbt, it could be helpful to use multiple selectors to simplify entering the days, hours, minutes and seconds, etc. but the end result would still be an ISO 8601 duration. For instance, the time selector in Scheduled Shows could be borrowed and repurposed to support days in addition to time.

Here are some observations regarding the ISO 8601 durations that could be applied here:

• Moment.js can parse ISO 8601 durations as well as a simple format.
• PHP can handle an ISO 8601 duration with the DateInterval() class.
• PHP supports subtracting a DateInterval instance from a DateTime instance converting to a new absolute date which can then be passed to query the date range.
• PostgreSQL supports relative date and time calculations but in an incompatible manner.

The time duration must be stored in the Smart Block and not applied until the Smart Block is used which is different for Static and Dynamic versions. At the appropriate time, the duration would be subtracted from the current date-time to get an absolute time in the past which would be used to query the database.

from libretime.

Ok, so I've been pondering this again and it isn't simple because there are at least 4 files that need to be modified and a number of modifications needed to create the new processing.
So from a data-processing side of things it looks like 8.5.4. Interval Input on https://www.postgresql.org/docs/8.4/static/datatype-datetime.html says that it can support ISO 8601 with a special format.

So the interval for most purposes would be -"time unit" to Now. I have a hard time imagining any of our dates being realistically set in the future at this point unless there is an issue with the clock.

The next question is how to modify the UI. I had the idea that it might make sense to separate date/time filtering into its own search criteria section just as the Limit section is. I don't think this would be too challenging and existing criteria involving the dates would be moved into the new form section.

Otherwise I think I need to do something similar to the Extra field that is used when a numeric interval is shown and invent a new field that is shown and hidden that involves the selection of a date time.

Now I think it would work simply by adding new options to the modifier for the date fields. Such as relative dates before & between and then modifying the input text field area to include a select field that lists time intervals and add an ago to the end. This seems less user friendly than separating the functionality but doing the same thing.

from libretime.

I want to offer one more option in smart blocks.
Add to sort tracks point: rarely played.

I understand that you need statistics from the database for the playback of tracks and put a priority in the formation of a playlist in a smart block to those tracks that have played for a long time.

from libretime.

Oh my! Thanks! @hairmare
it could be used.
I think it would be great if you could add a modifier not only a specific date and time, but for example it was not played within the last 2 days, or 120 minutes.

from libretime.

So I'm looking into how to approach this and I thought I'd take notes here so I can check them later and anyone else can chime in.

Right now the smart block criteria is stored either as a string or a number and so it filters the date column to only be a numeric date this is in the SmartBlockCriteria.php file I believe. Whereas I filterByDbMtime in BaseCcBlockQuery.php might already take relative date strings (if properly formatted.)

from libretime.

Ok, so I think that if we just change the validation on this form to accept PHP relative time formats formats in addition to actual dates it will work with the propel ORM. The question now is there a library or code already written to validate these I find it hard that there isn't something off the shelf but my research thus far hasn't found anything.

from libretime.

It looks like there is moment.js but it's possible we could also validate them by trying to create a PHP datetime with the user entered value to validate it and just provide decent documentation as I'm not sure moment.js will store the values in the PHP datetime relative format. Within PHP and installable via composer is Moment.php but I'm not sure that it validates relative dates.

from libretime.

I think carbon has support for international relative dates but not sure if it validates and translates to the PHP compatible format.

from libretime.

I'm not sure it makes sense to expose relative time formats to the user because they are not translatable and in some edge cases (like 'first day of this year') do unexpected things.

moment.js input could certainly be validated, but I'm pretty sure it won't be relative once it hit's the server. moment.js is really more of a UI tool AFAIK. The startOf() and endOf() methods from moment.php look sensible, the rest of lib looks like a lot of not-invented-here-syndrome just to get API compatibility with some js code.

Since carbon is a piece of PHP I don't see why it needs to match to the internal format. We can just use it directly where it's features are needed.

Given the dead air Problem from #129 I'm not 100% convinced that a PHP solution is the right way to go for the autodj and this php specific relative time magick makes it even more coupled to the web-ui.

from libretime.

Ok, my thoughts on this are, it makes sense to provide the users the most amount of power that we can from the web interface. I also think that if we do use relative formats they should be somewhat limited. We are really only using them to filter SQL so most of the odd use cases probably won't come up.
I need to do more testing but if we limited the functionality to reltext term such as
'next' | 'last' | 'previous' | 'this' or yesterday. And the units months, days, seconds etc. Or we could limit it to simply math and units.
I don't think it would be too difficult to translate them back to the relative term that would sit in the database. The question is whether these relative terms all work with the database.

I think that a PHP solution or at least a web configurable one is the most user friendly in terms of allowing configuration by the end user. I know that a lot of people achieved various autoDJ functionality with liquidsoap hacks but I think that anything we create should be configurable through the web interface. So it makes sense to me to use PHP unless there is a real advantage towards doing it through python or Ocaml.

from libretime.

Also thinking about this unless we are going to replace smart blocks I think it makes sense to have a relative date function built in here even if they weren't utilized in the auto playlist. I think there are a lot of times where users will want to say only add tracks with last played greater than 2 weeks ago. Or only add tracks that have been added within the last month etc.

The real question I think, is whether we should do it via text input (benefits in that it can work without modifying the UI and can handle both numeric and relative input) or via a select box/drop down. This would make translating easier but would mean modifying the UI to handle either or.

I still want to fully test whether relative dates work with the propel datefield ORM. I think that they do based upon my limited testing. The question of whether they can be easily translated, validated and then stored in English in the database is the challenge here I think. This may be a good argument for making the UI for relative fields defined via a more clunky UI.

from libretime.

I'm leaning towards a drop down with different options that will pop up for the date field like the 2nd answer on this stackexchange question

from libretime.

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please chat to us on discourse or ask for help on our chat if you have any questions or need further assistance with this issue.

from libretime.