[Buschel]

Thanks for testing. I don‘t think the minimal stutter you describe is new, but simply caused by the fact that rounded edges needs some more processing time. I can look into further optimization, but first I wanted to get back to the status before sdwebimage 3.8.3. Is this reached from your experience (related to both stutter and resolution)?

[amasephy]

Yes I just finished testing the iPad. It works great there. And the slow loading I complained about with movie details (related to my high resolution images) doesn’t seem to be a problem anymore either! So resolution issue is resolved entirely for me!


So I was testing the stutter issue again today and I discovered a plot twist.

Stutter only happens when in power saving mode. While it isn’t surprising that the cpu would be more strained in power save mode, no stutter is present in the full movie list where tons of items are visible.

Yet in the season/episode view for shows, even when there is no artwork, with rounded corners there is stutter. I don’t understand why a view with no, or only a couple of images would stutter when one with many does not.

[Buschel]

Great, sounds like all what went wrong with the sdwebimage migration is now resolved. Your observations are pretty much explainable from the current implementation. In album and episodes view (where section headers contain the album / season covers) the rounded corners are applied to the images itself, whereas most other simply change the viewport (more or a less a mask you put on top of the image). The image processing causes the stutter as images are completely redrawn each time they become visible (e.g. while scrolling). This should only have been used for the NowPlaying cover and the ShowInfo details screen (here the viewport does not have the desired aspect ratio and the images themselves need to be redrawn for "rounded edges"). I now change the episodes/album to the standard and faster viewport based solution. Thanks for challenging me on this!

[amasephy]

That makes sense. I was thinking the images were being cached but since they’re not and having to re-round the images each time is certainly not an ideal solution. Todays devices can certainly handle it but since you are supporting very old devices still I wonder how those perform.

Great to see these kinds things being worked on and 3rd party libraries successfully updated. While invisible to the end user, it’s satisfying knowing that the app is being made more robust and future proof with these changes.

If you really want to challenge yourself, may I suggest you revisit the collapsing and expanding season/episode view? It really does some wonky things. Especially if you expand and collapse out of order, it just feels so janky. I personally feel it would benefit from a refined experience. 🙂

[Buschel]

If you really want to challenge yourself, may I suggest you revisit the collapsing and expanding season/episode view? It really does some wonky things. Especially if you expand and collapse out of order, it just feels so janky. I personally feel it would benefit from a refined experience. 🙂

The change to let the expanding episode fade in from its middle instead of scrolling in from top is a good step towards this. I shared a video earlier, but it looks better in real life. The problem with "hopping" when a new expanded season reaches the safe area I have no clue. Could also be a problem with iOS. I see some other layout issues from time to time ... Anything else you specifically have in mind?

[amasephy]

I have a few ideas.

When you expand multiple seasons I really think the header for the most recently expanded season should be pushed to the top of the view. Currently it only pushed up a few notches displaying two episodes. One would think of you are expanding a season you are interested in viewing as much of that season right from the start. I also believe this would avoid that distracting expand from the top animation.

Secondly, if you have multiple seasons expanded and you collapse from the bottom it always brings you back to season one. I think it would be a lot nicer if it brought you to the next preceding season that is expanded, sliding that seasons header to the top of the view as described in the first suggestion.


Even if you expand a season when the preceding seasons are collapsed and have a season below it expanded, the season header you expand will slide down revealing less episodes than if it simply stayed put.

[Buschel]

Thanks, need to think about this and play around a bit. I am not a regular user of this menu. The current implementation tries to scroll the unfolded episodes into view. All other scrolling is handled by iOS. Of course this can be change to e.g. only having one season expanded (collapsing others when expanding a new one) and then move the section header to top. It is just about what makes best sense from the use case.

Btw, this has nothing to do with this "scrolling in from top" issue, which is just an animation setting.

[UlfSchmidt]

While I couldn't contribute anything to the last topic of discussion (stuttering due to rounded corners), now it gets interesting for me again:

I would really like to see only one series unfolded and completely visible, as just proposed by @Buschel as I think that this would give the best user experience. The current implementation, as described perfectly by @amasephy ("I have a few ideas"), fails during many regular use cases. And if it is iOS causing all this trouble, maybe Buschel's suggestion would be the best. At least it sounds to me that it could be implemented easily and also would massively improve the behavior of the App in this use case.

[amasephy]

Only having one season able to be expanded is another good idea I can get behind.

I’d still like it to slide the season header to the top upon expansion to make as many episodes visible as possible.

[Buschel]

I worked on this a bit and found the "1 season only" solution not so great. This also does not solve the inset and jumpy animation problem in some cases that I face and which seem to be related to iOS handling of safe areas. But this is not critical at all. Now sections headers of newly expanded seasons are moved up to show the maximum amount of episodes possible. Collapsing seasons after will keep the headers at the same place. It is also possible to have with and without animation for the episodes fading in/out. Few impressions can be seen with the following videos:

With animation: https://www.dropbox.com/s/m30dspysi4meya...4.mp4?dl=0
Without animation: https://www.dropbox.com/s/dqv4u305p29dy1...7.mp4?dl=0

[amasephy]

Is there a possible third hybrid option? Here’s what I like. The “with animation” has a nice unfolding appearance and appears less jumpy. But, I don’t like the briefly visible black background. it’s more visible when collapsing the seasons. I find that distracting. The black background is not visible in the “without animation” version. If you can make it unfold nicely and not have the black background visible I think that would be the best presentation.

Edit: I had to look before I could confirm but I think my complaint really only applies to light mode. I think with dark mode the dark background would be expected as it matches the episode list items background.

[Buschel]

True, you see the app‘s background shortly. This background always has the same dark grey, which makes it less visible when using the app in dark mode. I will try, if other animation styles make this possibly less recognizable.

Btw, I also prefer the animated version. It is giving a smoother UI experience.

Edit: I played around with different animation methods and styles, but the temporary visibility of the background (this definitely more prominent when collapsing a season) is same. The only way to avoid this is to use a different way which does not animate at all. But this is not desired from two points of view: first, the animated version really feels smoother to use. Second, the non-animated approach requires the whole screen content to be recreated fresh (including reading and scaling thumbs ...) instead of only fasting in/out the season's episode.

[UlfSchmidt]

Btw, I also prefer the animated version. It is giving a smoother UI experience.

From the videos I would also prefer the animated version. I hope, it works then similarly on iPads?

[Buschel]

From the videos I would also prefer the animated version. I hope, it works then similarly on iPads?

It does. 👍

[amasephy]

Hi Buschel,

I have a new bug to report. Has to do with the new season/episode format you implemented for the Now Playing screen.

It seems the wrong season is being reported. It’s wrong on both screens but checking the list in the TV shows section shows the correct info, and revealing the Kodi server OSD indicates the correct season as well.







Edit: Now playing always shows 1x01. Show, season, episode number never changes.

Edit 2: Ok so this is weird. I went into Kodi settings and changed the syntax and now it’s updating the season/episode correctly. It seems if you don’t explicitly select one from settings then there is a bug where it just uses a default value of 1x01.