[PATCH] Farbige progressbar, SNR/BER-Anzeige in Infobar

[JtG-Riker]

Ich hab da noch ein "Schönheitsproblem" beim BER Wert

Ber ist maximal angegeben mit 262143 - bei Nokia Kabelboxen mit QAM256 Sendern ist der auf z.B. ZDF je nach Tunertoleranz zwischen 10000 und 80000 - so um den dreh.

In der Anzeigt im OSD wird aber dann schon 100% angezeigt, also viel zu früh.

Kann mal jemand im Code nachsehen warum da schon so früh 100% angeezeigt wird?

Gruß Riker

[Gaucho316]

Weiß denn wirklich niemand, warum 100% schon so früh erreicht wird? In infoviewer.cpp wird in Zeile 171 mit 40000 gerechnet, obwohl der Maximalwert von BER ja 262143 ist. Woher kommt also der Wert 40000?

Edit: Eben schoss mir in den Kopf, dass das vielleicht nur ein Schreibfehler ist. 0x40000 sind nämlich 262144 und 0x400 einfach 1024.

[rhabarber1848]

Ungetestet:

Code: Alles auswählen

--- apps/tuxbox/neutrino/src/gui/infoviewer.cpp	2011-11-13 20:25:50.000000000 +0100
+++ apps/tuxbox/neutrino/src/gui/infoviewer.cpp	2011-11-25 17:42:40.000000000 +0100
@@ -168,7 +168,7 @@
 	if ((signal.ber > 0) && (signal.ber < 400))
 		ber = 1;
 	else
-		ber = signal.ber * 100 / 40000;
+		ber = signal.ber * 100 / 0x40000;
 
 	// Sometimes the Ber is larger than the Max Ber so therefore needs to be stopped here if (bar > max ber)
 	if (ber > 99)

[Gaucho316]

Ich würde das radikal einkürzen. Der folgende Code sollte auch reichen. Auch der ist aber ungetestet.

Link entfernt, da Patch im CVS

[seife]

noch kürzer:

Code: Alles auswählen

ber = signal.ber / 2622;

Den Rest weg, wie bei dir.

[JtG-Riker]

Hab jetzt den Patch von Gaucho ma eingespielt, sieht besser aus, ich hab hier so ein Pegelregler wenn ich BER auf ~100000 stelle kommt BER 40% - nicht mehr 100% - schon mal prima

Seifes Änderung is abr nicht noch drin, das hab ich nicht verstanden *duck*

Gruß Riker

[rhabarber1848]

Seifes Änderung is abr nicht noch drin, das hab ich nicht verstanden *duck*

Der folgende Code sollte auch reichen.

Code: Alles auswählen

+	ber = signal.ber * 100 / 262143;

bringt dasselbe Ergebnis wie

noch kürzer:

Code: Alles auswählen

ber = signal.ber / 2622;

[Gaucho316]

noch kürzer:

Code: Alles auswählen

ber = signal.ber / 2622;

Das mag ja kürzer sein, aber die ausführlichere Rechnung finde ich übersichtlicher. Ist der Compiler eigentlich so schlau und optimiert das irgendwie selbst, d.h. rechnet 100 / 262143 aus und kompiliert das Ergebnis ein? Ich habe von so etwas keine Ahnung.

[doc]

Klar ist der Compiler so schlau.
Aber kannste schnell gegen prüfen, baue die beiden Versionen durch. das Endergebnis wird Bitgleich sein.

Klar ist die kurze Variante etwas schlechter zu lesen. Aber dann ein passender Kommentar im Code und jeder kann dann nachvollziehen warum das so eingecodet ist. Ein sinnvoller Kommentar wird mehr bringen wie lange Codekonstrukte.

[MarcM]

blöde Frage....

warum wird denn da auf- und nicht abgerundet ?

Marc

[rhabarber1848]

infoviewer_fix-ber-display_2011-11-25_1811.diff

committed to CVS: http://article.gmane.org/gmane.comp.vid ... x.scm/3158

[Gaucho316]

blöde Frage....

warum wird denn da auf- und nicht abgerundet ?

