Search unreliable

I’m observing this problem for longer time and wondering if it is a known bug or “feature”. I’ve posted the issue in the bug tracker but there seems be no activity to resolve it. The deficiency is quite annoying as user has no feedback which results are true and which are false empty set. Even if the server returns zero results, it does not identify as HTTP error or timeout. I noticed the problem is present with the searches through the API too. Maybe if there were clues the server has temporarily failed, the search could be repeated till it returns something. Anyway is there an idea how to bypass this nuisance till the instability is fixed? (if it’s going to be fixed)

1 Like

Please paste your search here.*+TO+*%5D%29%29+AND+%28video%3Afalse%29&type=recording&limit=25&method=advanced

1 Like


What is the purpose of ‘(NOT dur:[* TO *])’ ? This seems to cause the issue, perhaps order of operations related.

It’s clear this search will return nothing: (recording:“Since You’re Home” OR alias:“Since You’re Home”) AND (arid:36a3493f-fdb2-47d1-abb7-30658572c95f) AND ((NOT dur:[* TO *])) AND (video:false)

and this search works every time: (recording:“Since You’re Home” OR alias:“Since You’re Home”) AND (arid:36a3493f-fdb2-47d1-abb7-30658572c95f) AND (dur:[140840 TO 150840]) AND (video:false)

1 Like

The (NOT dur:[* TO *]) means “or not having length set” (the expression is used also in interactive recording picker on new release form, I’ve noted the picker suffering with the same issue)

1 Like

You can try (NOT dur:/[0-9]+/) instead.