I am experiencing some odd behavior playing music tracks from local storage or via SMB/Library. They are 320kb/s MP3
Tracks will play for a bit then the next track is played.
Setting caching off, the track will play for about 2 seconds before next-ing.
Setting buffering to All filesystems, Mem:32MB, ReadFactor:4x, Chunk size: 128kb - Tracks play about 40 seconds
Tried a recent nightly (10-Sep), same.
Thanks in advance for any insight!
-Ezala
Log extract:
info <general>: CDVDAudioCodecFFmpeg::Open() Successful opened audio decoder mp3float
error <general>: Read - Error( -1, 22, Invalid argument )
warning <general>: CFileCache::Process - <smb://192.168.1.101/Backups/musicshare/Front 242/Back Catalogue/16 Funkahdafi.mp3> source read returned -1! Will retry
error <general>: Read - Error( -1, 103, Software caused connection abort )
warning <general>: underflow: Error reading file - assuming eof
error <general>: Read - Error( -1, 103, Software caused connection abort )
warning <general>: underflow: Error reading file - assuming eof
More info...
- Fresh load 12.0.1 on SD, Wired LAN, no additional addons, SSH enabled
Better description of the problem is that an MP3 file played from an SMB share has issues in v12.0.1
Debug log attached. If I did the research first, I would have posted this as a bug report.
Feel free to delete my mess above
RPi4b, 2Gb, Class10 32Gb SD, Argon ONE V2 Case
To recreate:
The file stops prematurely. About 40 seconds in my case with whatever defaults are in play
debugLog.zip
If I set caching off. the file plays for only a couple of seconds.
**
ahh... tweak and ye shall succeed!!!
I believe the problem is a mismatch between the SMB and Caching chunk sizes out of the box, maybe?
If I match them up, the problem appears to go away... in my minimal testing that is
**
Worked ok on an 18 minute album side!
Do you use Settings->Services->Caching or advancedsettings.xml?
Kodi changed the SMB chunk size defaults in Omega and while these are sensible and reliable defaults for the vast majority of users, a minority might have network setups that require a tweak; hence the controls are in the Kodi GUI.
NB: Unless your network is broken there is no need to fiddle with cache settings. And if the network is broken, the correct solution is to fix the network, not fiddle with caching.
Thanks for the info and the work you all put in.
The infrastructure has not changed, just the version bump on the boxes running within.
4k video has historically worked fine on Pi4's for me via SMB on 11.0.6... and now 12.0.1.
