My Vero4k+ has been crashing during playback (showing the blue sad face screen and rebooting). So I enabled logging, and rebooted. Started playing a video and it crashed (blue sad face) after a few minutes when I was skipping backwards and forwards a few times.
Then I went to MyOSMC to upload the logs and it crashing while doing that.
Then I uploaded the logs again. Here are the link to the logs. Can someone tell me what to do to make it stable?
If we need a more accurate diagnosis we would need to reduce the log size.
Sadly no – but you could remove half the files in one directory to another one. If it doesn’t solve the problem, remove the other half. Then you can halve that half until you find the culprit. It’s tedious but should not take too long.
Alternatively you could use something like MediaInfo to recursively find MJPEG files.
Kodi is crashing because it’s trying to generate thumbnails from a video you’ve recently added or scan the library. So if it helps to narrow it down, I believe it’s something that you’ve added recently, or since the crashing began. If you haven’t added anything recently, then sadly something has become corrupted.
The crashing has been happening for quite some time, it’s only just today that I bothered to do something about it. The crashing is also inconsistent, it might go days without crashing.
I have quite a large library. What can I do to produce better logs to identify the offending file?
I’m thinking that telling Kodi it can cache to RAM using more space than what actually exists and completely saturating your NIC at the same time might not be a recipe for a good time. The default cache settings on the Vero’s is already quite large and I really don’t think with testing you will find that an even larger buffer will provide benefit.
I have 2 other Vero4k+ units, which I have set up in remote locations, using VPN back to my home network. The VPN is not very fast, so it is beneficial for me to have the largest possible buffer size and to saturate the network connection. Then I can pause and let it buffer. However, this particular unit is on my home network directly (WiFi) and so it does not have a buffering issue, but I thought it was no harm in leaving to my standard settings.
I understand I have the memorysize parameter set to 2097152000 bytes, which is 2097152000/1024/1024 = 2000MB.
My own testing yesterday has shown with that setting of 2000MB, I started playing a large video then paused it immediately. At the start, the on-screen debug stats showed:
MEM: 1627972/2035888 KB [1590/1988 MB free].
I left it paused for a few minutes and watched it chew up the RAM and buffer. It stopped buffering and the on-screen debug stats showed:
MEM: 391568/2035888 KB [382/1988 MB free].
So, even set to 2000MB, it only used 1208MB, and left 382MB free.
Also, the query about the advancedsettings memorysize and readfactor are very different possible problems to the possible corrupt MJPEG file(s) suggested by Sam.
I am away at the moment, but when I get back home, I’ll return advancedsettings to default and see how it goes. However, I would also like to explore the corrupt MJPEG file(s) issues. Sam, any advice here?
Kodi’s cache settings are a tricky thing. Kodi does adjust it according to the file being played but generally speaking every time I’ve ever tested it I found that once I go too large or fill the buffer too fast I end up in a situation where at best I improve the playback of certain files while making others worse. Also even though Kodi doesn’t seem to use that 3x the cache size, setting the max cache size to the amount of RAM you have without regards to their needing to be memory for the OS or the rest of Kodi seems problematic. Also OSMC has swapping memory to disk disabled by default so it tends to get a bit upset when the memory starts to fill up.
As for the mjpeg you might try disabling hardware acceleration in the Kodi’s player settings and browse through your library to get it to try caching anything it was tripping up on. I think that setting disables hardware acceleration for thumbnail generation in addition to video playback. That may be enough to get you past the problem.
Sorry for the slow reply. I removed my custom advancedsettings per your suggestion and this type of crash has disappeared.
However, I think the settings I were using do have their place/are beneficial. That said, with this media player installed on my local network, there is ample bandwidth so I don’t need buffering.
I’m glad that got you sorted, but I’d reiterate that Kodi’s cache settings are a tricky thing. The cache settings in the next stable release will now be in the UI as that is one of the updates that were put in Kodi v21. As such the way we were implementing the custom sized cache for the Vero’s needed to be changed so I personally spent a great deal of time testing various cache settings in a variety of setups with different bandwidth available to make sure our defaults were as optimal as possible. I didn’t find that overly large cache sizes were currently able to paper over bandwidth limitations at all. At best they slowed down playback start, at worse they caused playback issues that were not there with more sane settings.
I love that the settings are going to be part of the Kodi interface. I wish that many/all of the advanced settings were intelligently settable via the interface; this would make them more accessible to the user.
I do have a second Vero4k+ at a remote location, which uses vpn back to my home network and has limited-ish bandwidth; 20mbps… although it is unclear how much of this is functionally usable considering vpn and encryption overhead and funny things with the networks.
It has worked quite well for me having the same buffer/other advanced settings. I press play, wait some seconds for it to start and then press pause. I then wait for some minutes and watch the buffering bar grow and grow, then when it has grown as much as it can, I press play and it plays just fine (for the buffered content).
The counter argument to that is the more settings you add the harder it makes it for the average user. The reason most of those settings are not in the UI are because they are so niche that they shouldn’t clutter up the UI for how few users are wanting them, or because the settings are not something that most users should be messing with without a specific understanding of what they do, and possibly downsides and repercussions of enabling the features. I remember many years ago when most people still only had dial-up internet there was a seemingly never ending stream of people who had issues after they changed their cache settings according to something they read from some random person online. I think it made a lot of sense back then to increase the barrier to entry for breaking your Kodi setup that way.
