[amasephy]

Using 8th gen iPad and iOS 17.

[Buschel]

Also no issue with the iPad 8G iOS 17 simulator.

[amasephy]

Here’s the video.

[Buschel]

@amasephy, in your video it is quite obvious, but I am really not seeing anything like this. This does only happen since the very last build and not with any of the other TF build before? This would help me narrowing down the changes which might influence such behavior. 

@UlfSchmidt, do you see anything like this on your iPad?

[amasephy]

It gets even more bizarre. I’ll start out by saying these findings are consistently reproducible.

Going back through all available TF builds here’s where jitter happens and doesn’t happen…

Happens
4657
4691.43
4768
4835

Doesn’t happen
4691
4691.42
4798
4798.42


Edit: Btw I’ve also noticed that exiting search bar is slower in the global search panel. Either by pressing cancel or sliding the view. It’s more obvious when pressing cancel though. It’s instant in the movie library view but delayed maybe 1 second in global search. Not a new issue as far as I can tell.

[Buschel]

I cannot match this to any change as it seems to be erratic over the different builds. I also tested on my wife's iPad (Air 5G, iOs 17.3.1) without seeing this issue. I am clueless.

[amasephy]

Yeah really bizarre how different builds affect it. Too bad no obvious cause.


Going back to old builds really highlighted how slow the old connection process was. Again, cannot offer enough praise for this improvement.

[Buschel]

Going back to old builds really highlighted how slow the old connection process was. Again, cannot offer enough praise for this improvement.

Absolutely. I faced the same today while going back to old builds to test something. Usability definitely improved.

As a sidenote: You mentioned that you sometimes see the App starting fresh (would now show the toast message) instead of just waking up after you did put it to sleep. This could be just iOS terminating the App in the background due to "system pressure",  e.g. when iOS needs RAM. You can reduce the probability on iPad by just closing the stack before putting the app to sleep. On iPhone just leave it in NowPlaying. Since few weeks I see that AppStore reports a lot more such "system pressure" terminations. Either more users with memory-intense use cases, or Apple made a change in iOS.

[amasephy]

I’m not too bothered by it relaunching. I see it a lot with other apps even on my 15 pro which has tons of ram. I think Apple is a bit aggressive with this but they aren’t asking me. 🙂

Related to the app I see a lot of scenarios where it does not default back to remote screen upon resuming a connection. Most obvious is if I suspend the app and shutdown Kodi server then restart Kodi server without waking the app up until after server is up and running. In this scenario the app appears to have no idea the server was ever shutdown.

[Buschel]

In this scenario the app appears to have no idea the server was ever shutdown.

Exactly. The App is asleep and does not see the server was down for a while. In your use case it is probably best to put the app asleep when on remote screen.

[Buschel]

@amasephy, while working on restoring some other function (blue frame around selected item in grid view) I reviewed the fullscreen grid view layout. I also saw some erratic label position changes when comparing screenshots, but still I could not see any "live" problem. I now did a small change which sets the cells' dimensions without fractions but with maximum possible resolution as supported by display. I also removed some vertical autoresizing of the label and made it fix located with fix height under each thumbnail. Let's see, if this helps. Only downside of this (and the other changes in this area) are that the image cache needs to be rebuilt as the thumb sizes change by a small amount.

[amasephy]

Ok fingers crossed this works.

Btw, when trying to reproduce you are tapping in the search box, right? I’m assuming you are as that’s the only way to reveal the cancel button.

[Buschel]

Yes, that what I tried.

[amasephy]

While I wait for next TF with possible fix, I just tested the jitter thing in the music library. Here something weirder happens. It rotates which labels jitter in 4 different cycles. Here’s music. TV does something different as well.

I wonder if it has to do with truncating labels.


Edit: I figured it out. You need to be in grid view for the non fullscreen library to trigger the issue. If you’re in list view the problem does not manifest. Also, if you initialize the library view in list view and change to grid view there is still no problem. When you toggle between the views you must reinitalize the library view by tapping on the main menu item to toggle jitter behavior.

Edit 2: Further confirmation, the reason certain previous builds worked is because for some reason the builds that worked defaulted to list view while the builds that didn’t work defaulted to grid view upon fresh installs from the test flight app.

[Buschel]

Yes, now I can also see this. To make it quick: iOS layout issue. The cell sizes in collection view (aka grid view) are just changing for some of the cells. I suspect this comes from fractions of dimensions still being left when laying out the whole view, e.g. N item and N+1 spaces need to add up to the whole view width. Currently the space width is fix, the item width is calculated (and then rounded). But this needs a bit more time today to understand this in more depth. That this moves over different cells is most likely just an effect of cell-reuse.

With my code change the labels stay where they were, but the thumb size is slightly changing. Need to think through this a little more.

Edit: Should work with my latest change now.