[UlfSchmidt]

I totally agree with both edits of @amasephy , but I fear in order to change these issues, Kodi itself needs to be updated, not just the remote.

Especially the topic with the volume control, but this is only the tip of an iceberg, since there is currently in the App always everywhere everything enabled, whether it is actually possible to use or not makes simply no difference. A nightmare user experience. Another good example for this is the power off menu providing so many options not working on most systems. If I remember it correctly, I started a discussion about this also some time ago already, but there is no way for the App to know in advance what will do and what will fail.

[Buschel]

I can confirm same “unknown label” issue is in 19.3 as well. As you say it only appears to be an issue when using the “widgets” on the main screen of Estuary. When adding the movies from within the Movies subcategory on Kodi server there is no issue.

Thanks for checking this. Seem I used another instance of the Remote App when testing this on my side under 19.3. I will create an issue report for Kodi in the next days. Maybe this can be fixed for Kodi 20.
Edit: JSON issue PlayList.GetItems

As for the playlist not being updated, it’s really perplexing me. Now it works fine on my Xbox but it doesn’t update while using Windows. I’ve confirmed tcp is working. I simply can’t explain it.

I will try to test this with my son's setup. Could be missing notifications coming from Kodi.

Let’s say you queue up some content. The playlist has let’s say 3 items.
Now if you use the remote and play something that is not on the playlist it will discard the queued items. Would it not be better to insert this to the top of the current playlist?

