58 replies to this topic

[razorback]

...why not ?

after all it DOES display the correct information !
(as does the mentioned info from Glass-Utils).

So, what's the issue ?
perhaps: "not invented here" ?

R

[pieterg]

We know that if you show the transponder parameters (instead of the frontend status), the information will match what is in the lamedb.
This discussion is about the frontend status.
If a skin is showing transponder parameters, you cannot use it to debug frontend status.

[littlesat]

you cannot use it to debug frontend status.

Indeed... it should be fixed at the source.... and that could be within the drivers we cannot change...

[Huevos]

As far as I can remember the problem seemed to come from using blind scan exclusively on my vu+ultimo, I think more or less all the data is stored as "Auto" in the lamedb.

This isn't true. Vu+ Ultimo returns all blind scans as 3/4 FEC and that is what is written to lamedb. All other parameters are correct apart from minor frequency and symbol rate discrepencies.

[Huevos]

Just a quick question: I've noticed in Pli that whenever the data is for display only (infobar, or service info) false is used, but when the data is going to be used for some work (like in manual scan of a single transponder) true is used. Why is that? Why is it so important to display incorrect data on the infobar, rather than use the lamedb data that is used everywhere else in the image?

Edited by Huevos, 10 March 2012 - 23:32.

[pieterg]

normally you'd want tuner status in the infobar. The transponder parameters might be incorrect, and most tuners can perfectly cope with that, and figure out the correct settings.

[littlesat]

I saw ViX did submit your patch... but still this isn't a good idea... Now always the values from lamedb are taken - and also those could be wrong.... The real fix in fact are good drivers!!!

Edited by littlesat, 12 March 2012 - 11:17.

[razorback]

We know that if you show the transponder parameters (instead of the frontend status), the information will match what is in the lamedb.
This discussion is about the frontend status.
If a skin is showing transponder parameters, you cannot use it to debug frontend status.

please enlighten me.....since I am - as mentioned - no developer.

what is the difference between "transponder parameters" and "frontend status" ?

when I had definitely wrong data in my lamedb, on the ET-9100 the correct data was displayed in the infobar (apparently because of the ability of the tuners to get it right anyway)whereas on the VU+Duo I got a "tuning failed" (apparently because the tuners there are not that capable).

which - for me - would say that whatever is responsible for the display, must have access to the "real tuner data", obviously retrieved from what the tuner is providing....
how so ???

And I know, I am a nuisance - but why can a skin (whatever it does) display the correct information and others can not ??

I want to UNDERSTAND what is happening there.......

R

[littlesat]

With the transponder parameters is meant what the tuner is programmed to tune to.... this data comes from lamedb.... The frontend status are the parameters were the tuner is really tuned too.... As some tuners are intelligent and can e.g.automatically adjust FEC, QPSK/PSK, DVB-S1/S2, Symbol rate and frequency.... this should be the true data were the tuner is tuned to.... (see difference between blue and yellow key at service information)...

By goal was to give the real value were the tuner is tuned to... but some drivers/tuner do forward an incorrect value... that we then see on the OSD.... to put it on lamedb may also give incorrect values....

Probably we have to make an option for that... but that is something I also want to prevent....

Edited by littlesat, 12 March 2012 - 12:11.

[pieterg]

For me, the real status is most interesting. The lamedb parameters are not.
So please don't change this.

[Huevos]

I saw ViX did submit your patch... but still this isn't a good idea... Now always the values from lamedb are taken - and also those could be wrong...

In VIX if you go to the service info you can see either. Press blue for the data from the front end and yellow for the data from lamedb.

[pieterg]

that has been the case since day one of e2

[Huevos]

that has been the case since day one of e2

This is just a matter of personal taste but people seem very polarised about. Easiest way to please everyone would be to add it as an option in the customisation menu, then each and every person could decide for themselves what their infobar should display.

[pieterg]

that has been the case since day one of e2

This is just a matter of personal taste but people seem very polarised about. Easiest way to please everyone would be to add it as an option in the customisation menu, then each and every person could decide for themselves what their infobar should display.

I meant the blue/yellow pages in the information menu.
That's where you can find the transponder parameters, if you need them (and compare them with the frontend status).

Any status screen however, should show accurate status.

[Huevos]

Any status screen however, should show accurate status.

I agree but in this case something is broken which makes that impossible.

[littlesat]

Something is broken in the drivers of the box... and that is not fixable...

[Huevos]

Something is broken in the drivers of the box... and that is not fixable...

Ok, well I've posted it as a bug report on their site, so nothing left to do now.

Edited by Huevos, 12 March 2012 - 14:08.

[MartiniB]

