Server Version#: Beta 1.40.2.8395 Player Version#: Web 4.125.1 (Firefox v. 125.0.3) OS: Windows 10 Enterprise x64 - 22H2 - 19045.4291
Example: Movies released in the year and a half
Error: filtering by release date, using decimals of time scales creates "unexpected error"
(This likely isn’t just a beta issue but that’s what version I use. Yes I know there is also release date - is after/before as an option but, using decimals in this case should still work)
Steps:
Go to the library tab of your Movie/TV show library
Search the library using advanced filters using these parameters for a rule group;
Release Date - is in the last - 1.5 - Years
(This also works when using either is in the last or is not in the last as well as any of the time increments. The amount of time does not matter either, as long as it has a decimal.)
Have you considered using, for example, is in the last 18 months? The error should definitely be handled a bit more gracefully than it is currently (likely they should just perform field validation to only allow whole numbers), but in my opinion it’s perfectly reasonable to express 1.5 years as 18 months. Or 2.5 years as 30 months.
In file com.plexapp.system.log, you have (at least) 2 criticals :
2024-05-09 21:27:30,671 (5174) : CRITICAL (runtime:709) - Private handlers are no longer supported; couldn’t register <bound method StreamService.token_handler of <StreamService object at 0x00000000045bf490>>
2024-05-09 21:27:30,673 (5174) : DEBUG (runtime:1150) - Scheduled a timed thread named ‘invalidation_timer’
2024-05-09 21:27:30,673 (4ed8) : DEBUG (runtime:1117) - Created a thread named ‘ensure_agent_info_exists_inner’
2024-05-09 21:27:30,674 (1da8) : ERROR (networking:197) - Error opening URL ‘http://127.0.0.1:32400/servers’
2024-05-09 21:27:30,674 (5174) : DEBUG (logkit:13) - Starting the proxy service
2024-05-09 21:27:30,676 (4ed8) : DEBUG (runtime:1117) - Created a thread named ‘ensure_agent_info_exists_inner’
2024-05-09 21:27:30,677 (1da8) : CRITICAL (core:574) - Exception in thread named ‘refresh_servers’ (most recent call last):
The first one is a runtime related, but the second one is CORE related… what is CORE is up to PLEX TEAM TO SOLVE… and is related to some Python routines.
Regaring the decimals, have you tried with a coma instead ? (with Windows … the most stupid idea is generrally the good one)
I do not know how Plex stamps it’s time… but it can be that since you have 365 days in one year and 366 every four year… one can state that 1.5yr = 365+0.5*365 wich ends up with a non entire number… which can lead to an internal server error a bit like dividing per zero
As a human, I do understand 1.5 yr … does the machine too? If Plex did not implement an exhaustive way to understand how humans can talk about a time… then it end’s up in a very cumbersome situation.
