While this is a Kodi issue, I am not getting answers from the Kodi forum, perhaps experts here can throw some light. I have a folder with over 5000 photos and videos which are being continuously displayed as a recursive random slideshow, essentially a digital photo/video frame. The application will crash after sometime, faster with Pi’s that have lower RAM, Pi 3A+ for example. 3B+ is better, but will still eventually crash. 4B with 2GB RAM seems to work okay. I tried installing Kodi on Raspbian, and if swap is disabled, it will crash faster. OSMC probably disables swap as a default? The issue is likely due to the fact that Kodi stores metadata of all the media files before playing them. Crashes with very large Number of jpg images is a link to an old thread in which I have asked the same question on the Kodi forum.
We disable swap by default, but it can be enabled.
If it’s affecting Kodi on other platforms, then it’s an upstream issue. Unfortunately the photo viewer is inefficient and needs a re-work.
Sam
What are the cons of enabling swap, does it reduce SD card life and the corruption probability is higher? If the issue is with memory needed for media file metadata, why would it take so long for the application to crash, wouldn’t it show up right away? Memory usage seems to be okay, as seen from the ‘free -mh’ command, even on the Pi 3A+, at least initially. Playling Playlist dies after about 7 minutes - possible memory leak? - #16 by sam_nazarko - this was the other thread with a similar issue in which I had posted earlier, lot of experimentation that doesn’t seem to be going anywhere!
It will cripple performance and also reduce SD card lifespan.
That’s not the issue.
The post in the Kodi forum said the following, is that not correct? Will creating sub-folders containing smaller numbers of photos/videos help at all?
But still you have the limitation that kodi will process every jpeg in a folder before displaying the first.
With enough photos in a single directory you will crash kodi on any platform. It will also be slow.Ideally kodi would just load the information for the photos that are required to display the current screen
and only load more as required (e.g. when scrolling). But that is not how kodi is designed.
Yes but this won’t be metadata – this will sadly be a combination of memory leak and bad architecture.
It needs resolving upstream.
Thanks! Perhaps the OSMC team has an inside track to the Kodi team and can bring this up for resolution in an upcoming release, as it impacts all platforms and distributions. Are there any photo/video player programs that can run on Raspbian and mimic this digital photo frame feature? I tried VLC media player, but it has its own quirks.
I am a Team Kodi member – but Team Kodi is a group of volunteers and unless someone wants to work on this section, it likely won’t receive a lot of attention.
Thanks for the feedback. Will stopping and restarting Kodi every day help in preventing this crash, assuming of course that it will take more than a day for it to happen?
It might do - but it’s no magic bullet
Sam
Another experiment! BTW, the issue with VLC player is posted in Photo slideshow on Raspberry Pi 3B+ crashing - The VideoLAN Forums, there is some problem with high resolution jpegs. If you have any pointers, it would be greatly appreciated!
VLC is a completely different project and isn’t something we can advise on unfortunately
Sam
The workaround I’d use is to limit the list of images to 1000 total for any session. How to best accomplish that would depend on the directory structure.
I have just under 30,000 photos in my collection. While I don’t use kodi/osmc to run any slide shows (I use feh), mine are organized by
yyyy/mm/, going back to the early 1982. Prior to then, I have all the photos grouped together. Really, any decade can be grouped together prior to 2008 for my photos - pre-digital cameras. In 2008, I took over 9,400 photos. Did lots of international traveling that year - 5 continents.
To get a count of photos, something like:
$ find gallery/2008 -type f -iname \*jpg | wc -l
9403
$ find gallery/2012 -type f -iname \*jpg | wc -l
3589
I’d probably just create a single file with all the image files listed, then use ‘split’ to split the file at a certain number of lines. Just RTFM any commands you don’t already know.
I definitely want to have both photos and videos being shown together, in a random fashion, so Kodi or VLC seem to be the best options. It would be good to know the exact limit, unless of course the issue will show up regardless, with higher frequency of a crash with higher number of files.
I’d be surprised is there were any limits in the software. They typical limits would be the size of a signed integer or unsigned integer. Both are huge, even for 32-bit CPUs. 2,147,483,647 - Wikipedia is more photos and videos than I have by over 1000x. That’s the signed integer limit - unsigned is much larger.
I’d expect any limits to be from hardware and other software running on the system.
Kodi 20 crashes when playing recursive slideshow · Issue #22643 · xbmc/xbmc · GitHub - this seems to indicate that the problem was not there with 19.5 and only with 20 on Windows 10 platform, but that is not the case with the Pi, the issue manifests itself with 19.x releases also. Many people seem to report the same issue on different platforms with different Kodi versions, but the logs rarely show anything, so the issue get closed and it doesn’t get further attention. How to resolve this stalemate and get some action from Kodi?
Have you tried the v20.1 test builds first?
Sam