[Buschel]

(1) "No connection" after scrolling up. -> Confirmed, just fixed this. Again related to lates dequeuing changes.
(2) Different logo contrast. ->  You are right. This happens, if you scroll up several time. It is getting more contrast each time. Also related to dequeuing changes. Not fixed yet.
(3) Wrong status. -> Good to see you could reproduce this finally. I will have a look a this.

Edit: Cannot reproduce (3) here. Is there anything special, can you share a video?

[amasephy]

Nothing special. Every time I suspend the app and resume it goes into yellow connection status.

Doesn’t matter if I’m at the main menu screen or the remote screen. If I suspend the app and resume I get the same result. Interestingly I do need to swipe up on the main menu OR the right pane to “refresh” the connection status. As soon as I do this it turns yellow. The only difference is the right pane still labels the connection server name.

Here’s a video of it.

[Buschel]

Perfect, thanks. The difference is how you suspend and resume the app. I really switched to a different app or put the iPhone to sleep. You only attempt to do it, and then go back. Only in your case, the problem occurs, and I can reproduce it now as well. The code causing this is >9 years old.

The App ends TCP when receiving notification UIApplicationWillResignActiveNotification, which happens when just attempting to change the App like in your video. This is why the status icon becomes yellow. But TCP is only enabled again when receiving the notification UIApplicationWillEnterForegroundNotification, which is not sent without the App having really entered (not only attempted to enter) background. So, we should only switch off TCP if the App really enters background, which is signaled by UIApplicationDidEnterBackgroundNotification. 

Applying this change locally seems to work, but I need to understand possible side effects before moving on. @kambala, what are your thoughts?

[amasephy]

I can’t believe after over a year of testing it’s only now clear the subtle way to trigger it. Thanks for confirming and explaining. Hopefully your fix will put this annoying bug to rest once and for all.

[Buschel]

Well there are still more issues with the status icons. For example I remember it is possible to to switch off TCP on Kodi server and not see this reflected in all screens. 

Btw, a bigger problem with the issue you find is that the TCP connection is really switched off (the status icon becoming yellow is just right). After this happened you will not receive any notifications by Kodi anymore and the App can only perform updates via polling each second. You can easily see this when observing the volume bar and changing the volume in Kodi server for with another app instance.

[kambala]

Perfect, thanks. The difference is how you suspend and resume the app. I really switched to a different app or put the iPhone to sleep. You only attempt to do it, and then go back. Only in your case, the problem occurs, and I can reproduce it now as well. The code causing this is >9 years old.

The App ends TCP when receiving notification UIApplicationWillResignActiveNotification, which happens when just attempting to change the App like in your video. This is why the status icon becomes yellow. But TCP is only enabled again when receiving the notification UIApplicationWillEnterForegroundNotification, which is not sent without the App having really entered (not only attempted to enter) background. So, we should only switch off TCP if the App really enters background, which is signaled by UIApplicationDidEnterBackgroundNotification. 

Applying this change locally seems to work, but I need to understand possible side effects before moving on. @kambala, what are your thoughts?

current logic is obviously wrong. Either use WillResign+DidBecome or DidEnter+WillEnter. Note that only WillResign will occur if you receive an incoming call, not quite sure if a socket is allowed to work in inactive state (call may be long).

[Buschel]

Thanks. For now I changed it to use only use DidEnter+WillEnter. You think this will be ok for the App, or you expect problems because of the TCP connection?

[kambala]

Thanks. For now I changed it to use only use DidEnter+WillEnter. You think this will be ok for the App, or you expect problems because of the TCP connection?

should be good I think, afaik most app functions don't use the raw TCP connection but rather JSON-RPC over HTTP

[amasephy]

Hi Buschel,

Your fix probably will cover this but revealing the iOS notification pane by swiping down from the top of your phones screen triggers the same yellow connection status.

[Buschel]

Your fix probably will cover this but revealing the iOS notification pane by swiping down from the top of your phones screen triggers the same yellow connection status.

