:bug: Background fanart won't display for items in container (513) after "Action_Recommendations_OnClick" from a different film

[OfficerKD637]

Skin section

Widgets

Current Behavior

Hi J!

I know I butchered the title of the bug but I didn't know how best to concisely describe it lol.

When you're on the info page of an item and you click right to go into Window(1120) to browse the Director or Writer's catalog (container(513)), everything works fine.

Now you click on any one of those items (let's say a different movie by the same director), and it takes you to the info page of that item. But now when you try clicking right to go into container 513, all the widgets won't have the bg fanart anymore (although the clearlogo is present).

I think it's not that the fanart is not present (because it just displayed them when we were in the info page of the first film), but #that it's falling back to the default gradient backgrounds (coal, slate, green, blue, etc.).

Here's a video to demonstrate the issue: https://streamable.com/u3hwi6

Expected Behavior

Container(513) to display bg fanart after "Action_Recommendations_OnClick" from a different film

Steps To Reproduce

1. Go to the info page of a movie/tv show
2. Click right to go to the Director or Writer's catalog (container (513))
3. Click on any of the items which should take you to the info page of that respective item
4. Try going to container 513 again

Background fanart not displayed

Screenshots and Additional Info

1. First visit to Container(513)

2. Subsequent visit to Container(513) after "Action_Recommendations_OnClick"

Checklist

• [X] I have made a separate issue for each bug that I am reporting.
• [X] I have searched the issues and this bug has not been reported.
• [X] I am using the most recent skin version.
• [X] I have confirmed that this bug does not occur in the default skin.

[jurialmunkey]

I know I butchered the title of the bug but I didn't know how best to concisely describe it lol.

Haha. I understood. Despite the butchering, the title actually helped me pretty much instantly understand the issue.

[OfficerKD637]

Hahaha. I know you love saying 'You'd need a crystal ball for that!' or 'Neither Kodi nor you can read our minds!' when I ask (several) silly questions, but why do I have the feeling maybe you CAN read our minds lol.

As always. thank you so much!!

[OfficerKD637]

I just tested this and it still didn't fix it. Can you kindly check if the issue is solved at your end?

[jurialmunkey]

I just tested this and it still didn't fix it. Can you kindly check if the issue is solved at your end?

Yeah it's working fine for me after the change (I did test it before I pushed it!). I could reliably cause the issue beforehand and now can't, so it seems fixed to me

[OfficerKD637]

That's so strange... I haven't been able to get it to work. Tried restarting Kodi, fresh install of the skin, etc.

I am not sure if this will help, but here's a debug log: https://paste.kodi.tv/baqihutota.kodi

And here's a video: https://streamable.com/cpo7zm Only the clearlogo shows up for the new movies, but the background art displays the default gradient as soon as Window1120 is active. When I bring my focus back to 4001, the fanart shows up again.

[OfficerKD637]

Hey Jurial,

Hope you're doing well!

I still can't seem to wrap my head around this problem. Can you please take a look at my log or video and tell me what I might be doing wrong?

I can provide more debug logs/info if needed.

[jurialmunkey]

Have you tried with Omega to make sure it isn't Kodi version related? Could be all sorts of things if you're using a master branch as there's lots of new features being added in terms of rendering that will likely have bugs to sort out (e.g. see togglebutton issues).

[OfficerKD637]

Yes, I have tried with Omega as well. Exactly the same behavior.

Here's the Omega log running AF v0.7.27: https://paste.kodi.tv/xehudovevu.kodi

[jurialmunkey]

Does it happen with auto play trailers off?

[OfficerKD637]

Unfortunately yeah. I tried with the trailers off (and disabled Background video)

It's using the blue_blur.jpg as the fallback image (because that's what I set as my window background in the 'Appearance' settings). I confirmed this by changing it to something like 'Pink' and now everything is Pink.

This issue only occurs when True position >= 1 in the Details Window and 513 is in focus.

I turned on the 'Information' overlay and I can see that the correct metadata is passed through in all the subsequent visits to the details window (True position also goes up accordingly).

