Jump to content


Photo

Yet another commit that needs reverting


  • Please log in to reply
23 replies to this topic

#1 Huevos

  • PLi® Contributor
  • 4,229 posts

+158
Excellent

Posted 31 January 2019 - 19:33

https://github.com/O...05d640b88ba0be9

 

This is unfinished work. It has been rushed into PLi develop branch and it is alpha code. Did any OpenPLi coder bother to test it?

 

It is going to show on every machine that is currently multistream not machines that have T2MI capable drivers. There should be a /proc flag to show STB capability, not just link it to a different capability.

 

The enigma code should be able to retrieve the PID automatically, but this code only works with a manually entered PID, not auto. There is no way for the T2MI PID to be saved in lamedb (how is that going to work across reboots?). PIDs are not listed on Lyngsat so no way to add them to a satellites.xml. So the only way for users to retrieve and enter the PID is to look it up when present on Flysat.

 

IMO, this is unfinished code rushed into the image to support a new feature on one, and only one STB. This code should either be reverted or go to a different branch until it really is ready, not to the main development branch.


Edited by Huevos, 31 January 2019 - 19:37.


Re: Yet another commit that needs reverting #2 littlesat

  • PLi® Core member
  • 56,123 posts

+685
Excellent

Posted 31 January 2019 - 19:53

Give your comment on the commit...

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: Yet another commit that needs reverting #3 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 31 January 2019 - 19:58

Just some history and info regarding T2MI.


The only multistream T2MI is Zeonbud at 4.8E.

All others are "ordinary" ones.

So any tuner should be able to receive them, if you have access to C-band where most of them exist.


First there was astra-sm that was able to de-encapsulate the T2MI and provide back the full DVB-T/T2 transponder TS.

Some time ago, Edision offer single PLP T2MI (like the ones in 4.8E) with their new AVL tuner.

Today, Octagon offered T2MI (including MPLP) with a de-encapsulator embedded on drivers. I guess few more OEM will follow.


It's fine that manufacturers are working on this, it would be great of course if linux DVB could do it.
Then a newer kernel would offer it for all (and for free).


Anyway linux DVB is not that fancy today.

It really needs lot of changes in order to be able to work properly with s2x, multitype tuners, t2mi, gse and few more.


It would be nice if somebody informs all the PID to lyngsat. Seems like an info required, because not all providers are having proper T2MI_Descriptor.

Since that patch was already merged, I say now fix any problems left from those "credited".

Edited by athoik, 31 January 2019 - 19:59.

Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Yet another commit that needs reverting #4 Erik Slagter

  • PLi® Core member
  • 46,951 posts

+541
Excellent

Posted 31 January 2019 - 20:20

I also vote for revert.


* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: Yet another commit that needs reverting #5 WanWizard

  • PLi® Core member
  • 68,301 posts

+1,718
Excellent

Posted 31 January 2019 - 20:52

I also vote for revert.

 

Me too.

 