compare which data you have in Infobar
same as Menu->Information->Service->Yellow
or Menu->Information->Service->Blue

first comes from lamedb, if that are `Auto` then this is Enigma's2 proplem - on autoscan it add value Auto everywhere it can
have reported that on DMM board http://www.dream-mul...auto#post108425
but there no chanses see fix

to remove all `Auto` values in the lamedb i have made `lamedb.sed` rulles list and script
which i execute after each autoscan(stupid Enigma2 replaces also previously stored transponder's information)
/usr/script/lamedb_set_inversion.sh
(chmod 755)

#!/bin/sh
# MartiniB
#
fLAMEDB="/etc/enigma2/lamedb"
sed -f "$fLAMEDB".sed "$fLAMEDB">"$fLAMEDB".tmp
if [ -s "$fLAMEDB".tmp ]; then
mv "$fLAMEDB".tmp "$fLAMEDB"
# broken sinc ~2011.okt
#wget -O /dev/null -q [url="http://127.0.0.1/web/servicelistreload?mode=1"]http://127.0.0.1/web/servicelistreload?mode=1[/url]
killall -9 enigma2
else
echo ErRoR - Zero len "$fLAMEDB".tmp
fi

/etc/enigma2/lamedb.sed

s#:48:2:0#:48:0:0#
s#11554000:27500000:0:3:70:2:0#11554000:27500000:0:3:70:1:0#
s#:70:2:0#:70:0:0#
s#11919000:27500000:1:3:90:2:0#11919000:27500000:1:3:90:1:0#
s#:90:2:0#:90:0:0#
s#:100:2:0#:100:0:0#
s#11727000:27500000:1:3:130:2:0#11727000:27500000:1:3:130:1:0#
s#:130:2:0#:130:0:0#
s#12714000:5632000:1:3:158:2:0#12714000:5632000:1:3:158:1:0#
s#:158:2:0#:158:0:0#
s#:160:2:0#:160:0:0#
s#:192:2:0#:192:0:0#
s#:235:2:0#:235:0:0#
s#:282:2:0#:282:0:0#
s#:360:2:0#:360:0:0#
s#:390:2:0#:390:0:0#
s#000:2:0:360:#000:0:0:360:#
s#000:2:1:360:#000:0:1:360:#
s#000:2:2:360:#000:0:2:360:#
s#000:2:3:360:#000:0:3:360:#
s#000:2:4:360:#000:0:4:360:#
s#000:2:5:360:#000:0:5:360:#
s#000:2:6:360:#000:0:6:360:#
s#000:3:0:360:#000:1:0:360:#
s#000:3:1:360:#000:1:1:360:#
s#000:3:2:360:#000:1:2:360:#
s#000:3:3:360:#000:1:3:360:#
s#000:3:4:360:#000:1:4:360:#
s#000:3:5:360:#000:1:5:360:#
s#000:3:6:360:#000:1:6:360:#
s#:400:2:0#:400:0:0#
s#:420:2:0#:420:0:0#
s#10974000:8150000:0:3:530:2:0#10974000:8150000:0:3:530:1:0#
s#:530:2:0#:530:0:0#
s#11512000:2617000:1:3:600:2:0#11512000:2617000:1:3:600:1:0#
s#:600:2:0#:600:0:0#
s#:750:2:0#:750:0:0#
s#:-300:2:0#:-300:0:0#
s#:-245:2:0#:-245:0:0#
s#:-220:2:0#:-220:0:0#
s#:-180:2:0#:-180:0:0#
s#:-150:2:0#:-150:0:0#
s#12661000:2170000:1:3:-125:2:0#12661000:2170000:1:3:-125:1:0#
s#:-125:2:0#:-125:0:0#
s#:-80:2:0#:-80:0:0#
s#:-50:2:0#:-50:0:0#
s#:-40:2:0#:-40:0:0#
s#:-8:2:0#:-8:0:0#
s#:011a0000:07f6:0002:130:0#:011a0000:07f6:0002:1:0#
s#^STREAM-#BBC\ Stream\ #

[humaxboy]

First we need to now if this failure is only valid for all the VU-boxes.... -or- only the DUO....

It is the Duo and Ultimo for sure, and maybe the Uno and Solo as well. ET9200 reports the FEC correctly but system and modulation wrong (always QPSK) when set to false.

I can confirm that this failure come also Vu + Uno. Look at my topic at http://openpli.org/f..._fromsearch__1.
First problem with Turksat 42 E, 11896 H DVB-S2/8PSK 11200 2/3. But you can take any DVB-S2/8PSK signal on Astra, same issue, it shows DVB-S/QPSK.

Humaxboy