Can you think of a scenario when the Window background image is displayed instead of the actual fanart? Because I've noticed in other cases, when there's no TMDb fanart for a film, it'll just show up as blank/black (not Pink, Blue, Green, etc. from one of the blurs.) or cycle through the images from your fallback folder.

[jurialmunkey]

Unfortunately yeah. I tried with the trailers off (and disabled Background video)

Ok then there goes my idea that it might've been playback refreshing the container

Because I've noticed in other cases, when there's no TMDb fanart for a film, it'll just show up as blank/black (not Pink, Blue, Green, etc. from one of the blurs.) or cycle through the images from your fallback folder.

Assuming you're using "Real Blur" for background, this should not happen. Either fanart is displayed, or the blur fallback is displayed. You should not get a black background unless the image exists but is currently caching (that might cause a black background because no previous image was loaded and the new one is not ready yet).

Are you using some other Background setting than Real Blur? Because that's a key detail here...

[OfficerKD637]

I'm using 'Fake Blur'

[jurialmunkey]

I'm using 'Fake Blur'

Well there's the problem. Hacks will have hack behaviour. It's impossible to manage backgrounds properly using this hack due to issues with nesting Kodi variables and the way Kodi manages info dialog ListItems outside of the library.

[OfficerKD637]

Well there's the problem. Hacks will have hack behaviour. It's impossible to manage backgrounds properly using this hack due to issues with nesting Kodi variables and the way Kodi manages info dialog ListItems outside of the library.

Damn it.... It was just a matter of changing my 'Background style' setting. Although, I did try one of the other 'Performance' options (Fanart) and the same bug was present. Today, as soon as I switched it to 'Real blur', everything worked perfectly. But albeit it working seamlessly on my Windows system, I am a bit uncertain of how this setting would perform on a low powered ARM device...

I'm going to give these 2 commits a go and get back to you asap.

Thank you so much for trying to accommodate my needs with these hacks. I know it feels shitty working around Kodi's limitations, and there's not much I can say to make you feel better but I am truly grateful for everything that you do.

EDIT: Works flawlessly with both 'Fake Blur' and 'Fanart' Background styles! Thank you thank you thank you!!!

[jurialmunkey]

Although, I did try one of the other 'Performance' options (Fanart) and the same bug was present.

Yep they will all have the same issue.

The problem is twofold:

1. The ListItem of the VideoInfoDialog is not available in the dialog above it (i.e. 1120) because you can't access listitems from other windows (only other containers in the same window). That's why the base image appears blank (the difference on the first pass is that you're in the library, so you're getting the background of the library instead since everything else is blank).
2. There's some issue with nested VARs (VARs inside other VARs) in Kodi. My guess is that if two windows are accessing the same nested var at the same time (e.g. both Info and 1120 using the background image VAR), then the value is pulled from memory. That's why traversing the list of director movies also doesn't change the background despite being in the same window (because it's getting the original output from 1 instead).

The reason it works with the Real Blur is because TMDbHelper sets a property containing the blur image path (and original image for the flixart portion) to the home window, so that can be accessed by the background in any window.

The "Real Blur" also really simplifies the code to handle things because its one property and TMDbHelper can handle all the fallbacks and different container IDs etc. (vs. needing a variable which covers all those different scenarios). This is same reason why logo displays correctly (essentially same method but for cropping instead of blurring).

[OfficerKD637]

Now it all makes sense. As long as TMDbHelper is in charge of setting the properties and image paths, it's easier to workaround Kodi's issues (since it only has to worry about one property and no nested VARs)

But how did you solve this bug? What's the secret sauce? I am guessing that new 'Includes_Images_Background_FakeBlur.xml' file is acting like a faux TMDbHelper, where the other windows can reference it to get the images it needs?

[jurialmunkey]

Kind of. The new file is just an override for the variable so that I can flatten it a bit (rather than be a variable inside another with a condition - I make the file itself conditional). So that solves the nested var issue for 513 to work properly.

For the main background though, that's essentially faking Tmdbhelper's process by setting the background var to the same property it would use when the onclick action occurs to open the 1120 dialog. That allows me to do a sort of half/half approach where the main background (if 513 unfocussed) uses the property but then the container (513 focused) still uses the normal variable.

[OfficerKD637]

That 50/50 hack is blowing my mind.....