There was an issue raised on the same use case, but with a different ask: Instead of deleting the old queue without any notice just raise a popup, if you are ok to delete the current queue or not (issue #84). In fact, the current behaviour exactly matches Kodi's. I think the remote should not deviate from what Kodi does. Or at least as default it should behave same.

Is there a way for the app to detect when passthough is enabled and disable the volume control on the app since it doesn’t actually do anything?

I am not convinced the remote should handle it, imho it will be better to block this in Kodi itself. Obviously it is already handled for other remotes, it should be also blocked for JSON API volume changes.

[kambala]

Really I am just spending a few minutes looking for edge case issues to help improve the app. As I am not a skilled programmer the most help I can be is writing up detailed bug reports. I guess it’s my way of paying back the efforts of people like Buschel. I hope they don’t come across as a nuisance though. 🙂

you're doing a great job, thanks a lot!

you should work as a tester / QA in IT company

[UlfSchmidt]

Really I am just spending a few minutes looking for edge case issues to help improve the app. As I am not a skilled programmer the most help I can be is writing up detailed bug reports. I guess it’s my way of paying back the efforts of people like Buschel. I hope they don’t come across as a nuisance though. 🙂

you're doing a great job, thanks a lot!

you should work as a tester / QA in IT company

Exactly what I was thinking

[Buschel]

@amasephy, I can only support the previous comments. Please continue with your reports and especially the detailed reproduction steps. This helps improving the App and the user experience. I am just reminding the huge step the swipe-behavior made after you brought up some observations.

[amasephy]

Thank you all for the kind words and encouragement!  Very nice to wake up to today.

Buschel,

I defer to your judgement on my comments/observations from last night.  Passthrough probably should be handled by Kodi server.  I also did not realize how playlists worked on Kodi server.  Thank you for indicating you'll write up a ticket for the JSON get list issue.  You better understand what is going on there.  Sadly regarding my JSON issue I haven't gotten a single response on the new pause behavior.  I hope this new issue gets some attention and resolution.

With regards to the pane swiping I have found a new issue regarding it.  I had felt there was something occasionally triggering this but never could reproduce until now.  It seems to be an issue throughout the app.  I almost think its new but can't be certain.  Maybe you can verify in older releases.

Bug: Swipe back inconsistency.

Reproduce:

Go to Movies category.
Tap quick remote icon.
Swipe back from left edge of screen.
You should be seeing the list of Movies again.
Go back to the quick remote.
Now swipe back to movies but from the center of the screen.
You are back to the main menu!

You can trigger this anytime you are two panes deep.  I first noticed it in the add server menu while editing server settings.


Bug: Edit button not grayed out

On the now playing menu go to the playlist queue view.

When the playlist is empty the "Edit" button text in the lower right corner is still white indicating it can be pressed.  I think this should be deactivated (gray) if the list is empty to keep visually consistent with other things that are grayed out when they can't be used.  For example, the right settings pane the edit button is grayed out until custom buttons are added.

[Buschel]

Bug: Swipe back inconsistency.

How cool is that.
Not sure if this is really a bug, or a feature. As you rightly mentioned this happens when you are at least two panes deep (e.g. "Artist" > "Genesis" or "Genre" > "Pop" > "We Can't Dance"). Swiping from left border will only move back by 1 pane. Swiping from middle pulls the whole stack (e.g. Music). Entering the remote from a submenu / stack is like going 1 pane deeper.

Bug: Edit button not grayed out

Confirmed, this is a possible improvement, but not really high priority. The same happens when having no server in the server list. I will check for other places as well.

[amasephy]

I was also thinking this panning could actually be considered a feature.  I don't think its really hurting anything, but figured it should be pointed out.

[Buschel]

I also was not aware. There's still some hidden places...

[amasephy]

Here's a swipe back bug.

Apologies in advance, you have to navigate kind of deep to trigger it.

Reproduce:

Right hand Settings pane.
Tap more.
Tap System -> Display -> Display mode.

You should see Full screen with a check on the right.

Now swipe back to the left a little bit, but not enough to actually trigger a swipe back.

You will see a pull-down animation that I believe should not happen.

Now navigate to System -> Audio -> Stereo upmix.
Perform the same swipe back test. 

It will pull down but won't pull down all of the way leaving the top of the "form contents" (using Windows lingo here) off screen.  I suspect the pull down animation is hard-coded to a value.  Also its strange there is even a pull-down animation happening here.  When you first view this form no such animation occurs.

[Buschel]

@amasephy
The list should not be fully shown if the chosen setting (the one with the mark on the right side) is around the middle of the list, and the list itself is higher than the available space to show it. Reason is that the list is configured to show the marked item in the middle of the screen. The list is vertically moved in a way to achieve this. I can see this when using a simulator for an older iPhone or iPod Touch with a smaller display and use the setting "System > Audio > Stereo up mix  > 5.1".
The animation itself can be switched off. But it should only be switched off when falling back from a swipe-attempt. Otherwise the list does not animate smoothly to the chosen element but just jumps when opening the list the first time. This just does not look right. Maybe you can try with the Audio setting and see how it animates to scroll to the selected item.

[amasephy]

Buschel I am not sure how you are triggering the scroll selected item to center of screen.

Let me share a video of what I am experiencing.

Please note a few additional observations. The first section in the video showcases a category that can’t be fully read. The title of the category is too long.

Also note the bottom tap and hold block doesn’t fill the bottom of the screen and you can see list items beneath that box. Very nit picky but you can decide whether it needs to be addressed or not. The rest of the video shows the animations I observe.

[Buschel]

Ok, I was obviously on the wrong path looking at the problem. Thanks again for sharing this detail which looks like the layout and insets are not handled correctly.

[amasephy]

Buschel I do not know how we all missed this after months of studying app behavior but how come the TV shows subcategory doesn’t have an index when “Sort By” is alphabetical? Proof that it’s a bug is that the index appears when you set it to reverse alphabetical!

Edit:
Something else that I noticed I think might be able to be improved. If you use the search bar and type anything in. If the list is long and you scroll to the bottom you can’t view the bottom entries. I think once you type some search term in and start scrolling the keyboard should disappear while retaining the search term filter. This is how iOS handles it. Take a look at the “App Library” pane on the far right of iOS. You tap in search, the index appears, you type something and scroll and keyboard disappears gracefully.

[Buschel]

The missing index is most possibly not a bug. And I remember we already discussed this before when I explained about how the App uses the index. Rule is: Do not use an index when you are in default sort-method and -order AND less than 100 items are in the list. For >=100 items the index is always shown. Debatable, but this is how it was even before I started to work on the App.

The other suggestion on the keyboard is an interesting one.

Btw, in the meanwhile I could solve the top-down animation when snapping back from a swipe in the Kodi settings menu, as well as the wrong inset (content moving up into the navigation bar). I am still struggling with some other glitches, but we have time.

Edit: The keyboard dismissal was simple. Already done, but will most likely not go into the 1.10.1, but into a later version.