[wsnipex]

if a head request costs too much server resources, kodi is probably not the right media player for you.

[macamba]

if a head request costs too much server resources, kodi is probably not the right media player for you.

It's not too much cost for server, just I would like all work properly

[emveepee]

Who defined how many HEAD requests are proper? Some servers don't even support 1. If you feel it is incorrect I suggest submitting a PR with supporting rationale.

Martin

[macamba]

Who defined how many HEAD requests are proper? Some servers don't even support 1. If you feel it is incorrect I suggest submitting a PR with supporting rationale.

Martin

The more correct is explain the reason which Kodi or Addon do 2 Head request twice for the same resource, don't you think so?

[emveepee]

No.  I could think of scenarios where as a developer I might want to get the content-type and the content-length in two different calls.   Another example might be to determine if the file is growing and the server doesn't support content-ranges.

Relative to video streaming this call is insignificant.

Martin

[macamba]

No.  I could think of scenarios where as a developer I might want to get the content-type and the content-length in two different calls.   Another example might be to determine if the file is growing and the server doesn't support content-ranges.

Relative to video streaming this call is insignificant.

Martin

Maybe but I think is strange for a resourse jpg of a programme in EPG

[puenktchen]

For iptvsimple it will always do 2 requests unless you provide the mimetype as a KODIPROP or the mime type can be easily inferred from the file extension in the URL.

Are you sure about your statement with the file extension in the URL? My URL's look like this:

Code:

h__p://127.0.0.1:8096/emby/VirtualTV/Stream.ts?ChannelId=441160

Should this work? Because i always get two stream request. Also the Kodi log always shows this:

Code:

INFO <general>: AddOnLog: inputstream.ffmpegdirect: Stream mimetype: application/octet-stream

I have the feeling it's only the mimetype of the KODIPROP that is evaluated, so without any i always get those two requests.
And no, i cannot set the KODIPROP because the mimetype of my live streams don't necessary fit the mimetype of the catchup streams.

[phunkyfish]

I believe it’s only for URLs that end with the extension. But that’s a good point, could also check for for the question mark e.g. .ext?

EDIT: It only works for .m3u8, .mpd and .ism. I guess it could also work for .ts but I would need to check for any other side effects.

[puenktchen]

That would be nice if you can check this.

But the more important question is what the OP is asking: Why is the returned content type of the HEAD request for streams not evaluated as a mimetype for the pvr/inputstream addon?

[phunkyfish]

Because the add-on does processing before the stream is opened which requires the content type. Then the stream is opened by Kodi via an inputstream.

[puenktchen]

This cannot be true, because i clearly see this order in the logs of my server: HEAD, GET, GET
So when HEAD comes first and returns the mimetype, why a second GET?

[phunkyfish]

The addon accesses the url and then the inputstream does.

When ffmpeg reads the stream it actually does it twice. Once when it does not know the mime type and again once it does.

[puenktchen]

Once when it does not know the mime type

And that's the point. The HEAD request already returns the mimetype! But it's not used by the addon. Why is that? Is it intentional, is it just an oversight or is it a bug?

[emveepee]

Watching with wireshark I can easily duplicate situations with http streams that go HEAD HEAD GET HEAD GET GET... so I suspect it is just the nature of what the server is replying and what curl and ffmpeg are expecting.

I was working on a plugin recording VOD channels controlled by http to LIRC and the video buffers then buffers again https://www.youtube.com/watch?v=B98P_XJ4...utu.be&t=7.  The extra lage this causes too much a delay between the remote and and the screen to make it a truly viable addon.  This same url when played via PVR inputstream does not suffer from any buffering.

Martin

[puenktchen]

... so I suspect it is just the nature of what the server is replying and what curl and ffmpeg are expecting.

ffmpeg only needs the mimetype, because it's enough to put the mimetype as a KODIPROP in the channel playlist to then only create one GET request without any previous HEAD request.
Without the KODIPROP in the playlist, one HEAD request is created. The response of the HEAD request returns the same mimetype as the KODIPROP in form of content-type. But this is obviously ignored because two GET requests will follow. If it's not content-type that should hold the mimetype what else?
I still think the response of the HEAD request is never evaluated by the pvr/inputstream addon.