Non tested, non-finished code does not belong in the main develop ( = pre-release ! ) branch. Stuff like this will make it difficult to branch off future release versions.


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Pro (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: Yet another commit that needs reverting #6 littlesat

  • PLi® Core member
  • 56,123 posts

+685
Excellent

Posted 31 January 2019 - 23:44

Then revert... unless for me it looks finished...

Edited by littlesat, 31 January 2019 - 23:44.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: Yet another commit that needs reverting #7 Huevos

  • PLi® Contributor
  • 4,229 posts

+158
Excellent

Posted 1 February 2019 - 10:15

Then revert... unless for me it looks finished...

I don't know what you mean.

 

I have been testing this patch for the last month and a half.

https://github.com/H...11bef293f93abe2

 

The version committed to OpenPLi git doesn't have any support for automatically resolving PIDs. And when a manually selected PID is used there is no way to save that to lamedb.

 

It also needs a /proc/stb to show the drivers are capable, otherwise the options show on all STBs that can multistream, but do nothing, so would be very confusing for users.

 

The worst part is the user has to know the PID details and enter this manually to be able to scan anything, and that data is not available on Lyngsat, nor in satellites.xml.

 

How can you consider this code ready for the next OpenPLi RC?


Edited by Huevos, 1 February 2019 - 10:17.


Re: Yet another commit that needs reverting #8 Huevos

  • PLi® Contributor
  • 4,229 posts

+158
Excellent

Posted 1 February 2019 - 10:22

Also, why has the commit been connected to multistream when every enigma2 receiver that is not multistream capable can also do it? T2MI can be done on any receiver that has the correct software. It is not a hardware specific feature. Just needs the correct drivers.


Edited by Huevos, 1 February 2019 - 10:25.


Re: Yet another commit that needs reverting #9 Erik Slagter

  • PLi® Core member
  • 46,951 posts

+541
Excellent

Posted 1 February 2019 - 11:23

I think the reasoning was that hardware depends on drivers.


* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: Yet another commit that needs reverting #10 Huevos

  • PLi® Contributor
  • 4,229 posts

+158
Excellent

Posted 1 February 2019 - 11:34

I think the reasoning was that hardware depends on drivers.

Yes but every enigma receiver can do this without any changes to the drivers just by using astra-sm.

 

Also, for some reason this commit links T2MI to multistream capability. That is wrong. This commit should not need to touch the multistream code.

 

And the user still needs to know pid details just to be able to scan. What other scan ever requires the user to enter pid details? And even if those pid details are known by the user they are not saved in lamedb so how is it supposed to work across reboots?


Edited by Huevos, 1 February 2019 - 11:35.


Re: Yet another commit that needs reverting #11 MCelliotG

  • Senior Member
  • 443 posts

+35
Good

Posted 1 February 2019 - 23:37

Just for comparison and info, OpenATV that has already implemented this change since 31/1/2019 on Enigma2 has caused some issues on other MIS capable tuners that have not integrated a t2-mi decapsulator in driver level. For instance my HD51 now reports a PLP ID 0 in service info in all DVB-S2 services, which is completely wrong. Let alone that enabling T2-MI in Service scan will not work as expected.

 

My question is: is astra-sm's t2mi_decap binary file open source or closed source? From what I understand, Octagon used the very same decapsulator in their drivers, but what if that was a standalone enigma2 process? Wouldn't theoritically that work in all receivers without needing astra-sm if the required modifications were in place?


Edited by MCelliotG, 1 February 2019 - 23:37.


Re: Yet another commit that needs reverting #12 Pr2

  • PLi® Contributor
  • 6,046 posts

+256
Excellent

Posted 2 February 2019 - 10:16

Deleted since astra-sm is Open Source.  ;)


Edited by Pr2, 2 February 2019 - 10:33.

NO SUPPORT by PM, it is a forum make your question public so everybody can benefit from the question/answer.
If you think that my answer helps you, you can press the up arrow in bottom right of the answer.

Wanna help with OpenPLi Translation? Please read our Wiki Information for translators

Sat: Hotbird 13.0E, Astra 19.2E, Eutelsat5A 5.0W
VU+ Solo 4K: 2*DVB-S2 + 2*DVB-C/T/T2 (used in DVB-C) & Duo 4K: 2*DVB-S2X + DVB-C (FBC)

AB-Com: PULSe 4K 1*DVB-S2X (+ DVB-C/T/T2)
Edision OS Mio 4K: 1*DVB-S2X + 1*DVB-C/T/T2
 


Re: Yet another commit that needs reverting #13 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 2 February 2019 - 10:30

Guys please... astra-sm was and still is open source.

https://gitlab.com/berdyansk/astra-sm

Above is not astra-sm code.
Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Yet another commit that needs reverting #14 Erik Slagter

  • PLi® Core member
  • 46,951 posts

+541
Excellent

Posted 4 February 2019 - 20:23

Is this concerning the DVB concept of having a stream inside another stream? What I've heard is that there are no chipsets (at least not available for enigma receivers) that can do the extra decapsulation/demuxing in hardware. So either the drivers must do it in software or the software (enigma2) must do it itself. In that case I tend to favour the second option, because then (indeed) it will work on all receivers, although maybe the SoC can't keep up with the speed, if slow.

 

For my idea, so edision implemented the first approach, demuxing in software within the driver?


* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: Yet another commit that needs reverting #15 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 4 February 2019 - 20:38

