JSON RPC error breaks Apps' search functionality

[fischcode]

This bug appears to affect many if not all Kodi apps with a search function: when the text entry prompt for the search string opens in Kodi, the Kodi remote app for iOS correctly shows a text entry field but at the same time displays a
XBMC JSON-RPC Error: Invalid params.
(Code: -32602)
Data: (null)
METHOD
Files.GetDirectory
and fails to return the search string to the app. Sometimes the first attempt works, but all subsequent searches fail consistently.
This greatly reduces the functionality of apps such as YouTube which rely on a search function.

[wutschel]

Can you share a detailed use case (preferably not via YouTube), and also share which Kodi and Remote App version this happens with? Was this working before and with which versions?

[wutschel]

Thanks for sharing. The debug output shows "rties" instead of "properties". Cannot tell, if this is the reason for the error though. Can only look into this in a few days.

[fischcode]

I am sorry, but I had to withdraw my first list of steps as it turns out that the fault is much different from what I thought: I use kodi on libreelec mostly headless (using kodi remote instead) and thus didn't realize what was going on on the screen.
Eventually it appears that the following steps are required to reproduce the fault:

• Start kodi with no app open
• Use kodi remote to open an app such as ARTE.TV app (1.1.3+matrix by LORE, realvito) used in the example below) and navigate to the Search function: The search mask opens on the kodi screen
• Tap the back (<) button in kodi remote: The search mask stays open on the kodi screen
• Navigate again to the Search function: The following error appears in kodi remote:
  XBMC JSON-RPC Error: Invalid params.
  (Code: -32602)
  Data: (null)
  METHOD
  Files.GetDirectory
  PARAMETERS
  {directory="plugin://plugin.video.tyl0re.arte/?mode=SearchARTE&url=00";media=video;properties=(thumbnail);sort={ignorearticle=0;method=none;order=ascending;};}

While the cause of the fault is quite obvious when using kodi with a screen attached, it can be quite a nuisance when using kodi headlessly and interacting with it only through kodi remote. Unfortunately, only a few apps close the search screen on the second attempt leading to the fault (in which case a third attempt will work again) while others will leave the search screen open with the effect that search in kodi remote only works again after a restart of kodi...

The same fault can be reproduced using both kodi 21.0-BETA1 (20.90.801) on Windows and kodi 20.1 on libreelec in combination with kodi remote v1.14 (4229) using not only ARTE.TV but also a number of other apps such as YouTube from the standard kodi library or ZDF mediathek from the standard kodi library.
From what I know now, I don't think kodi remote ever behaved differently in such a scenario.

Now I hope this is clear enough to reproduce the issue and hopefully find a solution for it.

[kambala-decapitator]

@fischcode would it be possible for you to test the same scenario using other remotes? E.g. Kore (android) or some other from Appstore

[fischcode]

As a first test, I used Chorus (I know, not an actual remote): Chorus also leaves the search dialog open on the Kodi screen, but eventually pops up a dialog
'60 seconds ago, an input dialog opened in Kodi and it is still open! To prevent a mainframe implosion, you should probably give me some text. I don't really care what it is at this point, why not be creative? Do you have a word of the day? I won't tell...'
By entering some text, the search dialog on the kodi screen is closed and the search executed.
I'll let you know about Kore as soon as I find the family's Android tablet...

[fischcode]

While still looking for my Android tablet I tried iOS 'Music Remote Pro for Kodi' (a very nice app with an appealing hierarchical UI): When canceling a search, the search mask on the kodi screen is closed and at the same time a notice "Error loading data (Kodi server message 'Invalid params.') is shown. As the search mask on the kodi screen has been closed, the process can be repeated .

[wutschel]

I tried to reproduce (Kodi 19.5 with ORF or Youtube Add-on or Kodi 20.2 with ORF Add-on, Kodi on Linux) but I am not able to. It seems I am still missing some relevant part.

[wutschel]

Ok, got there now as well. It seems that sending Input.SendText with text: "" (empty string) just does not close the Keyboard on Kodi side. Sending text: " " (= Space), seems to work without causing this issue. But I am not sure, if this behaves the same for other Kodi versions...

[wutschel]

Better is possibly to align Kodi and App behaviour. E.g. only close the App's Keyboard when at least 1 character will be sent.

[fischcode]

In my opinion it should be possible to cancel a search dialog without any adverse side effects and Kore shows that it is possible to implement a user friendly solution for this.

[wutschel]

Installed Kore on one of my Android devices. This sends "kore_dummy_input" (which is also added to the search history) when the search is canceled. This does not happen when just sending an empty string. Will later today try to trace what exactly is sent to Kodi in the latter case. For sure I can also add "remote_dummy_input", which I already tested and can confirm working.

[wutschel]

Best solution I can come up with is to send "Input.Back" to Kodi, if the search is aborted or empty string is sent. This force closes the keyboard on Kodi side. In consequence an error is received via JSON API. This I can filter and ignore to avoid a debug message popup and simply show "no results found". This does not add "dummy_input" search history items.

Code: https://github.com/wutschel/Official-Kodi-Remote-iOS/tree/rework_keyboard

[wutschel]

This really puzzles me. I tested again with Kore and traced the JSON RPC commands sent to Kodi. Kore sends "text":"" when sending an empty string and sends "text":"kore_dummy_input" when canceling the input. I am now following Kore by sending "text":"", but sending "Input.Back" to close the keyboard on Kodi side when canceling on the App, e.g. via pressing "<" (Back).
As the JSON API throws the debug message (first post in this issue) when sending "text":"" or when canceling, I am simply ignoring this in the case in-addon search. This behaves as intended and feels natural to use now.