Das ist keine blöde Frage sondern ein guter Einwand. Wenn man mit 2622 rechnet, kommt man maximal bis 99, da 262143/2622=99,978... ergibt, was in int umgewandelt nur 99 ist. Mit 2621 kommt man bis 100, da 262143/2621=100,016... ist. Ich wäre übrigens immer noch dafür, die ausführliche Rechnung zu nehmen.

[doc]

Ändert das etwas am Endergebnis?

[GetAway]

Ihr rechnet mit integer. Integer schneidet die Nachkommastellen ab.

Code: Alles auswählen

wert = 100,0 +0,5 = 100,5 -> int = 100
wert = 100,4 +0,5 = 100,9 -> int = 100
wert = 100,5 +0,5 = 101 -> int = 101 usw.

Deswegen ist gaucho's Variante besser.

[doc]

Das liegt in der Natur der Dinge, int Zahlen sind nun mal Ganze Zahlen.
Aber für Prozentangaben würde ich auch keinen anderen Datentyp nehmen wollen, insofern gibt es keinen besseren Weg meiner Ansicht nach. Mehr wie 100% können nun mal nicht erreicht werden, wenn dann da 101% steht dann passt der Algo dahinter nicht. Also dann das Einbauen was Gaucho gepostet hat.

[rhabarber1848]

Mit 2621 kommt man bis 100, da 262143/2621=100,016... ist.

committed to CVS: http://article.gmane.org/gmane.comp.vid ... x.scm/3159

[GetAway]

Die Frequenz entweder Khz angeben oder 3 Stellen vorm Komma kürzen.

[Gaucho316]

Ich habe noch nie auf diesen Wert geguckt, aber jetzt, wo du's sagst ...
In streaminfo2.cpp wird in den Zeilen 638 bis 645 eine Fallunterscheidung zwischen Kabel und Sat gemacht. Das muss dann hier auch gemacht werden.

Edit: Müsste in Zeile 645 von streaminfo2.cpp nicht eigentlich si.tsfrequency%q statt si.tsfrequency%1000 stehen?

Edit: Für Kabel ist das im Infoviewer und in StreamInfo2 kaputt. Ich mache dafür morgen einen Patch.

[GetAway]

Bei streaminfo2.cpp kann ich keinen Fehler erkennen. Werte sehen bei mir gut aus.
Frequenz bei Pro7 370.904 MHz

Dafür liefert pzapit -gsi bei Kabel das falsch.

Code: Alles auswählen

/var # pzapit -gsi
frequency = 370017.904 MHz
onid = 0x0001
sid = 0x445d
tsid = 0x0453
pmtpid = 0x0061
vpid = 0x01ff
apid = 0x0200
spid = 0x0000
spage = 0x0000
pcrpid = 0x01ff
vtxtpid = 0x0021

[Gaucho316]

Frequenz bei Pro7 370.904 MHz

Dort müsste aber 370.017904 MHz stehen.

[GetAway]

Jetzt sehe ich es auch. Beim hochauflösenden Neutrino ist es auf 370.0 MHz gerundet.

[DrStoned]

Die Frequenz stimmt auch unter technische Information -> Stream Information nicht, zu erreichen über rote Taste -> blaue Taste.

Greetz von DrStoned

[Gaucho316]

Die Frequenz stimmt auch unter technische Information -> Stream Information nicht, zu erreichen über rote Taste -> blaue Taste.

== CStreamInfo2 in streaminfo2.cpp

Für Sat müsste das aber zumindest vor dem Komma stimmen. Nach dem Komma werden nämlich mögliche führende Nullen nicht beachtet. Aber die Einheit MHz müsste richtig sein. Das eigentliche Problem ist, dass g_Zapit->getCurrentServiceInfo() für Kabel Hz und für Sat kHz liefert.

[GetAway]

Nicht das beim Scannen auch noch so eine Gurke drin ist und daher die diff Werte im Log kommen. Sind ja immer die letzten 6 Stellen (ohne führende 0), die später als Differenz ausgegeben werden.(Kabel)

[Gaucho316]

Ich habe nun einen Patch für pzapit, den Infoviewer und StreamInfo2 erstellt, der die Frequenzanzeige korrigiert.

Link entfernt, da Patch im CVS