81 replies to this topic

[Huevos]

Press YELLOW when in Satfinder and it reads the TSID, ONID and services from the current transport stream and displays them on an info screen, without the need to do an E2 scan.

 

 satfinder-1.jpg   67.58KB   10 downloads

 

 satfinder-2.jpg   45.69KB   4 downloads

 

https://github.com/H...c85aa2201f4e986

 

Currently this is importing the dvbreader from AutoBouquetsMaker to read the transport stream...

 

Is there any way that similar could be done using enigma code (without having to do a scan)? Or is there currently no function in CPP that can be used this way?

[littlesat]

It depends on Plugins.SystemPlugins.AutoBouquetsMaker.scanner so not really usable... And the DVBreader of autobouquets maker is as far I remember a 'terrible thing' that cannot be interrogated very easy.

 

The question is why should you "scan the channels without a scanning channels"?... I think this 'part' is not that helpfull.

 

Couldn't it be considered to show the TSID and ONID right away on the screen without the yellow button.... and leave the channel scan as is? As far I know with autodiseqc the TSID and ONID are also read.

Edited by littlesat, 19 September 2017 - 16:06.

[WanWizard]

A possible reason could be to check what is on this transponder without getting them into your channel list?

[Huevos]

It depends on Plugins.SystemPlugins.AutoBouquetsMaker.scanner [...] And the DVBreader of autobouquets maker is as far I remember a 'terrible thing' that cannot be interrogated very easy.

Not sure what you mean by this. You tell it what to read and it returns the result.

[Huevos]

A possible reason could be to check what is on this transponder without getting them into your channel list?

Yes exactly. You can read the services without them messing up your channel list, And in most cases faster than an enigma scan.

[littlesat]

It uses a binary so to 'parse' a specific bin so you can read pids in python code. I think it is better to include some of these parsers in the enigma2 bin in cpp code or use other things that are available there. To get this informatie you need to parse pids ao you also need to scan them.
To read tid and onid as far I remember the same code as autodiseqc can be used.
As for the channels available on a transponder you already need to scan I do not see any reason to add an additional scan... the current scan just adds services to lastscanned bouquets...

Edited by littlesat, 19 September 2017 - 17:09.

[Huevos]

Code from AutoDiSEqC is not feasible because it does not update. That means it can only ever work for static LNBs. In the case of a motorised dish it will remember the first tsid it passes while the dish tranverses the arc.

Reason for not scanning is so this lamedb is not interfered with just to get more info about the current transport stream. After all satfinder is a tool. Scaning was a secondary function.

[littlesat]

Why is it bad lamedb get some updates... Then consider just give a normal scan a flag to not harm lamedb... I just meant to find a way to add labels that show tsid and onid on the usual screen... once the transponder is locked this should be possible. (And once locked it can also be considered to scan and add service names). Why add a yellow button for it and depend on a (hacky) plug-in? Better to try to add what is missing in common e2.

Edited by littlesat, 19 September 2017 - 20:08.

[Pr2]

Because he is talking of Satfinder, when you adjust an antenna for the first time you search for the satellite that you want to receive, and I won't like to have entries for satellite that I pass by when pointing my antenna in my lamedb. So no adding entries in the lamedb while in the satfinder is a bad idea.

But indeed mention the satellite that we receive signal from when we are in Satfinder can be useful when you set your antenna for the very first time, so you know where you are and where you need to go to find the real satellite you are searching for.

[littlesat]

That was Why I was suggesting not to add a yellow button for this... but give the data as soon the transponder is locked and even more optimaal show a picture on a first fta service... and find a way to not depend on the autobouquets plugin.
I hope it is Ok to brainstorm here...
Actually a lock could 'trigger' the same as you do with yellow. So yellow is not required. But you need to reserve some space for the extra info on the skin..

Edited by littlesat, 19 September 2017 - 20:33.

[mrvica]

means to update in bunch of skins the satfinder screen, probably we have to add the yellow button too

[jpuigs]

 

A possible reason could be to check what is on this transponder without getting them into your channel list?

Yes exactly. You can read the services without them messing up your channel list, And in most cases faster than an enigma scan.

 

 

A very good and interesting idea.

I don't remember any SAT receiver doing this, since the great DVB2000 on NOKIA's 9XXX first DVB STBs in early 2000's.

