WMA Lossless Audio file Causing Vero 4K+/Kodi to Crash (Sad Face)

WMA Lossless Audio file Causing Vero 4K+ to Crash (Sad Face)

I have noticed this problem on my Vero 4K+ using software version ‘OSMC August 2021 2021.08-1’. Its worth noting that this did not happen with the previous November 2020.11-1 stable software release.

The following - Windows Media Audio 9.2 Lossless (16bit 44kHz Stereo) audio file causes the my Vero 4K+ to crash (sad face) and reboot
when either:

  1. An attempt is made to play the audio file by manually navigating to it, or
  2. During a library scan.

The WMA file and associated media information can be found here - WMA Problem Files

With debug logging enabled I performed the two basic methods of accessing the WMA file.
The debug logfiles collected during these simple test can be found here - removed

In both cases accessing the WMA file resulted in a segmentation fault (at line 212) of the mediacenter (Kodi)

  1. Manual navigation:

Aug 26 14:48:50 osmc mediacenter[2379]: /usr/bin/mediacenter: line 212: 2832 Segmentation fault sudo -u osmc MALLOC_MMAP_THRESHOLD_=8192 LIRC_SOCKET_PATH=/var/run/lirc/lircd $KODI --standalone -fs
Aug 26 14:48:50 osmc mediacenter[2379]: Kodi exited with return code 139 after 0 hours, 8 minutes and 15 seconds

  1. During a library scan:

Aug 26 14:49:55 osmc mediacenter[2379]: /usr/bin/mediacenter: line 212: 3140 Segmentation fault sudo -u osmc MALLOC_MMAP_THRESHOLD_=8192 LIRC_SOCKET_PATH=/var/run/lirc/lircd $KODI --standalone -fs
Aug 26 14:49:55 osmc mediacenter[2379]: Kodi exited with return code 139 after 0 hours, 0 minutes and 54 seconds

Kodi is clearly not handling these (somewhat deprecated) WMA audio files properly.

Not really a problem for me personally, as I have removed the offending file from my library, but this certainly will be an issue for others I guess.

Can you try and play the file locally?

If it’s one file only causing this issue, then the file may be corrupted. I agree that Kodi should behave better in this case however.

OK - just checked this, plays fine locally from a SD Card (/home/osmc/Music), so I guess its not the WMA file itself and so it must be SMB/Kodi related as I was accessing the file via SMB.

Also plays fine with VLC (locally on a PC) too.

Indeed – you could check SMB settings under Settings - > Services or consider an OS level mount.


Easiest way to do an OS level mount, as Sam suggested, is autofs:

Just to be clear, I have only had this issue with the ‘.wma’ file type (noting that this one is lossless, most normally aren’t) using SMB (‘out of the box’ on OSMC, without autofs). Infact I have tried several .wma files and the same problem occurs with all of them.

All other file types I use (mainly MKV, MP4, FLAC, MP3) have been fine.

Consequently I really do not need to consider autofs, but thanks for the advice - I might give it a go and see if this approach handles .wma files properly.

Just a reminder too that I did not have this issue with this file with the previous November 2020.11-1 stable software release.

Thank you again for a great product - the support is tremendous too !

1 Like

Got as far as ‘Permission Denied’ error trying to get autofs working with SMB v3 on a Win10 Server. autofs debug output (autofs -f -d -v), while attempting a ‘-ls -alh /mnt…’ on another ssh shell:

mount_mount: mount(generic): calling mkdir_path /mnt/nuputer10/#flacs
mount_mount: mount(generic): calling mount -t cifs -o rw,credentials=/home/osmc/.smbcredentials,iocharset=utf8,uid=osmc,gid=osmc,vers=3.0 // /mnt/nuputer10/#flacs
>> mount error(13): Permission denied
>> Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
mount(generic): failed to mount // (type cifs) on /mnt/nuputer10/#flacs
dev_ioctl_send_fail: token = 2
failed to mount /mnt/nuputer10/#flacs

Looks like this could take ages to work out, judging by progress in other threads on this subject. So I gave up … at least I have SMB working out of the box…

I’ve never managed to get autofs working using a credentials file, but it works perfectly if I include the username and password directly in the mount settings.

1 Like

I’d have to test this, but the # may be confusing things. Normally a # means the beginning of a comment. What does your /etc/auto.shares look like?

1 Like

I try ‘in-lining’ the smb credentials in the mount settings and dropping the # - later.

I hope that using autofs will resolve the (original) .wma file problem.

Can any one else try a .wma audio file over SMB/autofs on the latest (Vero4K) stable SW release ?

Seems to be a problem accessing the file you linked.

I don’t have any issues playing compressed wmas.

Did you tried to play the file locally? Does that solve the problem?

Can you link to a public wma file online

There’s a D/L link in the first post.

Here’s a new link

Infact I tried two other files, same result in each case. I’ve copied those to the D/L link above too.

Yes I did play it locally (copied it to /home/osmc/Music).

Playing it local doesn’t solve the problem. Thats the whole point, they will play locally but not over a network/SMB. There was no trouble with this in the previous Vero4k+ stable release from November 2020.

I am trying autofs with SMB as I write this, as suggested in an earlier post (rather than via the OSMC menus, to set up an SMB share). I will let you know how I get on.

Still having problems

Try the link again, and hit select all, a box should appear saying download click on that to start the D/L
It works in my part of the world …


Try this url

So, I eventually managed to get autofs working (i’ll come to that later) and consequently by adding a new music source using a autofs/SMBv3 mount (via a selection from the root filesystem - /mnt in the OSMC menus) I was able to play the wma files without any problem.

Using the ‘out of the box’ SMB method of sourcing music (via the on screen menus) and playing WMA files causes Kodi to crash with a segmentation fault at line 212, as already described.

Setting up autofs was straightforward, once I discovered that it was not possible use a .smbcredentials config file (for SMB username/password) - it simply doesn’t work, and I had to specify the username/password in the /mnt specification for autofs. fzinken please update your ‘how to guide’ for this - were you able to get an .smbcredentials file to work with SMBv3 ?

Myself and many other people have it working without any issues. That there are problems with it first time was heard from @angry.sardine and yourself.
I am happy to investigate, at this moment the only thought I have is either space or other special characters in username or password. Maybe try with an easy simple character username and password as a test. We can take it further in the autofs thread

1 Like

Thank you.