29 replies to this topic

[колбаскин]

I understand there is a problem for all users? Can prompt decision?

[WanWizard]

No, I don't have any issue on my ET 10K, so it must be something in OpenWebIf that triggers it.

 

Anyway, report these issues here: https://github.com/E...penWebif/issues, as said we don't maintain it.

[SpaceRat]

Please stop blaming OpenWebif for this.

 

These are the facts:

 

• ET10000 and various other boxes use multitranscoding (That means they offer normal and transcoded streaming on the same port, controlled by appending URL parameters)

   

  The default values for these parameters are controlled using a plugin named enigma2-plugin-systemplugins-multitranscodingsetup

   

  There are two variants of storing these defaults (Either two fixed presets or a theoretically unlimited amount of presets stored inside an array), but those who made the different version also made the necessary changes to OWIF.

  If you compare https://github.com/E...lugin-OpenWebif and https://github.com/oe-alliance/e2openplugin-OpenWebif you will notice the different handling.

   

  The first mentioned version of OWIF will handle the vendor provided multitrancoding w/o issues and the second will handle the oe-a variant without issues.

  As PLi didn't make own changes to the vendor's multitranscoder, the first variant will also work for OpenPLi.

   

• Vu+, Gigablue and DAGS/Edision use a separate transcoder, running on its own port

   

  This transcoder comes with its own setup plugin named enigma2-plugin-systemplugins-transcodingsetup

   

  Both variants of OWIF handle the Vu+-style transcoding perfectly well. No issues.

 

 

Now we come to OpenPLi:

1. OpenPLi decided not to use the original Vu+-Transcoder but to write their very own incompatible one.

2. While it resembles the way the multitranscoders of other boxes work, it's neither compatible with those multitranscoders.

 

In short:

- Vu+-style transcoding works

- Genuine multitranscoding works

- OpenPLi's remake of multitranscoding for the Vu+ does not work.

 

Conclusion/solution:

- Either fix your PLi-multitranscoder for the Vu+ to be compatible with the vendor-provided multitranscoder for other boxes so that OWIF can use those routines

or

- Provide a patch to handle your PLi-specific differences

 

But do not expect people not using OpenPLi to implement changes that are PLi-specific and stop lieing to users in order to make them ask for those changes from us.

 

You broke it, you fix it!

Why on earth should VTi, Black Hole or oe-a devs implement PLi-only fixes?

Edited by SpaceRat, 9 July 2015 - 14:15.

[WanWizard]

Why MUST we use the crappy VU+ only solution on an Xtrend box?

 

And there is nothing broken, it works fine on an ET 10K, as I wrote before. You only need to start the plugin once, as that will create the VU+ config file the OpenWebIf hardcoded relies on.

 

It is not our fault that OpenWebIf has external dependencies but is unable to fullfill them.

[SpaceRat]

Why MUST we use the crappy VU+ only solution on an Xtrend box?

As usual you understand nothing.

Probably you can not even use the Vu+ transcoding on an Xtrend box, but at least you are not supposed to do that.
And I nowhere said you should.

 

And there is nothing broken, it works fine on an ET 10K, as I wrote before.

And that relates to the Vu+ Duo²/Solo²/... problems in which way?

It is not our fault

It's never PLi's fault.

[WanWizard]

Fact remains: OpenWebIf has an external dependency, that is neither checked nor provided.

 

If it needs a transcoding config file to work (and it does), it should provide it, instead of assume it will magically be there. Poor coding practice, so fix it.

[колбаскин]

https://github.com/E...mment-119943711

 

And who is broke?

[Erik Slagter]

Probably you can not even use the Vu+ transcoding on an Xtrend box, but at least you are not supposed to do that.

It works out of the box. But it's not "VU+" transcoding, it's OpenPLi streamproxy that (also) offers the "VU+" interface (at least the sensible part).

It's just a "little bit" annoying that you defend the "VU+" transcoding to be the generic interface for all manufacturers. We don't agree and then you blame OpenPLi. Okay fine, be my guest, everyone is entitled to an opinion.

[Erik Slagter]

So the 1mbit bitrate limitation on Vu+ solo2 transcoding is hardware and never will be updated?

As explained many times before.

[SpaceRat]

It works out of the box. But it's not "VU+" transcoding, it's OpenPLi streamproxy

That's exactly what I said: OpenPLi is using its very own re-implementation of multitranscoding.
Thanks for your confirmation.

And as you have now confirmed that PLi uses a PLi-specific implementation it should be clear that only PLi (or an OWIF-dev using PLi) can make the necessary changes to make it work.

that (also) offers the "VU+" interface (at least the sensible part).

You know what's problematic, people have told you before.
a.) You are hiding the transcoding proxy behind a filename which is a normal (non-transcoding) streamproxy on many images
b.) You are storing the settings of your (trans)streamproxy inside some .conf which needs special treatment rather than using the E2-style of storing them inside /etc/enigma2/settings

It's just a "little bit" annoying that you defend the "VU+" transcoding to be the generic interface for all manufacturers.

No, I haven't.
Actually I was even considering suggesting your transtreamproxy for inclusion into OpenATV as soon as you get the problems sorted out.

We don't agree and then you blame OpenPLi. Okay fine, be my guest, everyone is entitled to an opinion.

I only blame OpenPLi for stopping at half the way.

You decided to make the PLi configuration incompatible with both, Vu+ transcoding and Xtrend & Co. multitranscoding, so you provide the patches.
Nothing more, nothing less.

Or:
You make the PLi-streamproxy configuration compatible with the multitranscoder of Xtrend & Co and it will automagically work (and if not, I'll take care of the rest).