[Huevos]

That was Why I was suggesting not to add a yellow button for this... but give the data as soon the transponder is locked and even more optimaal show a picture on a first fta service... and find a way to not depend on the autobouquets plugin.
I hope it is Ok to brainstorm here...
Actually a lock could 'trigger' the same as you do with yellow. So yellow is not required. But you need to reserve some space for the extra info on the skin..

The problem is sometimes the dish locks on the "wrong" satellite while the dish is in motion. Then the dish carries on to the correct satellite and locks again. The AutoDiSEqC code does not update. TSID/ONID data remain from the "wrong" satellite.

 

Personally I think the way forward would be to add TSID/ONID to FrontEndInfo in the convertor and then it can be accessed directly in the skin. That way there would be no need to modify the plugin at all.

[Huevos]

means to update in bunch of skins the satfinder screen, probably we have to add the yellow button too

If it is done in the convertor it is completely up to the skinner what to display in their skin.

[Abu Baniaz]

The "terrible" and "hacky" reader is here:

https://github.com/o...lib/dvbreader.c

 

If you can suggest changes to make it better, it  would be greatly appreciated. We all agree if functionalities in E2 can be added without having to depend on plugins, it is the better option.

[littlesat]

Actually that binary should be included in the e2 bin and add 'dvb snoop' like code to it. Just a call to get onid and taid etc... with simple calls. As far I remember this is already available in e2. The background scan could read services.
Autobouquets could better be build by afding a different parser to the fastscan in cpp. I know this is a lot of work and for most people more complicated so it is for now what it is.
For the rotor you coukd poll the tsid and onid but I expect you have a trigger by a nee lock...

[Huevos]

Actually that binary should be included in the e2 bin and add 'dvb snoop' like code to it. Just a call to get onid and taid etc... with simple calls. As far I remember this is already available in e2. The background scan could read services.
Autobouquets could better be build by afding a different parser to the fastscan in cpp. I know this is a lot of work and for most people more complicated so it is for now what it is.
For the rotor you coukd poll the tsid and onid but I expect you have a trigger by a nee lock...

Triggering by lock is no help. Tuner lock/unlocks/locks again/etc while transversing the arc.

 

Re: Fastscan; Fastscan is a one-trick-pony. All it does is scan a proprietary table of one provider, i.e. M7. 

Also Fastscan is not a true plugin as half the code is embedded in the enigma binary, which means it is not portable.

 

But anyway we are going off topic here. The question is how can we get this data directly from enigma.

[littlesat]

Re: Fastscan; Fastscan is a one-trick-pony. All it does is scan a proprietary table of one provider, i.e. M7. 

Also Fastscan is not a true plugin as half the code is embedded in the enigma binary, which means it is not portable.

That's fully true... but this does not mean it can be extended by other provider's 'tables' and 'systems'... by switching it somehow to a different method. All PID readers are already there... 'only' the parsing needs to be changed. I'm sure that we could make a faster, smoother scan that way. And to be true I also understand this is a but more difficult way to go for the coders that made autobouquets as it has to be done in c++....

 

But when everyone has unlimited time this was already done years ago. So we should be happy that we also have autobouquets in not to optimal way as prefered...

 

 

Now back on topic...

 

The Autodisecq does the following...

 

It has a self.raw_channel via eDVBResourceManager.getInstance().allocateRawChannel(self.feid)

It arrange a callback for when the onid and tsid is 'received' via self.raw_channel.receivedTsidOnid.get().append(self.gotTsidOnid)

Then you get the tsid and onid via a the function gotTsidOnid(self, tsid, onid) (in autodiseqc it is compared with the table.... here we can set a label... and of course also start a services scan when we like).

Edited by littlesat, 21 September 2017 - 09:46.

[Huevos]

I originally coded it using the AutoDiseqc code, but like I explained above it doesn't work because that code is for static dishes, not motorised. i.e. once the tuner locks (on the wrong satellite) TSID/ONID that come out are for the wrong satellite and don't update upon the dish arriving at the correct satellite. For this to work TSID/ONID need to update continuously as the dish moves.

[littlesat]

You can trigger a new check on onid and tsid by the lock trigger.... and when that does not work poll it (I know it is not easy pointing to autodiseqc is just to give it a direction)

Edited by littlesat, 22 September 2017 - 07:38.