RPi4 - Music playback skips, Video fine

Hi,

I’ve been using OSMC for years (in fact I just noticed the input on my TV is still labelled “RaspBMC”) but since an OSMC update mid last year (possibly the May update, possibly August) I’ve been having a really annoying issue. Specifically music files intermittently skip during/before playback but video files play back without problem; the issue persists now, running the October 24 update.

In more detail, I use an RPi4 in one room as a media centre and often put on music party mode in that room, or play an album etc. Intermittently a playing music file will prematurely skip to the next track in the playlist or just be skipped before it even starts. This is intermittent, it’s not always the same file, it’s not always the same place in the file. Often, you can go back one track in the playlist and the file will play through again without fault.

There are no faults playing video files be it old SD AVIs, 1080p x264 with DTS audio streams, 720p x265 - all play fine.

All media files, (music/video) are located on the same remote NAS and are served from there via samba. The pi mounts the remote share via etc/fstab. The music library is running on MariaDB on another server on the network. The RPi 4 uses a wired network connection.

A second RPi3B+ in another room running OSMC October24 also has the identical problem however it is connected via WiFi.

Kodi on a windows PC with wired network connection does not have the problem.

Kodi running on Linux (Ubuntu and Mint) PCs do not have this problem, wired network, one even quite far away at the end of a powerline network adaptor.

Jellyfin streaming to multiple clients (Windows, Android, MacOS, Linux) does not have the problem.

I included the above 3 lines to show that smb sharing is alive and well on my network setup and this issue does at least seem to be isolated to the OSMC instances. All of them access the same files on the same NAS using the same protocol.

Looking through debug logs on the raspberry pi, there is just a generic “SMB: Software caused connection to abort” error when the files skip and not a lot else error-wise. Readfile fails to read the file and then it skips to the next track.

I haven’t yet tried reverting to a previous OSMC version as I need to sort another microSD card for that. It’s also worth mentioning that my NAS is running very old version of samba v3.6 with no chance of upgrading it and thus is limited to protocol version 2.0 but, critically, this hasn’t been a problem in the past with OSMC and other systems on the network seem just fine with it…

I’m happy to test things out and submit logs if that’s useful but also if anyone can point me in a direction or if Sam can point to something, possibly samba related, that might have changed in mid-2024 to cause these issues it would be much appreciated.

TIA

I’d setup a source in music>files using a Kodi SMB path, not scraped, and see if the problem presents itself playing from there. You may also need to go to settings>services and set max SMBv2 as well. If it doesn’t display an issue there then perhaps you could look at your mount options for tweaks you can make there like specifying a different SMB version.

Thanks for this.

The problem with an intermittent fault of course is it’s not easy to reproduce on command! Playing some audio via music>files for about 30 mins and it did not skip. Went back to library > music party mode and it skipped the second track after about a minute. My only issue here is that it didn’t ask for new credentials to connect as presumably the share is already active via the CIFS mount in fstab.

settings>services was set to min SMBv1, max SMBv3 but of course this is a global setting that would affect all shares not just music specifically? (all music and video files hang off the same share and are not mounted separately) Do we know if the max SMBv2 setting in Kodi actually refers to SMBv2.0 (vista era) or SMBv2.1 (win7 era)?

EDIT/
Setting min value to SMBv2 renders the share inaccessible so therefore Kodi setting “SMBv2” == SMB protocol v2.1 as the server supports max v2.0 (v2.02, technically)
/EDIT

Section of log file where skip occured, I note it struggling to load the cover image for the previous track as well:

2025-01-22 18:29:00.501 T:560      info <general>: PARTY MODE MANAGER: Playing song at 0
2025-01-22 18:29:00.856 T:20720    info <general>: CDVDAudioCodecFFmpeg::Open() Successful opened audio decoder mp3float
2025-01-22 18:29:01.013 T:20720    info <general>: AudioDecoder: File is queued
2025-01-22 18:29:01.029 T:20720    info <general>: PAPlayer::PrepareStream - Ready
2025-01-22 18:29:01.050 T:20717   error <general>: SMBFile->Open: Unable to open file : 'smb://USERNAME:PASSWORD@REDACTED_SERVER_IP/media/Music/Contemporary/Ramones/>
                                                   unix_err:'67' error : 'Software caused connection abort'