Edision using new AVL tuner got T2MI (single MPLP) from firmware inside the tuner.

Octagon implemented the de-encapsulator inside drivers.


Both approaches are not promoting open source, but they simply work without having "many" enigma2 changes, and this is what normal users care about!

They want to scan a TP containing T2MI and get the channel list. Tune to a channel, watch TV, press the red button and record. That's all.


The "hacky" way with de-encapsulation on userspace using "bypass" to astra-sm is not easy to configure neither user friendly.


So current situation is like this: Enigma2 community cannot provide "simple" T2MI, user demand, manufactures are doing magic, people are happy.


As a normal user I prefer simple solutions that work.

As a open source user/developer, I prefer a software that I can compile and run my self.


If the "standard" become the driver-space de-encapsulation, some boxes might get the update and work out of the box, other need to use the non user friendly "astra-sm" way.
Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Yet another commit that needs reverting #16 Huevos

  • PLi® Contributor
  • 4,229 posts

+158
Excellent

Posted 5 February 2019 - 01:12

How does Edision know which PID to de-encapsulate? i.e. normally PID is 0x1000, but not always. e.g.40.5W 4000 L, PID is 0x0040.



Re: Yet another commit that needs reverting #17 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 5 February 2019 - 06:40

I don't know, the SDK from AVL only accepts an enable/disable.

Maybe they pass the full TP TS to their de-encapsulator, that's why only 4.8E works properly, because it has single PID (no PMT, PAT, only 4096) and single PLP.

AVL62X1_Enable_T2MIRawMode
AVL62X1_Disable_T2MIRawMode
But AVL solution is incomplete, probably the newer SDK / firmware will require PID as well, if they will fix MPLP?

It's all just guessing. Both implementations are hidden in blobs.
Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Yet another commit that needs reverting #18 Huevos

  • PLi® Contributor
  • 4,229 posts

+158
Excellent

Posted 5 February 2019 - 09:52

This is the transponder from 40.5W that sort of works but breaks up from time to time. SI tables are sparse. No NIT or BAT, so no T2MI descriptor. But does have a basic PAT.

 

Attached File  40W_4000L.jpg   188.23KB   5 downloads


Edited by Huevos, 5 February 2019 - 09:53.


Re: Yet another commit that needs reverting #19 Huevos

  • PLi® Contributor
  • 4,229 posts

+158
Excellent

Posted 5 February 2019 - 20:29

@@MCelliotG, Do you have a list of t2mi pids from your experiments with astra-sm?



Re: Yet another commit that needs reverting #20 frankviana

  • Senior Member
  • 472 posts

+4
Neutral

Posted 5 February 2019 - 22:50

With my tests, pid: 64

 

https://forums.openp...ndpost&p=889792


Dreambox Two, GT-Media V8XS, GT-Media M7x, GT-Media v9 prime, Gt-Media Finder Meter 2, , TBS 6903-x v2, Octagon SF8008 single, Edision OS Mini 4k, Zgemma h9s SE, GT-Media V8UHD, Raspberry Pi 4, T95 Max + (CoreElec/Tvheadend), Freesky Triplo X, Zgemma h9 twin, Zgemma h9s, Amiko SHD 8900, Gt-Media GTC, Octagon SX88+, Octagon SX88, Vu Zero, Vu+ Zero 4K, Mecool K1/K2/K3, Azamerica s2010, Azamerica s810B, Nazabox Xgame, Koqit K1 mini, TBS 5520se, TBS 5925, TBS 6922se, Openbox X5, Openbox S9, AZBOX TITAN twin, AZBOX Premium+, AZBOX Elite , Rasp Pi, Rasp Pi 2/3, Orange Pi PC, Coolsat 5000, Dm528s, DM800se, Satlink 6933, Satlink 6960, Satlink 6932, GT-Media V8, Gt-Media V8 Meter,  PixelView PlayTV USB SBTVD ISDB-T (dib0700), Mygica S270 ISDB-T (Siano Rio). C-Band Motorized dish - 5,00m (20ºE - 116.8ºW), Ku-Band Motorized dish - 1,80m (3ºw - 116,8ºW)



1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users