[amasephy]

Hello - I identified an issue with the latest version of Kodi while using the official iOS Kodi Remote app. I reached out to that developer on this thread and it was confirmed on their end but apparently the root of the problem is a change in the JSON implementation for Kodi 19?

The issue is when playback is paused via the iOS app, the videos progress bar does not appear on the tv screen. When using a physical remote such as my Xbox controller to pause, the progress bar is displayed.

Prior to using Kodi 19 the iOS app did not have any difference from using a physical remote.

Was this a deliberate change to disable the viewing of the progress bar when using an app to control Kodi or an unintentional regression?

[DaVu]

I noticed this yesterday as well (using Yatse and/or Kore) and we already talked internally about that. Seems there's some bug in Kodi 19. Maybe we are able to fix it. Not too sure tbh

edit:
Ok...so we dug deeper. The seekbar overlay you are missing to see was introduced in Kodi 19. It wasn't present on Kodi 18 and that had another implementation of showing a paused video. I also replied on the other thread that one could also consider using {"jsonrpc":"2.0","method":"Input.ExecuteAction","params":{"action":"playpause"},"id":0} instead of Player.PlayPause method which, at least for me, works like a charm.

[Buschel]

@DaVu , thanks for the details. In general I would expect that Kodi handles PlayPause the same -- whether this comes via "Input.ExecuteAction", "Player.PlayPause" or even hitting "Space" on the keyboard. If Apps using JSON need to change this, I am asking myself if also the other commands (e.g. seek, skip, stop) should be done via "Input.ExecuteAction" and  "Player.x" commands should be abandoned.

Would be good, if a developer can comment on this.

[DaVu]

I can just share what a team member said: 

"root cause of this is not skin related nor the play/pause implementation, it's the System.IdleTimer(5) usage. When triggering json requests related to controls the global idle timer is not reset
...

"another option is just to use Input.ExecuteAction from JSON that one resets the timer"

Player.x commands shouldn't be abandoned. In that case, if an action relies on a control (showing the seekbar), it might probably be better to use something different. 

TBH, I don't get what that "System.IdleTimer()" does or not or why it's necessary for it to be "resetted". I'm just sharing my experiences and it makes some sense for me to use an "input"-method which sends an "action" if a user wants to execute an action on the application. 

But we can also wait for a dev to explain more.

[DaVu]

Code wise it's just a difference that the "Player.PlayPause"-method is missing this:

https://github.com/xbmc/xbmc/blob/master...ns.cpp#L41

Which resets the System.IdleTimer. But I'm not too sure if it's a good pattern to extend the "Player.PlayPause"-method with that if an input-method could the better way.

[enen92]

@DaVu , thanks for the details. In general I would expect that Kodi handles PlayPause the same -- whether this comes via "Input.ExecuteAction", "Player.PlayPause" or even hitting "Space" on the keyboard. If Apps using JSON need to change this, I am asking myself if also the other commands (e.g. seek, skip, stop) should be done via "Input.ExecuteAction" and  "Player.x" commands should be abandoned.

Would be good, if a developer can comment on this.

I think it comes down to the fact the Player json methods are not Input methods - they affect the Player state only. Personally I think this is right, json methods should have headless in mind, avoid dependencies on GUI, input, etc.
The estuary top seekbar depends on the idle timer, that's intrinsically linked to input. Still, kodi json-rpc has "raw" input method support via `Input.ExecuteAction`. For json based remotes to mimic the physical remote behaviour, those methods should be used instead of the player state methods. It's not only the idletimer that's affected, the GUI sound of keypresses are also not executed if not triggered via Input.
The only point I have doubts is in a (far far) distant future when and if Kodi is able to run headless. Will input methods make sense in that scenario? Regardless, too far to a realistic possibility so I'd say the best and safest option for the near future is to use Input via json.

TLDR: I still don't think there's anything to fix on the kodi core side, it comes down to the json clients of Kodi to choose the appropriate methods to execute.

[Buschel]

Thanks for the detailed response. So this is per design and intended. I need to think through how to deal with this from the App side.

[enen92]

Thanks for the detailed response. So this is per design and intended. I need to think through how to deal with this from the App side.

I will think a bit more about this and likely dedicate a bit of time to it so please try to avoid wasting time implementing things that could be reverted later.

IMHO we can also see this from a different angle: incorrect usage of systemidle timer (input related) in visible condition of that window on the default skin. Unfortunately skins don't have any other way to do it. But...what if skins could define and make use of custom timers (restricted to the skin scope)?
The impact of this issue likely does not justify the implementation, but I can see the resource improving the skinning engine on the long run (and replace similar use cases that are currently solved with python and the overhead it brings).

[enen92]

@Buschel cc https://github.com/xbmc/xbmc/pull/20816

[Buschel]

Thanks for sharing. Looking forward to see this merged.

[enen92]

above PR merged and backported to matrix, thread marked solved.

[DaVu]

Awesome

Thanks

[amasephy]

Thank you to everyone involved in resolving this issue!

[amasephy]

With the release of 19.4 on Xbox I was finally able to test this fix.

Unfortunately I am a bit surprised and disappointed by the new behavior. Yes, the progress bar is displayed when using the app (json) button now, but the progress bar disappears after a few seconds still.

Worse, the progress bar exhibits the same behavior when using physical remotes now - seemingly a regression.

Before this fix was implemented if you used a physical remote the progress bar stayed visible until the playback was unpaused. I’m almost certain this is the way it always was in Kodi prior to 19.x.