+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: Skins Support (https://forum.kodi.tv/forumdisplay.php?fid=67)
+---- Forum: Copacetic (https://forum.kodi.tv/forumdisplay.php?fid=320)
+---- Thread: Solved Slideshow takes ~60 seconds to start - is this normal? (/showthread.php?tid=376861)
Pages:
1
2
Slideshow takes ~60 seconds to start - is this normal? - AllesMeins - 2024-03-31
I really like that skin, but for some reason it takes very long for the background-slideshow to start. There is about 50-80 seconds just a black background until the first image shows up. This happens every time I start kodi and approx 70% of the times when I return to the main menu after watching a video. Once the show has started it runs without problems. I'm using emby as a media server, but already have a lot of artworks cached locally, so this shouldn't be a problem. Is this a known behavior or could this be a bug/settings-problem?
I'm using LibreElec 11.0.6 with Kodi 20.3 and Copacetic 1.1.24 on a on a Raspberry Pi 4. I connect to the emby server via "Emby for Kodi next gen" and have artwork caching enabled. As a test I also did a complete local caching of all artworks but this didn't solve the problem.
RE: Slideshow takes ~60 seconds to start - is this normal? - realcopacetic - 2024-04-01
It certainly shouldn't take that long. For comparison on my shield it takes about 1-2 seconds to start the background service and do the initial fetch of the first 40 artworks. I've also tested on a desktop Windows machine and a MacBook and they were faster (which makes sense as they were more powerful)
It's strange that the same thing happens when you exit back to the home menu. One the service starts there should always be a background fanart available. Even when it does a new fetch, if that process was causing the delay, it would just die the previous artwork for longer.
Can you go into add-ons > script.copacetic.helper > info > settings and enable all the debug settings.
Then can you follow these steps to post a full debug log please: https://kodi.wiki/view/Log_file/Easy#:~:text=If%20you%20are%20using%20a%20desktop%20operating%20system%2C%20such%20as,Manager%20of%20the%20operating%20system.&text=Open%20it%20with%20any%20text,and%20press%20the%20Save%20icon.
After enabling debugging in the Kodi settings you need to restart and then the debug should record what's going on when you start up and navigate back to home
RE: Slideshow takes ~60 seconds to start - is this normal? - AllesMeins - 2024-04-01
Here is the logfile you requested uwavoyezob.kodi (paste)
I couldn't reproduce the issue when getting back to home (maybe this just happens after watching a movie for a longer time?) but in the logfile you see a boot up with quite a long time until the first background showed up. I also noticed a crazy high CPU-usage (>390% out of 400) while waiting for the slideshow to start. This dropped somewhat after the first few pictures showed, but still stayed >350% - that is way more than what I have while watching a movie.
RE: Slideshow takes ~60 seconds to start - is this normal? - realcopacetic - 2024-04-01
(2024-04-01, 15:05)AllesMeins Wrote: Here is the logfile you requested uwavoyezob.kodi (paste)
I couldn't reproduce the issue when getting back to home (maybe this just happens after watching a movie for a longer time?) but in the logfile you see a boot up with quite a long time until the first background showed up. I also noticed a crazy high CPU-usage (>390% out of 400) while waiting for the slideshow to start. This dropped somewhat after the first few pictures showed, but still stayed >350% - that is way more than what I have while watching a movie.
Thanks for sharing.
It looks from this log like the first time the window properties used for fanarts are populated is 14:55:29.209. The process started at 14:55:19.806, so it's about 10 seconds from when the process was launched and about 25 seconds from when Kodi was initialised at 14:55:06.454.
A couple of things I noticed.
- It looks like the Next_Up widget is really hogging your system resources following startup. 218 of the 402 lines in this log mentioning script.copacetic.helper appear to be related to the next_up. widget.
- The refresh starts at 14:55:15.401 and seems to finish at 14:55:29.819. In that time it's making a lot of JSON calls.
- It looks like you have script.embuary.info/helper running in the background. I known that has a widget refresh function and I'm not sure if that's triggering it, but pretty much immediatley, the Next_Up widget for script.copacetic.helper seems to refresh again at 14:55:37.727, which doesn't seem optimal (This is just after the line [ script.embuary.helper ] Force widgets to refresh (AudioLibrary.OnScanFinished), so I'm not sure if that's the cause).
a) due to the size of your library or the power of the Raspberry Pi, the JSON calls used to fetch artwork and fill the plugin widget directories are taking too long
b) there are multiple background services running simultaneously, putting additional strain on your system.
I would suggest doing some testing to see what impact the following scenarios have:
1) Disabling Next_Up widget in Copacetic
2) Disabling any background services you don't currently need, e.g. any of the Embuary stuff, which I think isn't actively maintained anymore.
3) Last thing is that the delay until there is a fanart path for the background slideshow, although really slow (~25 seconds from startup), is still quicker than what you're perceiving (50-80 seconds). One more test you can do if you don't mind editing a couple of lines of XML.
In the file skin.copacetic/16x9/Custom_1199_Test_Label.xml, if you can make the following two changes:
Line 3: <visible>true</visible>
Line 14: <label>$INFO[Window(home).Property(background_global_fanart)]</label>
And if there are any other <visible> lines apart from Line 3, you can delete those whole lines.
What that will do is show you as soon as there is a fanart for the background slideshow. It should show in the top-right corner. If you see a value there but the screen is still black, then something else is going on.
E.g. for me, I had it for a while where I was getting a lot of black screens using the Artist slideshow because the fanarts for my musiclibrary weren't cached, so it was trying to show them but couldn't and the result was a black screen.
RE: Slideshow takes ~60 seconds to start - is this normal? - AllesMeins - 2024-04-03
Thank you for taking the time to check my log. I've uninstalled embuary and all its helpers and disabled the "Up next"-Addon (couldn't uninstall it, because it is a dependency for copacetic) I also disabled the "Next up"-widget in the copacetic settings because I wasn't sure what you were referring to. Unfortunately neither helped - I timed it with a stopwatch and it took 61 seconds from the moment the Kodi-Splash disappeared until the first background-image was shown.
I also did the change to the XML - almost immediately there was a pinkish square in the corner - about ten seconds in a very long string appeared: http://127.0.0.1:57342/picture/3f2249f4... (going on over the whole width of the screen and longer - the last characters I can see beore it goes out of the screen are "...|redirect-li") without an image showing.
Here is a logfile of this run
RE: Slideshow takes ~60 seconds to start - is this normal? - realcopacetic - 2024-04-04
(2024-04-03, 19:56)AllesMeins Wrote: Thank you for taking the time to check my log. I've uninstalled embuary and all its helpers and disabled the "Up next"-Addon (couldn't uninstall it, because it is a dependency for copacetic) I also disabled the "Next up"-widget in the copacetic settings because I wasn't sure what you were referring to. Unfortunately neither helped - I timed it with a stopwatch and it took 61 seconds from the moment the Kodi-Splash disappeared until the first background-image was shown.
I also did the change to the XML - almost immediately there was a pinkish square in the corner - about ten seconds in a very long string appeared: http://127.0.0.1:57342/picture/3f2249f4... (going on over the whole width of the screen and longer - the last characters I can see beore it goes out of the screen are "...|redirect-li") without an image showing.
Here is a logfile of this run
Thanks, that's interesting. It means the path to the texture that it should use in the slideshow is available from aobut 10 seconds. So that is when I would expect the background artwork to become visible. So now I just need to figure out why you're still seeing the black screen even though there's a path available for the image.
One more request if you don't mind.
Line 14, can you add this immediately before the </label>:
[CR]$VAR[Background_Home_Texture]So overall, youre line 14 in the file skin.copacetic/16x9/Custom_1199_Test_Label.xml should now look like this
xml:
Line 14: <label>$INFO[Window(home).Property(background_global_fanart)][CR]$VAR[Background_Home_Texture]</label>
What you should now expect to see is a second line under the previous long string and ideally the second line would have the same long string as what's in the first line.
RE: Slideshow takes ~60 seconds to start - is this normal? - AllesMeins - 2024-04-04
That did not work - are you sure this is the right variable? It only displayed the first line - even later when the backgrounds started showing. I did some tinkering (put it in an extra block and put a regular string after it to make sure it isn't displayed off screen or something) and I think I can say fairly certain that this variable is empty.
RE: Slideshow takes ~60 seconds to start - is this normal? - realcopacetic - 2024-04-04
(2024-04-04, 00:38)AllesMeins Wrote: That did not work - are you sure this is the right variable? It only displayed the first line - even later when the backgrounds started showing. I did some tinkering (put it in an extra block and put a regular string after it to make sure it isn't displayed off screen or something) and I think I can say fairly certain that this variable is empty.Yes, you can trace it back like so:
xml:
16x9/Home.xml, line 40 --> <include content="Background_Home" />
16x9/Components.xml, line 194 --> <include name="Background_Home">
16x9/Components.xml, line 202 --> <include content="Background_Multiart_Home" condition="Skin.String(Background_Interval,10) | !Skin.String(Background_Interval)">
16x9/Components.xml, line 182 --> <include name="Background_Multiart_Home">
16x9/Components.xml, line 188 --> <param name="texture_path" value="$VAR[Background_Home_Texture]" />
16x9/Variables_Textures_Artwork_Media.xml, line 39 --> <variable name="Background_Home_Texture">
This is the line I have in 16x9/Custom_1199_Test_Label.xml, line 14:
xml:
<label>$INFO[Window(home).Property(background_global_fanart)][CR]$VAR[Background_Home_Texture]</label>
Which shows this (screenshot 1):
The first line (the $INFO value) shows that script.copacetic.helper is fetching fanarts and providing them to the skin via skin properties. The second line (the $VAR value) shows which window property is currently being used to serve an image to the home background.
This depends on what you have selected in Settings > Copacetic > Background. Assuming you have chosen to override the default home backgrond with global slideshows (the bottom option, see screenshot 2) and have selected one of the slideshows (the top option, see screenshot 3), then the variable Backgronud_Home_Texture should be showing the output from the selected slideshow. If you chose the global slideshow (Movies / TV Shows / Art), then the two values shown by the test label in the top right corner should be the same because the $INFO we used was for the global slideshow window property
screenshot 2:
screenshot 3:
Assuming you don't have a typo, the fact that this variable is empty would make sense if you are seeing a black screen, but it doesn't make any sense that this would continue to be empty if you are then seeing artwork in the background.
To make sure the variable is empty because none of the conditions are being met for some reason, what you can do is go to the variable (16x9/Variables_Textures_Artwork_Media.xml) and after line 50, add a new line at the very end of the variable along the lines of:
xml:<value>Hello</value>
Then this value should always show in your test label if it for some reason isn't pulling through any of the artwork paths. Because we have a hardcoded value as a fallback, the variable should ALWAYS have a value. If you still don't see the second line in your test label, you must have an issue in your test label itself.
RE: Slideshow takes ~60 seconds to start - is this normal? - AllesMeins - 2024-04-04
I tried it again, the varaible stays empty. This is how it looks for me:
And these are my settings
The relevant part of my 16x9/Variables_Textures_Artwork_Media.xml:
Code:
<variable name="Background_Home_Texture">
<value condition="Skin.HasSetting(Home_Background_Override_Enabled) + Skin.String(Background_Slideshow,Custom) + Skin.String(Background_Slideshow_Custom_Path) + !String.Is>
<value condition="Skin.HasSetting(Home_Background_Override_Enabled) + Skin.String(Background_Slideshow,Global) + !String.IsEmpty(Window(home).Property(background_global_fa>
<value condition="Skin.HasSetting(Home_Background_Override_Enabled) + Skin.String(Background_Slideshow,Videos) + !String.IsEmpty(Window(home).Property(background_videos_fa>
<value condition="Skin.HasSetting(Home_Background_Override_Enabled) + Skin.String(Background_Slideshow,Movies) + !String.IsEmpty(Window(home).Property(background_movies_fa>
<value condition="Skin.HasSetting(Home_Background_Override_Enabled) + Skin.String(Background_Slideshow,TVShows) + !String.IsEmpty(Window(home).Property(background_tvshows_>
<value condition="Skin.HasSetting(Home_Background_Override_Enabled) + Skin.String(Background_Slideshow,Artists) + !String.IsEmpty(Window(home).Property(background_artists_>
<value condition="!Skin.HasSetting(Home_Background_Override_Enabled) + !String.IsEmpty(Container(3000).ListItem.Property(backgroundPlaylist)) + !String.IsEmpty(Control.Get>
<value condition="!Skin.HasSetting(Home_Background_Override_Enabled) + !String.IsEmpty(Container(3000).ListItem.Property(backgroundPlaylist))">$INFO[Container(3300).ListIt>
<value condition="!Skin.HasSetting(Home_Background_Override_Enabled) + !String.IsEmpty(Container(3000).ListItem.Property(background))">$INFO[Container(3000).ListItem.Prope>
<value condition="!Skin.HasSetting(Home_Background_Override_Enabled) + !String.IsEmpty(Control.GetLabel(3401))">$INFO[Control.GetLabel(3401)]</value>
<value condition="!Skin.HasSetting(Home_Background_Override_Enabled)">$INFO[Container(3300).ListItem.Art(fanart)]</value>
<value>Hello</value>
</variable>
And my 16x9/Custom_1199_Test_Label.xml:
Code:
<?xml version="1.0" encoding="UTF-8"?>
<window type="dialog" id="1199">
<visible>true</visible>
<zorder>3</zorder>
<controls>
<control type="image">
<width>200</width>
<height>200</height>
<right>0</right>
<texture colordiffuse="pink">views/white_100.png</texture>
</control>
<control type="label">
<align>right</align>
<label>$INFO[Window(home).Property(background_global_fanart)][CR]$VAR[Background_Home_Texture]</label>
<height>200</height>
</control>
</controls>
</window>
RE: Slideshow takes ~60 seconds to start - is this normal? - realcopacetic - 2024-04-04
It might be because you have the option 'Override home background with global slideshow' disabled. If you enable that, does the variable show a path?
Right now with that option disabled, and assuming that you haven't set a background image or playlist for any of the shortcuts in your menu via the menu customisation screen, then it will fallback to the last line, $INFO[Container(3300).ListItem.Art(fanart)]. Because the condition on that line doesn't check to see if there's a value present or not, it will display this value even if it's empty. So I think that's why it's not showing 'Hello'. If I added "+ !String.IsEmpty(Container(3300).ListItem.Art(fanart))" to the condition in the line above 'Hello', then that condition would no longer be true because the string is indeed empty, and then it would fall back to 'Hello' I think.
So first a question and then a new conundrum.
1. The question is if you enable 'Override home background with gloabl slideshow' does it then solve the issue of the home screen being stuck on a blank screen even though our test label shows the window properties for the global slideshow are providing artwork after about 10 seconds?
2. The conundrum is, even with it disabled, why is the Variable empty? $INFO[Container(3300).ListItem.Art(fanart)] should have a value. This is a list that auto scrolls through different content sources depending on the shortcut you currently have selected in your menu.
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.
xml:
<variable name="Background_Home_Path">
<!-- Global override - script.copacetic.helper -->
<value condition="Skin.HasSetting(Home_Background_Override_Enabled) + Skin.String(Background_Slideshow_Custom_Path)">$INFO[Skin.String(Background_Slideshow_Custom_Path)]</value>
<!-- Item override -->
<value condition="!String.IsEmpty(Container(3000).ListItem.Property(backgroundPlaylist))">$INFO[Container(3000).ListItem.Property(backgroundPlaylist)]</value>
<!-- playlists and xml library paths e.g. inprogress or sets -->
<value condition="String.Contains(Container(3000).ListItem.Property(list),.xsp)">$INFO[Container(3000).ListItem.Property(list)]</value>
<value condition="String.Contains(Container(3000).ListItem.Property(list),.xml)">$INFO[Container(3000).ListItem.Property(list)]</value>
<!-- music paths -->
<value condition="String.Contains(Container(3000).ListItem.Property(list),recentlyaddedalbums)">musicdb://recentlyaddedalbums/</value>
<value condition="String.Contains(Container(3000).ListItem.Property(list),recentlyplayedalbums)">musicdb://recentlyplayedalbums/</value>
<value condition="String.Contains(Container(3000).ListItem.Property(list),musicplaylists)">musicdb://artists/?albumartistsonly=true</value>
<value condition="String.Contains(Container(3000).ListItem.Property(list),musicdb)">musicdb://artists/?albumartistsonly=true</value>
<!-- video paths -->
<value condition="String.Contains(Container(3000).ListItem.Property(list),recentlyaddedepisodes)">videodb://recentlyaddedepisodes/</value>
<value condition="String.Contains(Container(3000).ListItem.Property(list),inprogresstvshows)">videodb://inprogresstvshows</value>
<value condition="String.Contains(Container(3000).ListItem.Property(list),tvshows)">videodb://tvshows/titles/</value>
<value condition="String.Contains(Container(3000).ListItem.Property(list),recentlyaddedmovies)">videodb://recentlyaddedmovies/</value>
<value condition="String.Contains(Container(3000).ListItem.Property(list),sets)">videodb://movies/sets/</value>
<value condition="String.Contains(Container(3000).ListItem.Property(list),movies)">videodb://movies/titles/</value>
<!-- fallbacks -->
<value condition="Library.HasContent(Movies)">videodb://movies/titles/</value>
<value condition="Library.HasContent(TVShows)">videodb://tvshows/titles/</value>
<value condition="Library.HasContent(Music)">musicdb://artists/?albumartistsonly=true</value>
<value />
</variable>
So for example, in your menu, I see you have Sets. If you're focused on that item, it should trigger this line in the variable:
xml:
<value condition="String.Contains(Container(3000).ListItem.Property(list),sets)">videodb://movies/sets/</value>
And then all the artwork you see should be just from your sets.
One thing I've noticed in my setup is that when the path falls back to 'videodb://movies/titles', which it would do if you were focused on Movies in your menu, or a generic item like Settings, it takes a while to refresh for some reason. Not sure why, but it's much slower than sets or tvshows, perhaps because there are more items in the library. If you had a large library, perhaps that would explain the long delay. If we can confirm this is the issue, I can try limiting the number of items in the list to speed things up a bit. If you leave your menu focused on TV Shows instead, does that make it quicker for the fanart to appear?
But the thing I can't get my head around is how the variable is empty in your test label, but you're still seeing artwork on the homescreen.
RE: Slideshow takes ~60 seconds to start - is this normal? - AllesMeins - 2024-04-05
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.
RE: Slideshow takes ~60 seconds to start - is this normal? - realcopacetic - 2024-04-05
(2024-04-05, 00:10)AllesMeins Wrote: I think we're making some progress (yay!)...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.
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.
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.
RE: Slideshow takes ~60 seconds to start - is this normal? - AllesMeins - 2024-04-07
Thank you, I installed the update and this seemed to solve the problem. Everything runs a lot faster now!
I've one more question though: Updating your skin has deleted my configuration for the home and shutdown menu.
- Can this be avoided with future updates? As far as I can see this is the only setting that got reset during the update - everything else is still as I had it configured.
- I still have a backup of my kodi folder: Which files should I restore to get my menu configuration back without having to set up everything by hand (I only have a TV remote to control kodi which makes it a bit time consuming)
RE: Slideshow takes ~60 seconds to start - is this normal? - realcopacetic - 2024-04-07
I think I may know what caused this. Did you update from Kodi repo? I can stop this happening next time
RE: Slideshow takes ~60 seconds to start - is this normal? - AllesMeins - 2024-04-07
I'm not sure - originally I installed from the Kodi-Repo, but since then I already did one version upgrade from your repo. But I don't remember if I also updated everything else from your repo - so I might have had a mixed installation. It would probably be best if I did a clean install, but I'm a bit hesitant since I've already invested so much time to configure everything to my likening.