OSMC/Kodi crashing on specific FLAC file

I was setting up my recently purchased Vero 4k, and the music library scan always crashed after around 10 minutes.

After a few tries, I’ve managed to figure out that the issue is caused by a specific FLAC file - that is, whenever the library scanner got to the folder containing this file the Kodi process simply crashed. The crash can be triggered by simply entering the folder (which is on an SMB share by the way) containing this FLAC file via the file browser too.

This is the file that’s causing the issue: http://nokedli.zahola.net/get/eyJ0eXAiOiJKV1QiLCJleHAiOjE4ODAyMTAyNTB9Cg.eyJwYXRoIjoiL2hvbWUvemF6YS9jcmFzaC5mbGFjIn0K.KHN0ZGluKT0gOTBiMzQ4YjM2YjdhN2E5ZWZiZTZjMWJkNzEzNjVlZmI5MTAwMTNiNGM1MWVjNjVmOGE3Nzc4OWM1OGYzZGI5Ywo

Has anyone experienced similar issues? Is there a way do debug what the problem might be with this file that’s causing Kodi to crash?

I just tried that file on my Pi3b+ over SMB and I could browse, scrape, and play it without issue. Is there any kind of \ / " : < > ; | * ? stuff in any of the file or folder names? I’m assuming your file is not named crash.flac on your system.

It is named crash.flac. Of course the original path wasn’t crash.flac, but even after I’ve copied the file to the root folder of the SMB share, and renamed it to crash.flac, Kodi kept crashing when opening the root folder, so it can’t be path-related.

However, in the meantime I’ve figured out that the issue can be circumvented by removing the PICTURE block from the file like this:

metaflac --remove --block-type=PICTURE crash.flac

After performing this, Kodi no longer crashed…

That’s odd, my system was reading the embedded cover art without issue. I don’t have a Vero to test if there is a platform specific bug.

EDIT: Windows store Kodi over SMB reads cover art and displays no issues as well.

Same here… All my FLACs have embedded cover art: no issues at all (on Vero and Pi).

Maybe have a look at this, @zaza: Music library update crashes 4k - #7 by Chillbo Might not be the issue, but worth a shot.

Yeah, my other files have embedded cover art too and there were no issues with those.

What I did notice however is that this file contains a zero-length padding block at the end of the metadata:

METADATA block #4                        
  type: 1 (PADDING)                      
  is last: true                          
  length: 0                              

I’ve checked my whole library and there were no other files with such a zero-length padding block:

$ find music/ -type f -iname '*.flac' -print0 | xargs -0 metaflac --list --block-type=PADDING | grep 'length: 0' | wc -l
0

And by removing the PICTURE block, the padding was grown by the size of the picture, thus eliminating the zero-length padding block.

I’ll test this hypothesis when I get back home :slight_smile:

Indeed, it’s the zero-length PADDING block, and not the PICTURE block that’s causing the crash. Kodi still crashes even if I delete the PICTURE block but preserve the zero-length padding block like this:

metaflac --remove --block-type=PICTURE --dont-use-padding crash.flac

According to the logs it crashes due to a segmentation fault:

Aug 01 20:12:05 vero mediacenter[2542]: /usr/bin/mediacenter: line 206:  5093 Segmentation fault      sudo -u osmc MALLOC_MMAP_THRESHOLD_=8192 LIRC_SOCKET_PATH=/var/run/lirc/lircd $KODI --standalone -fs
Aug 01 20:12:05 vero mediacenter[2542]: Kodi exited with return code 139 after 0 hours, 7 minutes and 19 seconds

Does this happen on other Kodi platforms?

I’ve checked with Kodi for macOS and it didn’t crash.

Same version?

I think so, both are 18.3:

osmc@vero : ~ $ /usr/lib/kodi/kodi.bin --version
18.3 Media Center Kodi
Copyright (C) 2005-2019 Team Kodi - http://kodi.tv

As I posted above it worked fine on Pi and Windows (current version on both).

Has anyone else reproduced this as a crash on a Vero? I’m struggling…

Maybe @zaza can upload the file in question for us to test with, @sam_nazarko? :slightly_smiling_face:

Sure, here’s the file in question:

http://nokedli.zahola.net/get/eyJ0eXAiOiJKV1QiLCJleHAiOjE4ODAyMTAyNTB9Cg.eyJwYXRoIjoiL2hvbWUvemF6YS9jcmFzaC5mbGFjIn0K.KHN0ZGluKT0gOTBiMzQ4YjM2YjdhN2E5ZWZiZTZjMWJkNzEzNjVlZmI5MTAwMTNiNGM1MWVjNjVmOGE3Nzc4OWM1OGYzZGI5Ywo

Gave it a quick test… Scanning fine into my music library here :man_shrugging:t2:

Very strange! I’ve checked with debug logging enabled, but it didn’t really provide any clue about the nature of this crash. It simply stops after CSMBFile::Open:

...
2019-08-02 19:40:02.578 T:4070248448   DEBUG: CGUIMediaWindow::GetDirectory (smb://192.168.0.24:445/music/)                                          
2019-08-02 19:40:02.578 T:4070248448   DEBUG:   ParentPath = [sources://music/]                                                                      
2019-08-02 19:40:02.579 T:3962110688   DEBUG: Thread waiting start, auto delete: false                                                               
2019-08-02 19:40:02.679 T:4070248448   DEBUG: ------ Window Init (DialogBusy.xml) ------                                                             
2019-08-02 19:40:02.764 T:3962110688   DEBUG: Thread waiting 3962110688 terminating                                                                  
2019-08-02 19:40:02.767 T:4070248448   DEBUG: ------ Window Deinit (DialogBusy.xml) ------                                                           
2019-08-02 19:40:02.776 T:3962110688   DEBUG: Thread BackgroundLoader start, auto delete: false                                                      
2019-08-02 19:40:02.813 T:3962110688   DEBUG: GetSongsByPath query: SELECT * FROM songview WHERE strPath='smb://192.168.0.24:445/music/'             
2019-08-02 19:40:02.816 T:3962110688   DEBUG: CSMBFile::Open - opened smb://192.168.0.24:445/music/crash.flac, fd=10000

Where does OSMC put the core dumps after Kodi crashes?

It will be tricky to debug without the symbol table.

Try disabling HW acceleration. Does it still crash?

Hmm, where do I disable hardware acceleration?

Settings -> Playback