New Beta Available (3.2.0~beta1)
- added option to pause slideshow when playback pauses
- override slideshow no longer resets at each song change
- fix for AS not reloading settings properly when in daemon mode
- fixes for miscellaneous UTF8 errors
- internal change to the way the main thread talks to the slideshow thread
Available as usual from my beta repo. This is probably a good time to mention that if you were testing the 3.1.0 betas and don't feel the need to keep testing that you should delete my beta repo. If you get this update and didn't want it, uninstall the 3.2.0 beta, reinstall 3.1.0 from the main Kodi repo, and (as I just mentioned, delete my beta repo).
(2020-01-10, 03:56)pkscout Wrote: [ -> ]New Beta Available (3.2.0~beta1)
- added option to pause slideshow when playback pauses
- override slideshow no longer resets at each song change
- fix for AS not reloading settings properly when in daemon mode
- fixes for miscellaneous UTF8 errors
- internal change to the way the main thread talks to the slideshow thread
Available as usual from my beta repo. This is probably a good time to mention that if you were testing the 3.1.0 betas and don't feel the need to keep testing that you should delete my beta repo. If you get this update and didn't want it, uninstall the 3.2.0 beta, reinstall 3.1.0 from the main Kodi repo, and (as I just mentioned, delete my beta repo).
Thanks a bunch for these fixes! I actually got the second feature working in a hackish way (commented out three lines inside artistslideshow.py - self._clear_properties, self._use_correct_artwork, self._trim_cache inside the main loop in Main, __init__), but having a proper solution is always better.
Now the black screen only happens when I start the slideshow (not at every song change), but it's still annoying that it takes 94 seconds for slideshow to start. It's either very slow in reading the 16,000 jpeg file names over SMB, or slow in randomly re-shuffling the list. I'll be testing both assumptions - first by copying all my files to the local file system and using that as the override folder, and then by disabling the random pictures mode.
Copying all files to my SD card is a problem though, as Kodi insists on caching all my images (~30GB in total), so I won't have space when everything is cached. Perhaps caching is disabled when files are local? I'll test that. If not, I need to find a way to disable fanart caching, as it occupies space, wears off my SD card, slows down everything, messes up with the quality of my photos, and is totally unnecessary in my case (all my images are properly downscaled to 4K resolution, and my connection to the remote folder is over gigabit ethernet).
@
pkscout - perhaps you can provide some pointers to where I can tinker with the code to disable fanart caching? I noticed that when an image is scraped for the first time, it is shown directly in the slideshow, the second time and so on - it is read from the cached version. So I'm thinking if I can modify a line of code to prevent Kodi creating a cached version of an image, this would do the trick.
(2020-01-10, 17:16)pulsar124 Wrote: [ -> ] (2020-01-10, 03:56)pkscout Wrote: [ -> ]New Beta Available (3.2.0~beta1)
- added option to pause slideshow when playback pauses
- override slideshow no longer resets at each song change
- fix for AS not reloading settings properly when in daemon mode
- fixes for miscellaneous UTF8 errors
- internal change to the way the main thread talks to the slideshow thread
Available as usual from my beta repo. This is probably a good time to mention that if you were testing the 3.1.0 betas and don't feel the need to keep testing that you should delete my beta repo. If you get this update and didn't want it, uninstall the 3.2.0 beta, reinstall 3.1.0 from the main Kodi repo, and (as I just mentioned, delete my beta repo).
Thanks a bunch for these fixes! I actually got the second feature working in a hackish way (commented out three lines inside artistslideshow.py - self._clear_properties, self._use_correct_artwork, self._trim_cache inside the main loop in Main, __init__), but having a proper solution is always better.
Now the black screen only happens when I start the slideshow (not at every song change), but it's still annoying that it takes 94 seconds for slideshow to start. It's either very slow in reading the 16,000 jpeg file names over SMB, or slow in randomly re-shuffling the list. I'll be testing both assumptions - first by copying all my files to the local file system and using that as the override folder, and then by disabling the random pictures mode.
Copying all files to my SD card is a problem though, as Kodi insists on caching all my images (~30GB in total), so I won't have space when everything is cached. Perhaps caching is disabled when files are local? I'll test that. If not, I need to find a way to disable fanart caching, as it occupies space, wears off my SD card, slows down everything, messes up with the quality of my photos, and is totally unnecessary in my case (all my images are properly downscaled to 4K resolution, and my connection to the remote folder is over gigabit ethernet).
@pkscout - perhaps you can provide some pointers to where I can tinker with the code to disable fanart caching? I noticed that when an image is scraped for the first time, it is shown directly in the slideshow, the second time and so on - it is read from the cached version. So I'm thinking if I can modify a line of code to prevent Kodi creating a cached version of an image, this would do the trick.
I manually walked the code for first start, and I think I found the place that is holding things up. As it currently stands, AS will basically not show an image until every image in a directory is loaded. I hadn't really intended that to be true, but I hadn't noticed it because most of the time there aren't more than 100 - 200 images (my largest folder of artist images is 174) for a given artist and they're, at best, 1080p. So for most use cases there's almost no difference between loading one image immediately and waiting for them all to get loaded. I changed the order of operations in the Slideshow display loop and I
think it should now load an image much earlier. I'll post a new beta in a bit with that change.
As for caching, the Kodi caching mechanism is built into the core of the program, and I don't think you can disable that. If you haven't seen it yet, here's the Kodi wiki page on caching:
https://kodi.wiki/view/Artwork/Cache
The only thing you could do is to use something like Texture Cache Maintenance utility to automate the deletion of the cache, but I suspect that will have some unintended consequences.
Thanks for looking into this! I did see the Cache wiki page. Also did a lot of google searching, and it does look there is no easy way to disable caching. Kodi core is compiled, correct? I do see some string relevant to caching inside the kodi binary.
Do you know at what point inside your Python script the following Kodi LOG message are generated?
2020-01-09 20:14:45.100 T:140325565753088 DEBUG: [Artist Slideshow] ArtistSlideshow.Image set to /home/syam/KODI/CD-2019.04.28__MG_3534.jpg
2020-01-09 20:14:45.273 T:140326167779072 DEBUG: Caching image '/home/syam/KODI/CD-2019.04.28__MG_3534.jpg' to '3/3985c122.jpg':
2020-01-09 20:14:45.373 T:140326167779072 DEBUG: cached image 'special://masterprofile/Thumbnails/3/3985c122.jpg' size 1080x720
2020-01-09 20:14:46.101 T:140326030870272 DEBUG: [Artist Slideshow] same file playing, using cached artists_info
2020-01-09 20:14:50.101 T:140325565753088 DEBUG: Previous line repeats 3 times.
In particular, the second line. Perhaps I can trick Kodi into not generating the cached version of the image.
(2020-01-10, 19:32)pulsar124 Wrote: [ -> ]Thanks for looking into this! I did see the Cache wiki page. Also did a lot of google searching, and it does look there is no easy way to disable caching. Kodi core is compiled, correct? I do see some string relevant to caching inside the kodi binary.
Do you know at what point inside your Python script the following Kodi LOG message are generated?
2020-01-09 20:14:45.100 T:140325565753088 DEBUG: [Artist Slideshow] ArtistSlideshow.Image set to /home/syam/KODI/CD-2019.04.28__MG_3534.jpg
2020-01-09 20:14:45.273 T:140326167779072 DEBUG: Caching image '/home/syam/KODI/CD-2019.04.28__MG_3534.jpg' to '3/3985c122.jpg':
2020-01-09 20:14:45.373 T:140326167779072 DEBUG: cached image 'special://masterprofile/Thumbnails/3/3985c122.jpg' size 1080x720
2020-01-09 20:14:46.101 T:140326030870272 DEBUG: [Artist Slideshow] same file playing, using cached artists_info
2020-01-09 20:14:50.101 T:140325565753088 DEBUG: Previous line repeats 3 times.
In particular, the second line. Perhaps I can trick Kodi into not generating the cached version of the image.
That ArtistSlideshow.Image message comes right after AS selects one of the random images and then tells the skin that's the image to display. In the code that is in the Slideshow object within the run() method. That starts at line 157 of artistslideshow.py. I'd give you an exact line number, for the image set, but it's changing with the next beta. Look for this line:
python:
self._set_property( 'ArtistSlideshow.Image', image )
I don't think there's going to be any way from within Python to get Kodi to not cache that image, but that's the line that sets the skin property so the skin can display the image.
Thanks. I was looking into core Kodi code, found these potentially interesting lines (inside xbmc/addons/kodi-addon-dev-kit/include/kodi/Filesystem.h):
typedef enum OpenFileFlags
{
...
/// use cache to access this file
READ_CACHED = 0x04,
/// open without caching. regardless to file type
READ_NO_CACHE = 0x08,
...
}
Probably totally irrelevant. Or perhaps this is something an addon can use to disable caching?
New Beta Available (3.2.0~beta2)
- logic change to load first slideshow image sooner
- fix for potential runaway loop
- fix for slow slideshow change when artist changes
Available from my beta repo as usual.
The last two items are problems that developed in 3.2.0~beta1, so if you're using the 3.1.0 release you shouldn't be seeing those issues.
(2020-01-10, 21:09)pulsar124 Wrote: [ -> ]Thanks. I was looking into core Kodi code, found these potentially interesting lines (inside xbmc/addons/kodi-addon-dev-kit/include/kodi/Filesystem.h):
typedef enum OpenFileFlags
{
...
/// use cache to access this file
READ_CACHED = 0x04,
/// open without caching. regardless to file type
READ_NO_CACHE = 0x08,
...
}
Probably totally irrelevant. Or perhaps this is something an addon can use to disable caching?
There are no programmatic ways of which I am aware to change Kodi's caching. My best bet is that you'd have to change a flag somewhere in the source code and compile a custom version from scratch.
BTW, Here's every JSON call you can make to Kodi:
https://kodi.wiki/view/JSON-RPC_API/v9
And every Python call you can make:
https://codedocs.xyz/xbmc/xbmc/group__python.html
Core caches textures automatically (unless it's a skin texture). If you want to prevent it doing so, you would have to compile a version that skips this routine.
https://github.com/xbmc/xbmc/blob/6e017a...p#L64-L118
Possibly just deleting the code and returning
true would do it, but I'm no expert!
I do think it would massively increase loading time for art though, as without the cache, it will have to be fetched from source each time.
@
pulsar124 what you referenced is for filesystem caching, not art. There is no (simple) way to prevent core from caching art as that's what it's written to do, other than re-writing the parts that do it.
@
pkscout Sorry for trampling on your thread!
Thanks pkscout for the new beta! I'll be testing it when I get home.
Thanks to both, pkscout and black_eagle, for cache related info. In my case, loading time should actually improve without cache, as I am reading my own images from a high performance local computer over gigabit ethernet, and caching involves writing, then reading from a fairly slow local SD card (where my CoreELEC is running).
I'll see if I can do something about CacheTexture function - thanks for the tip.
For the heck of it, I thought I'd try to put the Thumbnails directory in some weird place - I tried /dev/null and a write-protected directory. As expected, in both cases I saw no artwork when running the slide show. Yup, no easy workarounds here
I am having trouble with AS and my preferred skin Aeon MQ8. When in Music Fullscreen the artwork displays in front of and blocks the visualization. I see that you have setting in your Estuary Mod to turn this on/off. Any thoughts on how to fix this for Aeon MQ8 @
pkscout?
Thx
(2020-01-10, 23:10)jasn Wrote: [ -> ]I am having trouble with AS and my preferred skin Aeon MQ8. When in Music Fullscreen the artwork displays in front of and blocks the visualization. I see that you have setting in your Estuary Mod to turn this on/off. Any thoughts on how to fix this for Aeon MQ8 @pkscout?
Thx
That's a skin decision and best asked in the Aeon MQ8 support thread (if there is one). If you have some understanding of XML you could look at the MusicVisualization.xml file in the Aeon MQ8 thread. Basically Kodi loads and layers skin items in the order they are in the file, so the stuff near the top loads first and further towards the "back."
(2020-01-10, 23:54)pkscout Wrote: [ -> ] (2020-01-10, 23:10)jasn Wrote: [ -> ]I am having trouble with AS and my preferred skin Aeon MQ8. When in Music Fullscreen the artwork displays in front of and blocks the visualization. I see that you have setting in your Estuary Mod to turn this on/off. Any thoughts on how to fix this for Aeon MQ8 @pkscout?
Thx
That's a skin decision and best asked in the Aeon MQ8 support thread (if there is one). If you have some understanding of XML you could look at the MusicVisualization.xml file in the Aeon MQ8 thread. Basically Kodi loads and layers skin items in the order they are in the file, so the stuff near the top loads first and further towards the "back."
That's just what I needed to know. Thanks.
I'll take a look at the xml file.
@
pkscout Thanks again for your work - things improved dramatically for me! I tested your latest beta2, and the new "picture pause" functionality is great! I didn't see any change in the initial black screen timing - it is still the same 94 seconds (over SMB), but when I switched to a local copy, this became a non-issue (down to only 3-5 seconds of black screen, and only at the start of the slideshow). As I suspected, SMB is very bad for things like getting a list of 16,000 files, even over gigabit ethernet - the problem is with the large latency when dealing with files metadata. But now it's not an issue - I'll just have to maintain the local copy of my 4K photos, using rsync over ssh from my main desktop.
As to the caching issue - I'll bring it up in the core Kodi thread, asking to make no-caching available at least for addons, and only for specific situations (like artwork in slideshows). For now, I'll just run a system command inside your Python script to delete thumbnails and the database every time the slideshow stops. Not ideal, but I think it'll do.