[Buschel]

Thanks for the flowers
And thanks for helping figuring out such issues!

I think I now came to the core of the problem. Really nasty. Normally unique identifiers are used when processing loading attempts to differentiate the results and callbacks. The image cache did not do this and used the image's URL for this. But when two parallel load attempts of the same image was happening (e.g. one for the playlist thumb which shall be scaled down, and one for the NowPlaying which shall not be scaled) both were mixed up and the first started attempt won the race, resulting in saving the scaled down image. I now added a unique identifier like for other JSON API calls. Until now this seems to work even without any workaround.

The first test build will come after it got approved by Apple (new version number 1.13.1 requires a review). After some more tests I will then provide the real fix. In general this problem could have happened also for other situations where the same image-URL was used in different resolutions ...

Btw, during my tests I saw this problem multiple times even when starting movies from the movie database view.

[amasephy]

Incredible you were able to track down the root of the problem so quickly. That does indeed sound nasty.

Seems most of the devious bugs we have discovered and struggled to identify ways to reproduce have all been race conditions. They’re so annoying because they can seem to happen randomly.

Interesting that you were able to trigger from the database. I was not able to do that and I tried many different media.

Either way glad there’s a fix coming down the pipe.


Slightly off topic - does apple require a review before each test flight or only because a new version was just released to the App Store? I don’t think it’s much of a secret that these walled gardens can be a pain for devs to deal with.

[Buschel]

If the app version changes (like now from 1.13 to 1.13.1) there is an initial review which takes quite long. All new TF builds with the same version are more less available instantly.

[Buschel]

1.13.1 build 4106

Test build with a workaround for the "NowPlaying cover with low resolution" issue. This just removes the downscaling of playlist thumbnail covers. This is how the 1.12.1 was using sdwebimage and it is a less intrusive change.

[UlfSchmidt]

Already received 4107, what’s the difference to 4106?

[Buschel]

1.13.1 build 4107

Testing rework to properly handle the parallel loading of same image-URL with different target-resolutions. 

@UlfSchmidt, 4106 is less intrusive change and a workaround. 4107 is the real rework, but more risk for regressions. Both should fix the "low res" issue, 4106 is possible the lower risk for a hot fix release on AppStore, 4107 is the real thing on the long run.

[UlfSchmidt]

OK, thanks, giving both a try …

[amasephy]

Initial testing with both versions looks promising. Will keep an eye on it for awhile.

[amasephy]

I thought I had noticed something strange for awhile. Tonight I confirmed it.

When you tap on the now playing poster art to bring up currently playing overlay there is a problem. A high res logo is briefly displayed in the lower right corner for a split second. This should not be visible unless high res music is being played. Here you can see I am playing a movie. Regardless it shouldn’t be visible for a split second.

Here’s a screen capture. By the way, it only happens the first time this screen gets initialized. You can reset it by leaving now playing and going somewhere else and going back to now playing. However repeatedly displaying the overlay will not reproduce the issue.

[Buschel]

I could not reproduce this, but I saw a wrong initialization in the code which can definitely cause such effect. This is now corrected and I assume this fixes your observation. Thanks for pointing this out.

Besides that, no more "low res" images seen?

[UlfSchmidt]

Besides that, no more "low res" images seen?

None so far for me, but please wait for amasephy's own confirmation

I also hope that the bug with the missing images gets fixed soon in Kodi 21 beta, so that I am no longer distracted by these.

[Buschel]

None so far for me, but please wait for amasephy's own confirmation

Thanks, as you also saw this issue, I bank on your feedback as well.

I also hope that the bug with the missing images gets fixed soon in Kodi 21 beta, so that I am no longer distracted by these.

Yes. Such Kodi problems are always a hassle as app users often assume it is an app problem and then raise issues or give low ratings.

[amasephy]

I have not seen any low res art. I put it through the usual testing and crossed between iPhone and iPad - starting video on iPhone and then starting up Kodi on iPad and checking.

Your fixes appear to have done the trick. 🙂


Regarding the overlay - sounds good. This would be really nitpicking but I noticed that the text gets full justification a split second after the text is revealed. This is not visible unless you frame peek though unlike that hi res audio logo.

[Buschel]

Your fixes appear to have done the trick. 🙂

Very good. I already reworked this a bit more and made it better matching the intended way of how the open source solution was implemented.

This would be really nitpicking but I noticed that the text gets full justification a split second after the text is revealed. This is not visible unless you frame peek though unlike that hi res audio logo.

I tried this a few times, made recordings and cannot see this on iPad or iPhone simulator. As this seems barely visible I will not further invest time in this.

[amasephy]

Before I forget I wanted to bring up a couple of things for your consideration.

The other day I was doing some searching and a rumor surfaced that one of the 3rd party remote apps had the ability to control audio through CEC. I tried this app but it didn’t work. Looks like it’s been left to rot for many years.

However I figured I would see if it’s possible to implement here. This is something I would use all the time and is the only thing that forces me to reach for another remote.

Basically I was wondering if it’s possible to implement a mechanism to adjust audio volume while using Passthrough on Kodi server? The idea was that a CEC signal could be sent from the Kodi server box to the connected audio receiver. Is there any possibility of this?

Secondly-

Something I did discover that you may like. I know you have been working on making the app easier for first time users. I’d like to make a suggestion for this. Check out the “Constellation for XBMC” app. It has a very slick onboarding mechanism for new users/installations where you are immediately prompted to give the app access to your network and it immediately searches for Kodi instances. As good as that interface is, I’m certain if you chose to build something like this that it could be made even better here.

Just my thoughts. Very happy with the current state of the app regardless.