Yes, this is the same underlying problem and also will be fixed.

[Buschel]

Locally I already have some changes which should resolve the mismatching server status icons (red/yellow/green). I don't want to add this to the next version, which should be focusing on pure bugfixes (for now only the wrong server status after moving the server status out of view and the undesired disabling of TCP when entering App Switcher or Notification Center).

Let me also share two concept videos.

NowPlaying rework
- Video: https://www.dropbox.com/s/uxhj4db5mm9vck...k.mp4?dl=0
- Updated size and location of thumb and description
- More important info has bigger bold font and stronger coloration
- Add year or director
- S1E2 instead of 1x2x for episode 2 of season 1
- Smoother animation when toggling playlist and NowPlaying views

Server Status rework
- Video: https://www.dropbox.com/s/tlgkrogju94tcr...k.mp4?dl=0
- Add a server status icon to the navigation bar to show the status in each view
- Add a color bar for each server to easier differentiate (this was an idea / request from AppStore from a user with multiple servers)
- Add this color bar to the navigation bar to display the selected server on each view
- This is in a very early stage and has only dummy status and random selected colors

iPad Menu size
- Video: https://www.dropbox.com/s/79fp3pd8nnkdj2...u.mp4?dl=0
- Motivated by user comment on to small playlist field on iPads
- Limits the size of the main menu to 50% of the landscape height
- Main menu items keep scrollable
- If less then 50% is used, menu will shrink with the amount of configured main menu items
- This is a prerequisite for adding any further main menu entries like "File browsing" or "Settings"

Remote Message
- Video: https://www.dropbox.com/s/6ddlh0h0ip6jia...e.mp4?dl=0
- Use same message type / color as other app messages
- Correct size for iPhone embedded remote
- Move to center position of touch / 4-button view

Edit: Feedback, comments, ideas are welcome — as always

[amasephy]

Buschel,

I like what I’m seeing. The new flip animation is really nice. Much better than the current “shift” one. The shift animation has its place but in this context flip fits much better.


Regarding the audio and sub remote messages. I’m good with the color changes but something I had considered asking in the past is actually moving this message either both the remote in the blank space between remote top button row but below header, or have it drop the message exactly like what happens when you use the custom button execution message.

I know in the past you’ve said not all supported devices have this empty space. If you are moving the app to require newer iOS version eventually all supported devices will have this space. I’m wondering if the move you were planning already makes this a reality.

Placing it on the remote is as means your thumb covers the message up. Seems counterintuitive to me.

[Buschel]

Thanks for your feedback. I now did some quick hack to move the feedback up.
1. iPhone: https://www.dropbox.com/s/83nqwhnkhyixf6...e.mp4?dl=0
2. iPad: https://www.dropbox.com/s/8p7v7rwhpukozt...d.mp4?dl=0

[amasephy]

Looks really good. I’m wondering about the message color schemes now though. Just from a consistency point of view red banner messages seem like a bad thing elsewhere in the app but now they’re used for one of the messages here.

Might be worth using a different color here to distinguish banner message types. IE: Green for command executions, red for errors, and some other color for general messages like here.

Also, since you are looking at colorizing the servers, may I suggest you look into color blind safe colors. I personally don’t suffer from color blindness but I know a lot of apps have started to implement color blind safe colors. Just a thought.

[Buschel]

Hmm, are these really different banners? Either a command can be executed, or an error happens when attempting to use the function (e.g. „no subtitles“) or executing it. I agree, it might be better to use a green banner when the user selects to disable the subtitles. Just looks a bit weird as the action list shows a red item, and the execution would be showing green. Maybe I just do not use red color for the action item anymore. Need to think about it as there are also other places where red action list items are used.

I am even thinking of changing few other messages like the „Cannot do this.“ popup. This could also be replaced by a red error banner.

Color blind support is an interesting topic. In this case the red/green server connection status as well as the message banners would be impacted. Will search the web a bit for recommendations.