116 replies to this topic

[anudanan]

I´ve made tests with a revert of

 

https://github.com/e...d9a5e211d6916aa

 

It works with streaming for auth and without streaming for auth. with the /web/stream url over an unpatched OWIF httpserver

 

So I´m sure we don´t need a code change in OWIF and no http_server.py patch in OWIF if the auth parameter goes to OWIF web/stream urll if auth for streaming is enable.

 

The only point it that streamproxy can´t authenticat the -sip transient users of OWIF M3u file. 

 

Therefor we need a change of streamproxy to use every time if auth for streaming is enable a OWIF url for authentication the streaming user (passwd user and -sid users). Especially for filestreaming acutally streamproxy don´t user OWIF for doing the auth.

 

Maybe we can use an existing url access of OWIF instead of the own streamproxy authentication code fir user auth, but I don´t acutally know which url is the best

[anudanan]

With the auth revert I see now problem to change the Streaming.py of enigma to provide the default_audio_pid

 

No change of OWIF needed, no patch of http-server.py of OWIF needed

 

It works in the same way around auth  as today in openpli 7.0 with the http-server patch for OWIF. This patch is today needed ebecause streamproxy sends no webauth any time. With the  revert it send the auth for web/stream access, which is only needed, if OWIF has auth_for _streaming enabled

 

I´ve tested it in all cases and it works.

[littlesat]

And what about a change of owif?

[anudanan]

No OWiF changes are necessary and no OWIf patch on openpli

It works with the actual /web/stream url and a changed Streaming.py of Enigma as a copy from Streaming2.py from the Developer branch. We don’t need Streaming2.py in Enigma and no stream2.py in OWIf

Edited by anudanan, 7 March 2019 - 11:27.

[Erik Slagter]

For the authentication problem you use actually the patch for OWIF of httpserver.py, if streamproxy use OWIF.

https://github.com/O...56441039838ff55

You have integrated that some month ago. 

You don't need to worry about the authentication issue. This patch is tempory and I want to replace it with something permanent, that is implemented properly and doesn't need a patch. Actually the auth "issue" isn't a big deal. As soon as the "stream2" url is adapted by OWIF, most of it is already solved. The only thing we need additionally is an OWIF URL that does authentication without any other action (so web/stream isn't suitable). It can be simple as three lines in OWIF to have something like that.

[Erik Slagter]

If Streaming is configured without auth, then the web/stream url works without auth.

Probably, but most people will use auth.

[Erik Slagter]

The only point it that streamproxy can´t authenticat the -sip transient users of OWIF M3u file. 

That is one of the issues. There are others though.

 

But as said, don't worry about that, I will take care of it.

[Erik Slagter]

No OWiF changes are necessary and no OWIf patch on openpli

It works with the actual /web/stream url and a changed Streaming.py of Enigma as a copy from Streaming2.py from the Developer branch. We don’t need Streaming2.py in Enigma and no stream2.py in OWIf

If you want to have proper language selection in your live transcodings, yes you DO need it.

 

And I am not going explain for the third time why we can't simply change web/stream in OWIF.

[anudanan]

Ok, if you would like to have an url without auth even if a user has enabled auth, than a second is needed My point was that auth to the /web/stream url ist possible for streamproxy as is was in the past  but based on the auth_for_streaming switch of OWIF settings (acutally streamproxy use this parameter)

 

Do you think the OWIF developer will implement a second stream2 url?

 

 A discussion with them is needed. Do you know how other transcoding processes of other images handle auth for streaming?

 

 

I use today auth for streaming with a special no/shell user. With noshell user the m3u file use the credentials of the noshell user and use not the -sid user which streamproxy can´t handle today. With this special user is work very well.

[anudanan]

Did you know that with this httpserver patch 

https://github.com/O...56441039838ff55

OWIF doesn´t auth the /web/stream url even if auth_for_streaming is enabled? This is included in openpli 7.0 rel and also in develop branch)

 

That is the reason why streamproxy with auth for streaming works today together with OWIF and that is also the reason why default_audio_lang works with a changed Streaming.py instead of using stream2.py in OWIF and Streaming2.py in enigma.

I have is on my box and streamproxy get default_audio_lang_pid

 

The codelines for auth of /web/stream are in httpserver.py and the patch allows all access from localhost in OWIF.

[Erik Slagter]

Do you think the OWIF developer will implement a second stream2 url?

In the past they have said they need compatibility with other external applications. That inherently means I cannot change the behaviour of the web/stream url. So there it is, the third time I explained it.

 

So they either will have to accept a second streaming URL, required for streamproxy, or it won't work with streamproxy. As it is their code, they can decide.

 

Why don't you create a PR and see what happens.

[Erik Slagter]

Did you know that with this httpserver patch 

https://github.com/O...56441039838ff55

OWIF doesn´t auth the /web/stream url even if auth_for_streaming is enabled? This is included in openpli 7.0 rel and also in develop branch)

And this I am now explaining for the second time. This is a WORKAROUND patch. It will go as soon as possible. It's not a solution. Also it will NOT add the required functionality to the web/stream URL for default audio pid selection.

[anudanan]

I understand your point to have no patches for OWIF.

 

But providing the default audio pid has only to do with the code in Streaming.py in enigma. It works over the normal /web/stream url (it runs successful on my box) and not only with /web/stream2, but you are correct, there is a need for auth data if auth for streaming ist enable with /web/stream.

The demand for a /web/stream2 url is only the demand of no authentication from local host even if auth for streaming is enabled. But default_audio_pid providing works with both urls, if the corresponding Streaming.py or Streaming2.py have the default_audio_pid code.

 

 

 

. 

[Erik Slagter]

But providing the default audio pid has only to do with the code in Streaming.py in enigma. It works over the normal /web/stream url (it runs successful on my box) and not only with /web/stream2, but you are correct, there is a need for auth data if auth for streaming ist enable with /web/stream.

The demand for a /web/stream2 url is only the demand of no authentication from local host even if auth for streaming is enabled. But default_audio_pid providing works with both urls, if the corresponding Streaming.py or Streaming2.py have the default_audio_pid code.. 

How many times do I have to repeat this? The /web/stream url (OWIF) calls the stream adapter (OWIF) calls the stream controller (OWIF) and that calls the streaming.py (enigma) converter. There is no code there that will produce the default audio stream.

 

The /web/streaming2 url (OWIF, not yet in) calls the stream2 adapter (OWIF, not yet in) calls the stream2 controller (OWIF, not yet in) and that calls the streaming2.py (enigma) converter. In there is the code to produce the default stream pid.

 

I think you modified the streaming.py converter on your own receiver and you forgot you did it. You may want to start off with a clean enigma and OWIF installation and test again.

[anudanan]

Yes, I have a modified Streaming.py and I have said this many times in this thread. My idea was why a second chain of stream2.. Streaming2.py when it also works with the stream..Streaming.py to provide the default_audio_pid (clearly with a changed Streaming.py).

 

If you would like to have an extra /web/stream2 for access without auth any time you don´t need an streaming2.py in enigma. a new stream2.py of OWIF can also call Streaminy,py (with changes for default_audio_pid). Why a second Streaming2.py. I thing that is superfluous. That is my  opinion

[Erik Slagter]

That is a consideration, but I don't want to take the risk all sorts of existing plugins, skins and other Python code already using the converter and going to break when I change it.

Edited by Erik Slagter, 11 March 2019 - 18:56.

[anudanan]

I understand