Playing remote audio fails, logs containe 'ProtocolException: Unexpected status line:'

Hi,

I’m using Yatse 8.5.5/210652 @ Tolriq on Android 4.4.2,
and connecting to Kodi 2:17.4+git20170822.1 on Ubuntu 14.04.5 LTS.

I find I can’t play mp3s, or anything much, from the remote Kodi server. Occasionally if I persist I can play a track, but what usually happens when I play an album is a silent pause, and Yatse moves on to the next track, then another silent pause and the next, until the playlist is finished, or it shows a warning “too many errors, stopping playback”.

Playing audio files locally on the phone seems to work fine. Also, if I download the files first by clicking the down-arrow button, and they get a tick in the corner, they’ll play fine.

Enabling debugging in Yatse, I see the following in the logs (longer snippet below)

HTTP FAILED: java.net.ProtocolException: Unexpected status line: 

There is nothing after the colon. The next line indicates the download is closed.

I infer Yatse is using OkHTTP, which has this error in the source:

It looks like it’s getting a malformed header. But when I download the URL in the logs with wget, I see the following headers, which look normal, and the download works fine:

wget --debug -v  http://192.168.0.51:8080/vfs/%2Fsrv%2FMusic%2FSonics%2FBoom%2FCinderella.mp3Setting --verbose (verbose) to 1
DEBUG output created by Wget 1.17.1 on linux-gnu.

Reading HSTS entries from /home/nick/.wget-hsts
URI encoding = ‘UTF-8’
--2018-08-22 20:41:42--  http://192.168.0.51:8080/vfs/%2Fsrv%2FMusic%2FSonics%2FBoom%2FCinderella.mp3
Connecting to 192.168.0.51:8080... connected.
Created socket 3.
Releasing 0x000055bc60832560 (new refcount 0).
Deleting unused 0x000055bc60832560.

