(2024-04-05, 00:10)AllesMeins Wrote: I think we're making some progress (yay!)...
1. Enabling "Override home background with global slideshow" indeed solves the problem. The two variables are displayed and almost at the same time a background-images starts showing. So this looks promising.
2. When I change the active menu to TV Shows (with "Override home background with global slideshow" disabled) a background is shown much more quickly then when I leave the active menu on Movies. However (without having timed it) it felt still somewhat longer than the time i got with "Override home..." enabled. I don't know what constitutes a large library - I'm at about 700 movies and 200 tv shows.
Quote:You can see the rules for it in Variables_Paths_Media.xml at line 20: The variable "Background_Home_Path". This basically checks the path of the menu item you've currently got selected and then sets a corresponding path.
Is there an easy way to give it some debug-value or let it be displayed so I can try to figure out, what is going on and which condition is matching?
A shot into the dark - I tried to rule it out, but it was inconclusive:
I'm using emby as my media provider (Addon: Emby for Kodi next gen) and that does some crazy stuff with the video libraries. It creates all kinds of different entries for different use cases (stuff like "emby_tvshows_recentlyaddedepisodes" or "emby_movies_by_studios",...). There are also som video-libraies called "Emby_DYNAMIC" which I think are pulled directly from the sever and take pretty long to load. Does Copacetic maybe try to scan all those libraries? However I don't know how this could explain that it works faster with "Override home..." enabled.
Disabling the addon didn't speed things up, but I don't know how those libraries behave if the addon is disabled. Maybe they just run into a timeout which would probably take as long as querying the server with the addon enabled. I thought about uninstalling it, but I think that would not help, because than there would be no movie library to display.
Is there anything else I can do to help you track this down? I have a good backup of my setup, so I'm willing to tinker with everything and do all I can, although it might take some time because I'll be away over the weekend.
Edit:
One more observation, but I'm not sure if this is intended behavior or a clue to some sort of problem. There seems to be some backlog when changing focus. So after the backgrounds have started when switching focus from movies to tv shows (or vice versa) it takes about 4-5 images that are still left over from the previously selected menu until it starts showing stuff from the current selection.
OK, great, the global slideshows will be the most consistent because they are loaded by a monitor service that's always running in the background so are not dependant on any particular window. So once it's up and running (after 10 seconds), it will always have a fanart available even if you navigate away from home and back. When you use these global slideshows on the homescreen by enabling that override option, I've also tried to make a consistent experience between the home screen and other windows that use the global slideshows (e.g. addon browser, settings etc). Because I know the background will be the same, I can remove all the window transitions and it should feel like one continuous experience if you, say, go from Home to Settings etc. The other thing I recently added to the script is that if you shutdown or exit Kodi, it will capture the last fanarts loaded into the global slideshows and write them to a file, then as soon as Kodi is initialised, while the script is fetching new artworks, it will show those. There is still a slight delay of a couple of seconds while the fanart monitor loads, but it's as quick as I can figure out to make it.
Now setting aside the global slideshows for a moment, if you want to have different slideshows for each item in your menu, you can actually enjoy much finer control over this if you go to Settings > Copacetic > General > Menus. Go into the home menu and for each item, you will have the option to choose either a library path, a playlist, or an image/folder of images that will be used when that item is focused in your menu. So that way you could use certain Emby paths if you wanted to.
Setting that aside as well, and assuming we will rely on the default home screen background slideshow. Given that I didn't put any limit on the container that fetches the artwork, I think your library would be large. It's effectively pulling together 700+ fanarts in the background, which is probably the cause of the delay and probalby why TV Shows happens quicker.
I just pushed a new version (1.1.27) to my repo, which now limits this to 40 artworks. Hopefully that will speed things up significantly.
The last point, about the 'backlog' you noticed when changing focus. I might have seem something similar but less severe when switching say, from TV Shows to Movies. But again, I think it was because movies was slower to fetch the artwork because there was more of them. So let's see if limiting the artwork to 40 fixes that issue as well.
Lastly, the easiest way to debug the variable Background_Home_Path if you still want to, is to add a label to Home.xml. Right at the end before the </controls> tag, add this. The first line will show the current source that is being used to get fanarts, the second will show you the path of the current displaying fanart:
xml:
<control type="label">
<align>right</align>
<label>$VAR[Background_Home_Path][CR]$INFO[Container(3300).ListItem.Art(fanart)]</label>
</control>
It will work just like the label we used Custom_1199_Test_Label.xml. The reason we can't just use that again is because previously we were looking at Window Properties, which are available across the skin. But this variable is dependant on the actual container used for the homescreen menu and that can only be 'seen' by labels within the same window. I just realised this is why the VAR label in our previous communications was empty, because the label in the window Custom_1199_Test_Label.xml can see the global slideshow fanarts because they are in window properties, but it can't see the fanarts generated by the container on the home screen which is used when you don't have the override enabled. D'oh!!!
If you do add the label to the homescreen to debug, remember also to disable the Custom_1199_Test_Label.xml label by changing <visible>true</visible> to false at the top, otherwise, that one will go on top.
