I own a Vero4K+ since one year now. It is great for music and video, but absolutely unusable (for me) when it comes to browsing my photo library. I have it in a Synology NAS in the local network, and I connect to the folder using SMB or NFS.
The situation is really frustrating because the thumbnail generation process (activated to generate thumbnails when I open a folder) is causing the unit to reboot even after creating a few thumbnails (10 o 15). It seems that there’s a memory leak or some kind of bad coding in the process that result in a constant reboot of the Vero, so I always abandon the idea of using it to browse my library. Even with the browser of my LG OLED TV the experience is better!
I have identified that the larger the photos are, the less the unit is able to resist without rebooting. Also, the larger the amount of photos in the folder, the higher probability to get a reboot.
I can understand that the unit has limited resources, but there should be some kind of code able to reduce the amount of memory allocable to this process, even if it means a slower thumbnail generation.
There’s also no posibility to generate these thumbnails during night, letting the unit to work only on this, because afaik the only way to force the thumbnail generation is opening the folders.
Advice and comments about this are really welcome. For me, picture browsing is one of the most important use cases of this product.
Can you post some debug logs when this occurs?
My suggestion is to wait for Kodi v19, which will be available soon. There may be some improvements here in this regard. Unfortunately Kodi v18 is now end of life, and we won’t be updating it further
Another thing: are you sure the device is rebooting? That would be surprising. Maybe you see OSMC logo / sad face instead, which would indicate that Kodi is crashing.
Thanks a lot for your quick answer. The images are usually regular jpeg images taken with my Nikon d5100 (16mpx I guess).
You can get the log I’ve just uploaded in http://paste.osmc.tv/kimenasore. Let me know if it is ok for you. I’ve activated de debug log in settings, browsed one folder of photos and waited for the “sad face” to appear. After reboot I’ve used the OSMC plugin log uploader feature.
Sorry for the lack of precision. Yes, Kodi crashes. Indeed the behaviour is worse if I browse photos while the library is updating (very usual after the crash if the setting is activated to update library after boot).
The folder that caused the crash in the log has 220 photos. I have folders with less and others with much more photos. Indeed I was forced to disable the option to fetch EXIF data to avoid Kodi to make me wait almost one minute in some cases just to open the folder when it has several hundreds of photos (mobile backup, for instance). The good thing is that already created thumbnails load very fast.
Thanks again for your support Sam. Do you think that v19 could be the solution for this memory issue? Do you recommend setting some kind of swap partition in a USB memory sticknor any other workaround?
@sam_nazarko This doesn’t meant to be pushing at all, just connecting the two cases:
However, I presume it’s not really needed; I know Sam is pretty much aware of this, on the other hand it also seems to be an issue more on Kodi than OSMC side…
I recognise the problem. In Synology DSM search for Thumbnails. There is an option DSMs Mediaserver that sends low-res images to of DMAdevices and not the full-res ones. This speeds up browsing and indexing on the Vero tremendously. The only downside is the preview Thumbs look poor.
I don’t know why my DLNA Server (Synology) is not detected by Vero. BTW, I’ve observed that Kodi crashes much less frequently while generating thumbnails when the source is connected using Samba instead of NFS.
Your log shows that you have some significant network-related problems. For example your device cannot hold onto an IP address:
Feb 20 10:28:36 osmc avahi-daemon[278]: Joining mDNS multicast group on interface eth0.IPv4 with address 169.254.195.221.
Feb 20 10:29:26 osmc avahi-daemon[278]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.1.4.
Feb 20 16:57:49 osmc avahi-daemon[278]: Joining mDNS multicast group on interface eth0.IPv4 with address 169.254.31.85.
Feb 20 16:58:38 osmc avahi-daemon[278]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.1.4.
Feb 21 16:46:05 osmc avahi-daemon[278]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.1.129.
Feb 21 17:10:54 osmc avahi-daemon[278]: Joining mDNS multicast group on interface eth0.IPv4 with address 169.254.128.22.
Feb 21 17:11:45 osmc avahi-daemon[278]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.1.4.
Those 169.254 addresses occur when it cannot get a DHCP address. (You’ll see why in a moment.)
We see four “link is down” messages:
Feb 20 10:27:16 osmc kernel: libphy: stmmac-0:00 - Link is Down
Feb 20 16:55:55 osmc kernel: libphy: stmmac-0:00 - Link is Down
Feb 21 12:12:09 osmc kernel: libphy: stmmac-0:00 - Link is Down
Feb 21 17:08:34 osmc kernel: libphy: stmmac-0:00 - Link is Down
which suggest that there is no ethernet connection to the router/switch. The links return at:
Feb 20 10:27:50 osmc kernel: libphy: stmmac-0:00 - Link is Up - 1000/Full
Feb 20 16:57:03 osmc kernel: libphy: stmmac-0:00 - Link is Up - 1000/Full
Feb 21 16:45:54 osmc kernel: libphy: stmmac-0:00 - Link is Up - 1000/Full
Feb 21 17:10:09 osmc kernel: libphy: stmmac-0:00 - Link is Up - 1000/Full
Notice that the down link at 12:12:09 didn’t return ultil 16:45:54!
Finally, your ethernet interface is also showing almost 50,000 dropped packets. That is too high.