2057 replies to this topic

[littlesat]

And I fixed another one... a config import that was not there...

 

Then beside this the streamrelay patch does not properly work on a client remote box... a box where the tuners are disabled.... On a 'server' box the channel like ARD or so is indeed white... but when you select it you still can get 'no tuner available' messages... so this is not resolved yet. I'm afraid there was no real attention to fallback configured tuners here....

Edited by littlesat, 30 November 2023 - 13:31.

[DimitarCC]

a box where the tuners are disabled....

 

But that is pointless if you want to watch the channel that needs stream relay it will require a tuner! Or you are speaking for the remote client?

[Huevos]

And I fixed another one... a config import that was not there...

 

Then beside this the streamrelay patch does not properly work on a client remote box... a box where the tuners are disabled.... On a 'server' box the channel like ARD or so is indeed white... but when you select it you still can get 'no tuner available' messages... so this is not resolved yet. I'm afraid there was no real attention to fallback configured tuners here....

Please be patient. We are looking into this here. This is a feature we don't normally use.

Edited by Huevos, 30 November 2023 - 14:48.

[DimitarCC]

 but when you select it you still can get 'no tuner available' messages... so this is not resolved yet.

 

That is fixed with that

 

https://github.com/O...igma2/pull/3852

[Tech]

Merged.

[littlesat]

.But that is pointless if you want to watch the channel that needs stream relay it will require a tuner! Or you are speaking for the remote client?

->

That is not pointless at all.... as you 'bend' it with the URL of the server box on port 17999 (default) so it does a stream relay decode on the server box... so you also 'stealthly' can view stream relay channels on a client box.... this worked before smoothly and even due to a fake serviceref was not mandatory there all transponder data etc. was available... With the latest changes this does not work anymore. The stream is not requested anymore at the server side.

 

I'm afraid in your design did missed this point as you indicated that this makes no sense..... Also note that the server box will and can start more relay servers... they can also be 'remotely'. And for those the tuner stuff already performed well..

 

After all I'm afraid you're trying here to stay with fake serviceref and work-a-round the real pain.

 

Please forget the crap above... as I'm 100 % sure this will be resolved... and most likely by you as you're currently in that code...

Edited by littlesat, 30 November 2023 - 15:45.

[DimitarCC]

 

.But that is pointless if you want to watch the channel that needs stream relay it will require a tuner! Or you are speaking for the remote client?

->

That is not pointless at all.... as you 'bend' it with the URL of the server box on port 17999 (default) so it does a stream relay decode on the server box... so you also 'stealthly' can view stream relay channels on a client box.... this worked before smoothly and even due to a fake serviceref was not mandatory there all transponder data etc. was available... With the latest changes this does not work anymore. The stream is not requested anymore at the server side.

 

I'm afraid in your design you somehow completely missed this point.... Also note that the server box will and can start more relay servers... they can also be 'remotely'. And for those the tuner stuff already performed well..

 

After all I'm afraid you're trying here to stay with fake serviceref and work-a-round the real pain

 

 

I am afraid as the @Huevos said that is a feature than i have never used, can not use and will probably never use...Thats why it is missing. BUT We will look at that.

You can not overrule the fake ref. It is there by purpose because the tuner can not understand duplicated chids. ChannelID is formed by DVBNamespace, DVBTransportStream and DVBOriginalNetwork. All that is taken from the sref.

So if you have a stream with that above the same it will return a same chid and will prevent service to play. So fake ref have to be there.

It was working on the remote client since the server and client are different and there is no more chid duplication.

If you want to change that you must completly change the way enigma2 was parsing service refs.

What my design do is actually to relay the info from the original DVB sref to the fake one so to behave like it was real one.

[littlesat]

The amount of the delay however is specific for different tuners and boxes so it is a added as configuration with default value of 100ms.

This kind of patch drops a red flag.... as this is not a real solution, but a work-a-round.

 

Then better find something that forces to stop the stream...and then zap... but the issue here is you have to do something in the stream-relay implementation as well...

 

For now I think when the 100 ms delay does work.... and it depends on 'box' type then better go for a SystemInfo instead of config.... then in SystemInfo we can set a default per box... (we can begin with just one which is 100).

