(2016-03-21, 23:35)marcelveldt Wrote: Supported platforms for local playback
- Windows (32/64 bits) with 32bits Kodi [note: Kodi v18 with 64bits Kodi version not supported due to a python bug]

(2018-07-14, 15:40)jjsr1980 Wrote: All fine I had to play around with Spotify connect in this addon. Right now it works !!

(2018-09-20, 17:19)ozboss Wrote: Hello I tried the addon and i can log in, select and play songs, but i get no sound just a click at the start and then nothing.
Movies and other sound files play without problem in Kodi.
I also tried a fresh install of Kodi but still the same issue with Spotify....
(Using Kodi beta2 and Spotify 1.1.58 on Windows 10 64bit)

(2018-03-15, 16:06)adixor Wrote: Hi all

(new here)

I have installed the latest version today (1.1.46) on RPI3 + OSMC + Kodi latest (17.6) but unfortunately I have encountered the dreaded 2.40 min problem (play stops after 2.40, CPU goes very high for few seconds then system skips to next song and everything happens again in a loop ).

I have tried to debug it more and saw that basically the spotty-muslhf process seems to die after getting the first part of the song (seen as <defunct> in ps axufw) and once kodi wants to buffer some more data (around minute 2:20-2:30) multiple such pspotty-muslhf processes get spawned FOR THE SAME TRACK and they consume A LOT OF CPU. Due to that apparently the curl cannot get the data anymore (a tcpdump shows TCP Window 0 messages as the system cannot cope with the curl transfer) and then.. well everything dies and we start again with the next song.

I was able to find a workaround though! apparently on RPI the kodi cache is around 20MB (which I understand means it consumes 60MB of RAM, don't ask me why, ask https://kodi.wiki/view/Video_cache).
I modified that value to be 80MB (which I guess will consume 240MB but I  did NOT yet see that, memory consumption is the same) but it works, play does not stop anymore! Well,. maybe for songs more than 10minutes it will, but I don't listen much to those.

Here's my /home/osmc/.kodi/userdata/advancedsettings.xml if you want to try:

osmc@osmc:~/.kodi/userdata$ cat advancedsettings.xml
<?xml version="1.0" encoding="utf-8"?>
<advancedsettings>
        <network>
                <autodetectpingtime>30</autodetectpingtime>
                <curlclienttimeout>10</curlclienttimeout>
                <curllowspeedtime>3</curllowspeedtime>
                <curlretries>3</curlretries>
                <disableipv6>true</disableipv6>
<!--            <cachemembuffersize>0</cachemembuffersize> -->
        </network>
        <cache>
                <buffermode>1</buffermode>
                 <memorysize>80971520</memorysize>
                 <readfactor>10</readfactor>
        </cache>
</advancedsettings>


I have also modified some of the CURL variables above (default timeout was 5, def speedtime was 1 (I also saw messages related to this when the issue happens), curlretries was 2). Anyway, not sure about the CURL variables and I don't think they are related, I think it's related with the memorysize value which was about 20000000. Try it, maybe it will work for you.

If that is indeed the cause (cannot test now more on this),  then the exact 2:40 timemark might be caused by the default kodi value for the buffer on RPI systems. I mean not caused but that may be a factor, the issue still seems to be related with spotty-muslhf doing something wrong somewhere but it's a binary, not much I can investigate there. The multiple <defunct> spotty-muslhf children of kodi.bin do not look good though...

Curious if that helps anyone.

adixor