---request begin---
GET /vfs/%2Fsrv%2FMusic%2FSonics%2FBoom%2FCinderella.mp3 HTTP/1.1
User-Agent: Wget/1.17.1 (linux-gnu)
Accept: */*
Accept-Encoding: identity
Host: 192.168.0.51:8080
Connection: Keep-Alive

---request end---
HTTP request sent, awaiting response... 
---response begin---
HTTP/1.1 200 OK
Content-Length: 3955911
Last-Modified: Sat, 13 May 2017 10:45:12 GMT
Expires: Thu, 22 Aug 2019 19:42:09 GMT
Content-Type: audio/mpeg3
Cache-Control: public, max-age=31536000
Accept-Ranges: bytes
Date: Wed, 22 Aug 2018 19:42:09 GMT

---response end---
200 OK
Registered socket 3 for persistent reuse.
Length: 3955911 (3.8M) [audio/mpeg3]
Saving to: ‘%2Fsrv%2FMusic%2FSonics%2FBoom%2FCinderella.mp3’

I’ve even tried to replicate it with this groovy script, that uses okhttp, and it manages to download the file ok. So I suspect the problem is not with the Kodi server,

@Grab(group='com.squareup.okhttp3', module='okhttp', version='3.11.0')
import java.io.IOException;
import okhttp3.OkHttpClient;
import okhttp3.Request;
import okhttp3.Response;

OkHttpClient client = new OkHttpClient();

Request request = new Request.Builder()
    .url('http://192.168.0.51:8080/vfs/%2Fsrv%2FMusic%2FSonics%2FBoom%2FCinderella.mp3')
    .build();

Response response = client.newCall(request).execute();
println response.headers()

I’ve also googled for the exception and related terms and not really found anything, certainly not Yatse related.

A longer segment of the logs surrounding the error. This error is repeated a few times before Yatse stops trying.

2018-08-22 19:04:39.219 Verbose/MusicPlayer: [email protected]: Play: 0
2018-08-22 19:04:39.223 Verbose/MusicPlayer: [email protected]: New audio focus: 2
2018-08-22 19:04:39.224 Verbose/StatusObserver: [email protected]: Status changed: 1
2018-08-22 19:04:39.227 Verbose/MusicPlayer: [email protected]: Acquiring wakelock
2018-08-22 19:04:39.231 Verbose/MusicPlayer: [email protected]: onPlayerStateChanged: true / 2
2018-08-22 19:04:39.234 Verbose/MusicPlayer: [email protected]: Starting playback of: http://192.168.0.51:8080/vfs/%2Fsrv%2FMusic%2FSonics%2FBoom%2FCinderella.
mp3
2018-08-22 19:04:39.235 Verbose/MusicPlayer: [email protected]: onPositionDiscontinuity: 0 [1]
2018-08-22 19:04:39.238 Verbose/StatusObserver: [email protected]: Status changed: 2
2018-08-22 19:04:39.251 Verbose/FirebaseManager: [email protected]: Result: T999
2018-08-22 19:04:39.268 Verbose/MusicPlayer: [email protected]: onTimelineChanged: 0
2018-08-22 19:04:39.269 Verbose/MusicPlayer: [email protected]: onSeekProcessed
2018-08-22 19:04:39.285 Verbose/RemoteMediaItemDataSource: [email protected]: Preparing item: http://192.168.0.51:8080/vfs/%2Fsrv%2FMusic%2FSonics%2FBoom%2FCind
erella.mp3
2018-08-22 19:04:39.286 Verbose/MediaHelper: [email protected]: Media should not use subtitles: Song - audio/mpeg
2018-08-22 19:04:39.293 Verbose/FirebaseManager: [email protected]: Result: T999
2018-08-22 19:04:39.316 Verbose/KodiLogger: --> [221] HEAD http://192.168.0.51:8080/vfs/%2Fsrv%2FMusic%2FSonics%2FBoom%2FCinderella.mp3
2018-08-22 19:04:39.328 Verbose/MusicPlayer: [email protected]: onLoadingChanged: true
2018-08-22 19:04:39.356 Verbose/KodiLogger: <-- [221] 200 OK http://192.168.0.51:8080/vfs/%2Fsrv%2FMusic%2FSonics%2FBoom%2FCinderella.mp3 (35ms, 0-by
te body)
2018-08-22 19:04:39.357 Verbose/KodiLogger: <-- [221] END HTTP (No body, response code 200)
2018-08-22 19:04:39.359 Verbose/KodiLogger: --> [576] GET http://192.168.0.51:8080/vfs/%2Fsrv%2FMusic%2FSonics%2FBoom%2FCinderella.mp3
2018-08-22 19:04:39.454 Verbose/KodiLogger: <-- [576] HTTP FAILED: java.net.ProtocolException: Unexpected status line: 
2018-08-22 19:04:39.456 Verbose/RemoteMediaItemDataSource: [email protected]: Closing item: http://192.168.0.51:8080/vfs/%2Fsrv%2FMusic%2FSonics%2FBoom%2FCinderella.mp3
2018-08-22 19:04:39.466 Verbose/RemoteMediaItemDataSource: [email protected]: Preparing item: http://192.168.0.51:8080/vfs/%2Fsrv%2FMusic%2FSonics%2FBoom%2FCinderella.mp3
2018-08-22 19:04:39.468 Verbose/MediaHelper: [email protected]: Media should not use subtitles: Song - audio/mpeg
2018-08-22 19:04:39.474 Verbose/KodiLogger: --> [844] HEAD http://192.168.0.51:8080/vfs/%2Fsrv%2FMusic%2FSonics%2FBoom%2FCinderella.mp3
2018-08-22 19:04:39.485 Verbose/KodiLogger: <-- [844] 200 OK http://192.168.0.51:8080/vfs/%2Fsrv%2FMusic%2FSonics%2FBoom%2FCinderella.mp3 (8ms, 0-byte body)
2018-08-22 19:04:39.486 Verbose/KodiLogger: <-- [844] END HTTP (No body, response code 200)
2018-08-22 19:04:39.489 Verbose/KodiLogger: --> [340] GET http://192.168.0.51:8080/vfs/%2Fsrv%2FMusic%2FSonics%2FBoom%2FCinderella.mp3

Thanks for trying to help but please just upload the full unaltered Yatse logs and Kodi logs :slight_smile: Including when downloading that file.

I may have a little more experience about what to look after :wink:

Undisputed. Here you go.
kodi.log (98.2 KB)
debug-2018-08-22.log (1.3 MB)

Ok so it seems your Kodi was built with a broken LibMicrohttpd that had issues with range requests.

There’s no Kodi 17.6 for your OS?

As it happens there is kodi 17.6 available now, and I will check if this resolve the problem later.

But I am not very optimistic, because this has been a problem for me for well over a year now…

Kodi 17.6 is 9 month old :wink:

  • Fix possible connection issues with internal webserver

Anyway if it does not fix, I’ll send you a yatse build that logs header, but the issue is 100% on Kodi side.

For a moment there when I tried this evening, I thought it was resolved! Sadly, the problem is intermittent: the first track I played worked, the next didn’t. I got it to work just once on another track, which I skipped to the end of, then no more would play, silently skipping in the same way as described above.

The logs are attached:
kodi.log (212.3 KB)
debug-2018-08-23.log (1021.4 KB)

This happened about 18:22 today (2018-08-23), and a second try at 21:24 with similar results.

You are still on 17.4. The Kodi issue won’t disappear by magic :frowning:

You should check the track that work, I’m sure they are different than the other, maybe smaller or larger in size than the others.

Oops, I will revisit that then.

Ok, now definitely running 17.6.

I can still replicate all the problems. The problem isn’t dependent on the tracks I play. The first play, track 1 played fine, then 2…3 skipped, going straight on to track 4. Then I stopped play and tried playing track 2 - this failed to play as before, but I could start track 3 playing (which had previously skipped). This fits with my general experience that tracks will unpredictably play or skip, and this changes from attempt to attempt.

Logs attached.

kodi.log (282.2 KB)
debug-2018-08-24.log (471.5 KB)

Sent you a mail with a test apk that logs headers.

Got it, thanks - here are the logs having run some more tracks (and witnessed more skipping)

kodi.log (323.1 KB)
debug-2018-08-24b.log (914.8 KB)

All fails occurs after those queries.

Can you try with the exact same headers the 2 queries in a row and see if it works outside of your phone?

2018-08-24 21:28:26.509 Verbose/KodiLogger: --> [329] HEAD http://192.168.0.51:8080/vfs/%2Fsrv%2FMusic%2FEverything%20But%20The%20Girl%2FAmplified%20Heart%2F05%20Get%20Me.mp3
2018-08-24 21:28:26.534 Verbose/KodiLogger: <-- [329] 200 OK http://192.168.0.51:8080/vfs/%2Fsrv%2FMusic%2FEverything%20But%20The%20Girl%2FAmplified%20Heart%2F05%20Get%20Me.mp3 (23ms)
2018-08-24 21:28:26.534 Verbose/KodiLogger: <-- [329] Last-Modified: Sat, 13 May 2017 09:57:18 GMT
2018-08-24 21:28:26.535 Verbose/KodiLogger: <-- [329] Expires: Sat, 24 Aug 2019 20:28:55 GMT
2018-08-24 21:28:26.535 Verbose/KodiLogger: <-- [329] Content-Type: audio/mpeg3
2018-08-24 21:28:26.536 Verbose/KodiLogger: <-- [329] Content-Length: 5139987
2018-08-24 21:28:26.536 Verbose/KodiLogger: <-- [329] Cache-Control: public, max-age=31536000
2018-08-24 21:28:26.537 Verbose/KodiLogger: <-- [329] Accept-Ranges: bytes
2018-08-24 21:28:26.537 Verbose/KodiLogger: <-- [329] Date: Fri, 24 Aug 2018 20:28:55 GMT
2018-08-24 21:28:26.538 Verbose/KodiLogger: <-- [329] END HTTP (No body, response code 200)
2018-08-24 21:28:26.546 Verbose/KodiLogger: --> [910] GET http://192.168.0.51:8080/vfs/%2Fsrv%2FMusic%2FEverything%20But%20The%20Girl%2FAmplified%20Heart%2F05%20Get%20Me.mp3
2018-08-24 21:28:26.547 Verbose/KodiLogger: --> [910] User-Agent: Yatse/8.6.0B1 (Linux;Android 4.4.2) ExoPlayerLib/2.8.4
2018-08-24 21:28:26.547 Verbose/KodiLogger: --> [910] Accept-Encoding: identity

So, you mean with something like this? (Actually I suspect not, revising now… but here it is anyway)

@Grab(group='com.squareup.okhttp3', module='okhttp', version='3.11.0')
import java.io.IOException;
import okhttp3.OkHttpClient;
import okhttp3.Request;
import okhttp3.Response;

def log = '''

2018-08-24 21:28:26.547 Verbose/KodiLogger: --> [910] User-Agent: Yatse/8.6.0B1 (Linux;Android 4.4.2) ExoPlayerLib/2.8.4
2018-08-24 21:28:26.547 Verbose/KodiLogger: --> [910] Accept-Encoding: identity
‘’’

def url = 'http://192.168.0.51:8080/vfs/%2Fsrv%2FMusic%2FEverything%20But%20The%20Girl%2FAmplified%20Heart%2F05%20Get%20Me.mp3'

    
def headers = log
    .split('\n')
    .collect {
    def match = (it =~ /.*\[\d+\] (.*?): (.*)/)
        return match? match[0][1,2] : null
    }
    .grep { it }
	
println headers.collect { it.join(':') } .join('\n')

OkHttpClient client = new OkHttpClient();

Request.Builder builder = new Request.Builder()
    .url(url)

headers.each { builder.header(it[0], it[1]) }

Request request = builder.build()


Response response = client.newCall(request).execute();

println "\nResponse:"
println response.headers()

This seems to succeed every time I’ve tried it:

User-Agent:Yatse/8.6.0B1 (Linux;Android 4.4.2) ExoPlayerLib/2.8.4
Accept-Encoding:identity

Response:
Content-Length: 5139987
Last-Modified: Sat, 13 May 2017 09:57:18 GMT
Expires: Sat, 24 Aug 2019 22:28:43 GMT
Content-Type: audio/mpeg3
Cache-Control: public, max-age=31536000
Accept-Ranges: bytes
Date: Fri, 24 Aug 2018 22:28:43 GMT

This version sends a HEAD request then a GET. It fails with ProtocolException every time I run it.

@Grab(group='com.squareup.okhttp3', module='okhttp', version='3.11.0')
import java.io.IOException;
import okhttp3.OkHttpClient;
import okhttp3.Request;
import okhttp3.Response;

def log = '''
2018-08-24 21:28:26.547 Verbose/KodiLogger: --> [910] User-Agent: Yatse/8.6.0B1 (Linux;Android 4.4.2) ExoPlayerLib/2.8.4
2018-08-24 21:28:26.547 Verbose/KodiLogger: --> [910] Accept-Encoding: identity
'''
    
def url = 'http://192.168.0.51:8080/vfs/%2Fsrv%2FMusic%2FEverything%20But%20The%20Girl%2FAmplified%20Heart%2F05%20Get%20Me.mp3'

    
def headers = log
    .split('\n')
    .collect {
    def match = (it =~ /.*\[\d+\] (.*?): (.*)/)
        return match? match[0][1,2] : null
    }
    .grep { it }
	
println headers.collect { it.join(':') } .join('\n')

OkHttpClient client = new OkHttpClient();

Request.Builder headBuilder = new Request.Builder()
    .head().url(url)

Request.Builder getBuilder = new Request.Builder()
    .url(url)

headers.each {
    headBuilder.header(it[0], it[1])
    getBuilder.header(it[0], it[1])
}

Request headRequest = headBuilder.build()
Response headResponse = client.newCall(headRequest).execute();

println "\nHEAD Response:"
println headResponse.headers()

Request getRequest = getBuilder.build()
Response getResponse = client.newCall(getRequest).execute();

println "\nGET Response:"
println getResponse.headers()

Outputs:

User-Agent:Yatse/8.6.0B1 (Linux;Android 4.4.2) ExoPlayerLib/2.8.4
Accept-Encoding:identity

HEAD Response:
Last-Modified: Sat, 13 May 2017 09:57:18 GMT
Expires: Sat, 24 Aug 2019 22:40:09 GMT
Content-Type: audio/mpeg3
Content-Length: 5139987
Cache-Control: public, max-age=31536000
Accept-Ranges: bytes
Date: Fri, 24 Aug 2018 22:40:09 GMT

Caught: java.net.ProtocolException: Unexpected status line: 
java.net.ProtocolException: Unexpected status line: 
	at okhttp3.internal.http.StatusLine.parse(StatusLine.java:69)
	at okhttp3.internal.http1.Http1Codec.readResponseHeaders(Http1Codec.java:189)
	at okhttp3.internal.http.CallServerInterceptor.intercept(CallServerInterceptor.java:88)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147)
	at okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.java:45)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:121)
	at okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.java:93)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:121)
	at okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.java:93)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147)
	at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.java:126)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:121)
	at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:200)
	at okhttp3.RealCall.execute(RealCall.java:77)
	at okhttp3.Call$execute.call(Unknown Source)
	at yatse-test.run(yatse-test.groovy:45)

Debugging, seems like the offending stream has no header, possibly no content.

It only happens if there is the initial HEAD request, comment that out and the GET works.

Doesn’t seem to depend on the headers.

here’s a tcpdump on the kodi server whilst running the above script:

$ sudo tcpdump -i any port 8080 -vvv
[cpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
00:27:23.918711 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    bee-hoon.noodlefactory.co.uk.http-alt > mee-pok.fritz.box.58304: Flags [S.], cksum 0x822c (incorrect -> 0xfb07), seq 3268553995, ack 3278600181, 
win 28960, options [mss 1460,sackOK,TS val 526994104 ecr 105822922,nop,wscale 7], length 0
00:27:23.922359 IP (tos 0x0, ttl 64, id 52543, offset 0, flags [DF], proto TCP (6), length 52)
    mee-pok.fritz.box.58304 > bee-hoon.noodlefactory.co.uk.http-alt: Flags [.], cksum 0x9a0d (correct), seq 1, ack 1, win 229, options [nop,nop,TS va
l 105822924 ecr 526994104], length 0
00:27:23.943848 IP (tos 0x0, ttl 63, id 52544, offset 0, flags [DF], proto TCP (6), length 305)
    mee-pok.fritz.box.58304 > bee-hoon.noodlefactory.co.uk.http-alt: Flags [P.], cksum 0x7dac (correct), seq 1:254, ack 1, win 229, options [nop,nop,
TS val 105822929 ecr 526994104], length 253: HTTP, length: 253
        HEAD /vfs/%2Fsrv%2FMusic%2FEverything%20But%20The%20Girl%2FAmplified%20Heart%2F05%20Get%20Me.mp3 HTTP/1.1
        User-Agent: Yatse/8.6.0B1 (Linux;Android 4.4.2) ExoPlayerLib/2.8.4
        Accept-Encoding: identity
        Host: 192.168.0.51:8080
        Connection: Keep-Alive

00:27:23.943902 IP (tos 0x0, ttl 64, id 26549, offset 0, flags [DF], proto TCP (6), length 52)
    bee-hoon.noodlefactory.co.uk.http-alt > mee-pok.fritz.box.58304: Flags [.], cksum 0x8224 (incorrect -> 0x98fe), seq 1, ack 254, win 235, options 
[nop,nop,TS val 526994111 ecr 105822929], length 0
00:27:23.945499 IP (tos 0x0, ttl 64, id 26550, offset 0, flags [DF], proto TCP (6), length 311)
    bee-hoon.noodlefactory.co.uk.http-alt > mee-pok.fritz.box.58304: Flags [P.], cksum 0x8327 (incorrect -> 0x24ce), seq 1:260, ack 254, win 235, opt
ions [nop,nop,TS val 526994111 ecr 105822929], length 259: HTTP, length: 259
        HTTP/1.1 200 OK
        Last-Modified: Sat, 13 May 2017 09:57:18 GMT
        Expires: Sat, 24 Aug 2019 23:27:23 GMT
        Content-Type: audio/mpeg3
        Content-Length: 5139987
        Cache-Control: public, max-age=31536000
        Accept-Ranges: bytes
        Date: Fri, 24 Aug 2018 23:27:23 GMT



00:27:23.949541 IP (tos 0x0, ttl 63, id 52545, offset 0, flags [DF], proto TCP (6), length 52)
    mee-pok.fritz.box.58304 > bee-hoon.noodlefactory.co.uk.http-alt: Flags [.], cksum 0x97f8 (correct), seq 254, ack 260, win 237, options [nop,nop,TS val 105822930 ecr 526994111], length 0
00:27:23.965686 IP (tos 0x0, ttl 63, id 52546, offset 0, flags [DF], proto TCP (6), length 304)
    mee-pok.fritz.box.58304 > bee-hoon.noodlefactory.co.uk.http-alt: Flags [P.], cksum 0x2e18 (correct), seq 254:506, ack 260, win 237, options [nop,nop,TS val 105822935 ecr 526994111], length 252: HTTP, length: 252
        GET /vfs/%2Fsrv%2FMusic%2FEverything%20But%20The%20Girl%2FAmplified%20Heart%2F05%20Get%20Me.mp3 HTTP/1.1
        User-Agent: Yatse/8.6.0B1 (Linux;Android 4.4.2) ExoPlayerLib/2.8.4
        Accept-Encoding: identity
        Host: 192.168.0.51:8080
        Connection: Keep-Alive

00:27:23.966775 IP (tos 0x0, ttl 64, id 52547, offset 0, flags [DF], proto TCP (6), length 52)
    mee-pok.fritz.box.58304 > bee-hoon.noodlefactory.co.uk.http-alt: Flags [F.], cksum 0x96f6 (correct), seq 506, ack 260, win 237, options [nop,nop,TS val 105822935 ecr 526994111], length 0
00:27:23.967439 IP (tos 0x0, ttl 64, id 26551, offset 0, flags [DF], proto TCP (6), length 52)
    bee-hoon.noodlefactory.co.uk.http-alt > mee-pok.fritz.box.58304: Flags [F.], cksum 0x8224 (incorrect -> 0x96e9), seq 260, ack 507, win 243, options [nop,nop,TS val 526994117 ecr 105822935], length 0
00:27:23.970183 IP (tos 0x0, ttl 63, id 52548, offset 0, flags [DF], proto TCP (6), length 52)
    mee-pok.fritz.box.58304 > bee-hoon.noodlefactory.co.uk.http-alt: Flags [.], cksum 0x96ee (correct), seq 507, ack 261, win 237, options [nop,nop,TS val 105822936 ecr 526994117], length 0
00:28:47.659078 IP (tos 0x0, ttl 64, id 33618, offset 0, flags [DF], proto TCP (6), length 52)
    bee-hoon.noodlefactory.co.uk.http-alt > mee-pok.fritz.box.58150: Flags [.], cksum 0x8224 (incorrect -> 0x781e), seq 2273460390, ack 3604709513, win 243, options [nop,nop,TS val 527015040 ecr 105813809], length 0
00:28:47.684707 IP (tos 0x0, ttl 64, id 13319, offset 0, flags [DF], proto TCP (6), length 52)
    mee-pok.fritz.box.58150 > bee-hoon.noodlefactory.co.uk.http-alt: Flags [.], cksum 0xb690 (correct), seq 1, ack 1, win 0, options [nop,nop,TS val 105843864 ecr 526772636], length 0

What does appear to get it to work is not to re-use the OkHttpClient instance for the GET request, but create a new one.

This may be a workaround for some kodi-side weirdness or it may not, my mind is open :slight_smile:

In fact, changing the URL to get a page from an Apache server, it works fine… [scratching head] something to do with re-using HTTP sockets with kodi?

Hum ok, thanks for all the detailed tests.

This is strange, but this is an old Kodi 16 bug that was due to be linked with broken library. Never heard issues about it in v17 but well this is Kodi :slight_smile:

Yatse have some mechanism against that, but it seems ExoPlayer does not goes though it.
Will see if I can apply the fix without performance impact and will probably send you a mail with a test APK.

Thanks. Why would so few yatse+kodi 17 users (just me?) be seeing it, and not all? Is there something unusual about my set-up?

The thing is that Kodi building have some big logic flaws :frowning:

Some libraries including LibMicroHttpd are sometimes the ones provided with Kodi or sometimes the one provided by the OS, or the one provided by the packager manager :slight_smile:

Meaning that for a Kodi version X, each OS and each build could have different libraries used and so different bugs :slight_smile:

This is a total nightmare to handle support for that :wink:

Your OS is very old so probably ship the bugged library version and as such your Kodi version is bugged.
i doubt that there is a lot of Kodi 17 on Unbuntu 14 anymore.

I’m finishing some tests and will send you an APK soon.