[littlesat]

So if you have a stream with that above the same it will return a same chid and will prevent service to play. So fake ref have to be there.

Sorry I do not understand this part... and maybe I just do understand.... as this could be just the point that could be the target for a real solution here....

[littlesat]

Sorry on the client box it works fine.... my mistake .... somehow during an update the settings were not put back from the backup so the streamrelay was localhost.... My fault.... do not spent time in client box fallback stream relay as it is fine now!

[littlesat]

And also on the client box it shows now transponder info with fake ID.

 

P.S. you forgot to add the config for the delay that leads to a GSOD

[littlesat]

I just saw the confit is there... I did not looked right or it crossed....

[Huevos]

 

The amount of the delay however is specific for different tuners and boxes so it is a added as configuration with default value of 100ms.

 

This kind of patch drops a red flag.... as this is not a real solution, but a work-a-round.

 

Then better find something that forces to stop the stream...and then zap... but the issue here is you have to do something in the stream-relay implementation as well...

 

For now I think when the 100 ms delay does work.... and it depends on 'box' type then better go for a SystemInfo instead of config.... then in SystemInfo we can set a default per box... (we can begin with just one which is 100).

 

Regarding the time delay PLi doesn't work properly without it. It is configuable by the user but 100 ms is usually enough to release the tuner.

 

PLi already has a fixed 500 ms time delay for releasing IOTV streams before starting another.

Edited by Huevos, 30 November 2023 - 16:13.

[DimitarCC]

 

So if you have a stream with that above the same it will return a same chid and will prevent service to play. So fake ref have to be there.

 

Sorry I do not understand this part... and maybe I just do understand.... as this could be just the point that could be the target for a real solution here....

 

 

This is the reason a fake reference to be constructed. Because when we have same srefs it will return same channel ids and that will redirect you to the original service instead to stream relayed one.

That can not be fixed since as i said you have to completly change the enigma2 code regarding service reference handling. That is huge ampount of work and i am not sure is it worth since the stream relay is a hack at first place.

[DimitarCC]

P.S i suggest the moderator to move that posts above to the relevant thread in here https://forums.openp...g/#entry1583177

 

Since it is not connected with the skin.

[DimitarCC]

 

The amount of the delay however is specific for different tuners and boxes so it is a added as configuration with default value of 100ms.

 

This kind of patch drops a red flag.... as this is not a real solution, but a work-a-round.

 

Then better find something that forces to stop the stream...and then zap... but the issue here is you have to do something in the stream-relay implementation as well...

 

For now I think when the 100 ms delay does work.... and it depends on 'box' type then better go for a SystemInfo instead of config.... then in SystemInfo we can set a default per box... (we can begin with just one which is 100).

 

 

That is working like that because of the stream and it not only depends on the box, but on the tuner type and model. So i dont think a default values can be defined since someone have to test with all possible tuners.

And you can not force close the stream since there is no instruments with which you can do that.

[DimitarCC]

And also on the client box it shows now transponder info with fake ID.

 

 

Ofcource because it is not the box that initiate the stream relay. How the client box can know that this is stream relay channel on the server?

[littlesat]

Another side effect. At least on the remote client box for stream relay we do not see the service number (yet).... With an initial zap you see it but as soon you got picture it disappeared... (change to '---'). When I do not use fake service ref then it is fine.... (I have no idea of we have the same on server box - cannot test now)

Edited by littlesat, 30 November 2023 - 16:49.

[DimitarCC]

On Server box should not be that issue since you have the original reference stored in Navigation.

On the remote box you dont know what was the original because the box doesnt understand that this is stream relayed service

 

What can be done is channel number to be gotten from the python by using the bouquet file as a reference instead to use lamedb now.

Edited by DimitarCC, 30 November 2023 - 16:52.

[littlesat]

For the delay when we have to keep it I prefer to have a SystemInfo.... and not bother the user with it... when it is really sometimes needed to get a higher value for some hardware then we can arrange that..,. Or even start just with a fix 100 and see if a config is really needed.

 

I think a setting of '0' is not really a valid added value... 0 and 100 ms almost nobody does notice and even when you have a FBC tuner when more tuners are occupied it may still go wrong...