2025-01-22 18:29:07.856 T:20721    info <general>: CDVDAudioCodecFFmpeg::Open() Successful opened audio decoder mp3float
2025-01-22 18:29:08.003 T:560      info <general>: PARTY MODE MANAGER: Adding randomly selected song at 9:[musicdb://songs/215317.flac]
2025-01-22 18:29:08.087 T:20721    info <general>: AudioDecoder: File is queued
2025-01-22 18:29:08.098 T:20721    info <general>: PAPlayer::PrepareStream - Ready
2025-01-22 18:29:08.142 T:589     error <general>: SMBFile->Open: Unable to open file : 'smb://USERNAME:PASSWORD@REDACTED_SERVER_IP/media/Music/Contemporary/Reinhard>
                                                   unix_err:'67' error : 'Software caused connection abort'
2025-01-22 18:29:08.142 T:20736   error <general>: Read - Error( -1, 103, Software caused connection abort )
2025-01-22 18:29:08.143 T:20736 warning <general>: CFileCache::Process - <smb://REDACTED_SERVER_IP/media/Music/Contemporary/Reinhardt, Django/1996 - The Best of Djan>
2025-01-22 18:29:08.143 T:589     error <general>: [ script.embuary.helper ] Image error: Could not get image for smb://REDACTED_SERVER_IP/media/Music/Contemporary/R>
2025-01-22 18:29:10.143 T:20736   error <general>: Read - Error( -1, 103, Software caused connection abort )
2025-01-22 18:29:10.143 T:20736 warning <general>: CFileCache::Process - <smb://REDACTED_SERVER_IP/media/Music/Contemporary/Reinhardt, Django/1996 - The Best of Djan>
2025-01-22 18:29:12.020 T:20721    info <general>: CDVDAudioCodecFFmpeg::Open() Successful opened audio decoder mp3float
2025-01-22 18:29:12.049 T:560      info <general>: PARTY MODE MANAGER: Adding randomly selected song at 9:[musicdb://songs/223875.mp3]
2025-01-22 18:29:12.209 T:20721    info <general>: AudioDecoder: File is queued
2025-01-22 18:29:12.212 T:20717   error <general>: Read - Error( -1, 103, Software caused connection abort )
2025-01-22 18:29:12.212 T:20717 warning <general>: underflow: Error reading file - assuming eof
2025-01-22 18:29:12.220 T:20721    info <general>: PAPlayer::PrepareStream - Ready
2025-01-22 18:29:12.231 T:20740   error <general>: Read - Error( -1, 103, Software caused connection abort )
2025-01-22 18:29:12.232 T:20740 warning <general>: CFileCache::Process - <smb://REDACTED_SERVER_IP/media/Music/Contemporary/Shlohmo/EPs and Singles/2010 - Camping/01>
2025-01-22 18:29:14.232 T:20740   error <general>: Read - Error( -1, 103, Software caused connection abort )

- repeats for many lines -

2025-01-22 18:30:54.262 T:20740 warning <general>: CFileCache::Process - <smb://REDACTED_SERVER_IP/media/Music/Contemporary/Shlohmo/EPs and Singles/2010 - Camping/01>
2025-01-22 18:30:56.263 T:20740   error <general>: Read - Error( -1, 103, Software caused connection abort )
2025-01-22 18:30:56.263 T:20740   error <general>: Process - <smb://REDACTED_SERVER_IP/media/Music/Contemporary/Shlohmo/EPs and Singles/2010 - Camping/0106 - Spoons >
2025-01-22 18:30:58.033 T:20739    info <general>: PAPlayer::ProcessStream - Stream Finished
2025-01-22 18:30:58.241 T:20749    info <general>: CDVDAudioCodecFFmpeg::Open() Successful opened audio decoder aac
2025-01-22 18:30:58.396 T:20749    info <general>: AudioDecoder: File is queued
2025-01-22 18:30:58.407 T:20749    info <general>: PAPlayer::PrepareStream - Ready
2025-01-22 18:30:58.476 T:560      info <general>: PARTY MODE MANAGER: Adding randomly selected song at 9:[musicdb://songs/231151.m4a]
2025-01-22 18:32:54.569 T:560      info <general>: Loading skin file: MyMusicNav.xml, load type: KEEP_IN_MEMORY
2025-01-22 18:33:00.577 T:20756   error <general>: Read - Error( -1, 103, Software caused connection abort )
2025-01-22 18:33:00.582 T:20756 warning <general>: underflow: Error reading file - assuming eof
2025-01-22 18:33:00.582 T:20755   error <general>: Read - Error( -1, 103, Software caused connection abort )
2025-01-22 18:33:00.582 T:20755 warning <general>: underflow: Error reading file - assuming eof
2025-01-22 18:33:00.583 T:20760   error <general>: Read - Error( -1, 103, Software caused connection abort )
2025-01-22 18:33:00.583 T:20760 warning <general>: underflow: Error reading file - assuming eof
2025-01-22 18:33:39.114 T:20765    info <general>: CDVDAudioCodecFFmpeg::Open() Successful opened audio decoder flac
2025-01-22 18:33:39.330 T:20765    info <general>: AudioDecoder: File is queued
2025-01-22 18:33:39.341 T:20765    info <general>: PAPlayer::PrepareStream - Ready
2025-01-22 18:33:43.845 T:20739    info <general>: PAPlayer::ProcessStream - Stream Finished
2025-01-22 18:33:43.925 T:560      info <general>: PARTY MODE MANAGER: Adding randomly selected song at 9:[musicdb://songs/211807.mp3]

Is it possible to get a full log set instead of this log snippet?

You can learn more about how to submit a useful support request here.

Depending on the used skin you have to set the settings-level to standard or higher, in summary:

  • enable debug logging at settings->system->logging

  • reboot the OSMC device twice(!)

  • reproduce the issue

  • upload the log set (all configs and logs!) either using the Log Uploader method within the My OSMC menu in the GUI or the ssh method invoking command grab-logs -A

  • publish the provided URL from the log set upload, here

Thanks for your understanding. We hope that we can help you get up and running again shortly.

OSMC skin screenshot:

No, Kodi would not pick up your credentials from fstab. If Kodi needed credentials and didn’t ask for them then you had previously entered them for that source and they got saved to ~/.kodi/userdata/passwords.xml

This would affect all paths where the source was using a network path which means that Kodi is doing the networking itself. It does not interact with the underlying OS so mount points are not affected.

You said you were using a system mount. From that log it seems your music library is configured using Kodi paths. You could try using max SMBv1, or you could test your mount point to see if it works better with that NAS. If the mount point works better you can use path substitution to reroute the path stored in your MySQL db to the local mount without affecting other clients.

Hi,

Thanks for the replies, sadly life and work gets in the way of tinkering with SBCs and Kodi!

Darwindesign, you are absolutely correct in what you’ve said about fstab. From memory I believe this is a hangover from a previous setup that I’ve just brainlessly copied forward over the years (bearing in mind that I’ve been running raspbmc/osmc on various Pis since about 2013 on a Pi 1 model B!). Safe to say it is redundant and has been removed now.

I’d obviously re-done this in the past anyway as indeed credentials are stored in the file you suggested along with some also now redundant path substitution in the paths xml file. All of that is somewhat by-the-by though as it had been working fine with all those redundant settings up until mid last year. However I believe I’ve actually now found the problem…

Towards the end of 2023 (and I believe pushed into the 21.0 release of Kodi, the default SMB chunk size was changed from 64KB to 128KB and that is what was causing all my problems. That means that the August update of osmc will have been the start of my issues. Resetting it back to 64KB on the SMB-Client settings page and everything has returned to normal, working state. Interesting that this change only affected smaller files (music, art for music and movies) but larger files like movies played absolutely fine. I did read that SMBv1 only supports chunk size of 64K so its possible that forcing the protocol to SMBv1 would have fixed this too if opening a security hole in the process.

Thanks again but this is solved for now!