MrMC

No, it's the same problem.
With https enabled it calls for the stream in https which is the problem.

Is there anyway to incorporate the solution stated before:

this can be fixed on either client (Kodi) side, with a fixed libcurl which accepts the cipher served by the Enigma2 receiver (TLS1.2 in my case), or on the server (receiver) side, by adding the following default option to the m3u file generated by OpenWebIf: #EXTVLCOPT--http-reconnect=true --ciphers=<cipher name here>

@nisse99, as I said if we cant reproduce we cant fix.

if you are willing to let us test on your backend please contact us on [email protected], that is the only way we are going to be able to find and fix the issue.

if this issue has been in kodi for a while, kodi devs would have fixed it if it was an easy fix.. only way to fix it is to force tls1.2 but that might break other curl uses.

@davilla might have some more insight to this.

I am not very technical atleast when it comes to other OSes than windows

I did email you my apple id already. What else do I have to do for you to test on my backend? I want to help in anyway I can

@nisse99 you have testflight invite, please test VU+ when you can and let us know if its better... if not, we need to see that debuglog again. please use pastebin.com for it

nisse99 wrote:I am not very technical atleast when it comes to other OSes than windows

I did email you my apple id already. What else do I have to do for you to test on my backend? I want to help in anyway I can

@nisse99, any luck with it?

once plex client is stabilised we will be releasing it, please test and let me know if its working, if not we need to look into alternative solutions.

All right tested it out. Unfortunately same result. I tried uploading log to pastebin but it exceeded the limit for a non-pro user. Can I email you the log?

The problem still seems to be the fact that it tries starting the stream with https: when the stream has to be started with http:

I dont understand, you said you wanted https and thats what we are trying to fix. if you want http just disable https on your VU+ and all problems will be sorted out.

you cant have "secure" protocol and use http, it has to be https using tls1.2. I have a feeling that something is wrong with the VU+ software as I have tried numerous sites with https tvs1, 1.1 and 1.2 and had no problem with it.

yes, you can mail me the log.

From what I understand:

With HTTPS enabled all addresses to retrieve the channel lists, guide, icons etc have to be with HTTPS to work.

However the actual streaming though is still being run through HTTP... so if I take the line that fails from the log and remove the S it works in any browser.

I guess it's a limitation of the VU+/enigma boxes that the actual stream isn't being run through https. But in order to find the address of the stream the https is needed..

To be honest I don't understand the cipher solution part, I just found that solution in this thread http://forum.kodi.tv/showthread.php?tid=241931 , does that mean that it does stream through https as well but has to be deciphered? What's the point when the same stream can be started without the secured https?

Sending you my log now. Note I redacted my username/password, for some reason mrmc only redacts the user/pw on the error lines. Thanks for your patience

nisse99 wrote:From what I understand:

With HTTPS enabled all addresses to retrieve the channel lists, guide, icons etc have to be with HTTPS to work.

However the actual streaming though is still being run through HTTP... so if I take the line that fails from the log and remove the S it works in any browser.

but it doesnt work in any browser with https?

nisse99 wrote: I guess it's a limitation of the VU+/enigma boxes that the actual stream isn't being run through https. But in order to find the address of the stream the https is needed..

To be honest I don't understand the cipher solution part, I just found that solution in this thread http://forum.kodi.tv/showthread.php?tid=241931 , does that mean that it does stream through https as well but has to be deciphered? What's the point when the same stream can be started without the secured https?

Sending you my log now. Note I redacted my username/password, for some reason mrmc only redacts the user/pw on the error lines. Thanks for your patience

we have the latest and greatest curl with latest openssl, if https works in other browsers and not in MrMC then we have a problem... if however streaming via https is not working on your browser/vlc/<chose your player> we have no way of fixing it.

just out of curiosity, if you stream using http whats the point of having https for epg and picons?

I still maintain that this is VU+ issue and that we cant do much to fix it without breaking some other curl connections.

if you can, I would mind testing the stream here, allow me to connect to the box for few hours and I'll try to see whats happening and where the issue is.... if you want that, e-mail me please, do not post any info here.

I understand you curiosity! The point of https is for the credentials with username and password so that they are sent encrypted. To view the actual stream there's no additional authentication required, thus no "secret" data are sent unencrypted.

When I view on browser I log into the Openwebif manager which is https. From there I can press link to open the stream I want.
But if I instead use the approach which the PVR tries to, I have to remove the s so it's http for opening the stream link.

The enigma2 boxes are all the same. They stream through HTTP, however the interface (Openwebif) can be accessed through HTTPS. It's not a mistake, it's the way it's designed.

However the PVR addon has been written for only using https on everything if you enable it which seems to be a miss in the coding.
Is there no way to make the program use HTTPS for the webinterface port and HTTP for the streaming port? That would fix everything....

And did you mean access to the VU+ box? Or my ATV?