Bug: zapit

[Coronas]

Hi,

seit ca.10 Tagen speichert bei mir der Sendersuchlauf die Transponder, die eine FEC von 5/6 haben, in der services.xml mit dem Parameter fec_inner="5" ab. Wäre ja im Grunde genommen logisch, aber ein Bild sieht man nur, wenn man den Wert auf fec_inner="4" abändert...
Teste mit einer Nokia 2*I Sat, aktuelles CVS von vor einer halben Stunde.
cu

[Janus]

Ja, ja. Da nutzt man XML und 'codiert' dann doch wieder ...

1 = "1/2"
2 = "2/3"
3 = "3/4" - und nun der 'Gedankenwurm'
4 = "5/6"
5 = ?

Warum einfach, wenn's auch kompliziert geht!

Janus

[thegoodguy]

Also der Sprung mit den Raten ist nur in den alten Treibern.
In den neuen gilt:

Code: Alles auswählen

typedef enum {
        FEC_NONE = 0,
        FEC_1_2,
        FEC_2_3,
        FEC_3_4,
        FEC_4_5,
        FEC_5_6,
        FEC_6_7,
        FEC_7_8,
        FEC_8_9,
        FEC_AUTO
} fe_code_rate_t;

Somit ist fec_inner="5" in den services.xml bei den neuen Treibern richtig.
Warum dies aber nicht klappt, steht auf einem anderen Stern.

[Coronas]

Hm.

Schon mal super, dass ihr da ein bischen Logik reingebracht habt - ich war mir nie sicher, wie in der Vergangenheit eine FEC von 7/8 definiert war
Ich nutze den neuen ves1x93-Treiber, mit dem meinem Frontend entsprechenden Boardtype...
cu

[obi]

@Janus:
4/5 z.B. ist nicht DVB

- obi

[Janus]

Das ist mir schon klar.
Auch die Falle, die sich durch die Anwendung einer Enumeration auf eine solche 'gebrochene' Reihe auftut. Wobei die Lösung, die Enumeration durch nicht konforme 'Füllwerte' menschenlesbarer zu machen, recht listig ist. (aber irgendwie unprofessionell aussieht)

Und: jede Änderung einer Enumeration hat die Änderung des Parsers zur Folge. (Sowohl Mensch s.o., als auch Maschine [Settingseditor, Converter o.Ä.])
Eine der (für mich) sinnvollen Evolutionen in XML als Datenbeschreibung war die Abkehr von maschinenspracheverursachten Codierungen, hin zum 'lesbaren' Dateninhalt. (Was bei Prozessoren und Speicher mit 'Giga'-Leistungsattributen im PC Bereich auch zu verkraften ist)

Wenn ich im Tag oder Attribut 'fec' den Inhalt "5/6" erhalte, kann das nur eine FEC von 5/6 bedeuten. Warum nicht "h" für horizontal, "v" für vertikal? Das macht die Sache eben so schön unabhängig von der weiterverarbeitenden Logik. Ich persönlich würde den evtl. knappen Platz in der Box lieber über die Tagbezeichner als mit dem Dateninhalt sparen wollen. Wenn ich dann für meinem Bedarf eine Enumerierung brauche, mache ich mir danach eben (heimlich ) eine. Aber die muß dann nur ich verstehen.

Janus

[Chucky]

Janus ... wie er leibt und lebt. *fg*

Deine Postings musste man schon immer dreimal lesen, bevor man versteht was da steht *ggg* Siehe Satpage!

Aber immer wieder schön was von Dir zu lesen!

[obi]

@Janus:
schick ein patch

- obi

[Janus]

Erwischt!

Für's Patchen hatte ich bisher HumFree und die TuxOnHumax-Truppe.
Für's Coden habe ich (im vorigen Jahrhundert) als Einzelkämpfer überwiegend MS-"Spaghetti"-Basic aus dem vorigen Jahrhundert benutzt.
Für's CVS bin ich nach reichlich 3 Wochen Cygwin-Selbstversuchen noch nicht erfahren genug!
Und (richtiges) Linux ist gerade erstmal in Vorbereitung (Mandrake Isos sind gebrannt, alte 30 GB Platte ist eingebaut.)
Und von C habe ich schon garkaumeine Ahnung. (Ich arbeite zwar dran, aber: Hobby...)

So kann das also Nix werden.

Was ich z.Zt. anbieten könnte, wäre die lockere Mitarbeit an der Definition/Gestaltung von optimalen Settingsdaten. Da liegen meine Interessen aber mittelfristig auch an Erweiterungen, die den 'Gebrauchswert' des Receivers erhöhen. Da ich aus der Humax-Ecke komme, hätte ich dazu auch schon die eine oder andere Anregung. (die ich [s.o.] momentan aber nicht selbst umsetzen könnte)

Janus

[Janus]

Mein nigelnagelneues Mandrake versucht gerade ein make all auf rel_1_0_0.
Habe daher etwas Zeit zum stöbern.

- Im CVS habe ich kein Schema (.xsd) o.Ä. für XML-Dateien gefunden.

- Eine einigermaßen zentrale Struktur-Dokumentation habe ich auch nicht gefunden.

- Aus diversen Objektdeklarationen und Konstanten-Festlegungen lassen sich wohl notwendige Angaben zusammensammeln (dafür braucht man aber scheint's die große Übersicht über den gesamten Quelltext)

- Eine Validierung der verwendeten XML-Daten hat wohl noch nie stattgefunden. (Ein Versuch mit hier aus dem XML generierten Schemas ist flugs (gleiche ID) gescheitert)

- unpraktische (identische) Tag-Bezeichnerwahl in bouquets und services


Ein erster Schritt sollte demnach die Festlegung eines Schemas für die zu verwendenden Daten sein. Ich würde im Laufe der Woche mal einen Entwurf anfertigen, der aber dann von DVB- und C-Kundigen gegengelesen und entsprechend erweitert/gekürzt/angepasst werden muß.

Janus

[obi]

hi,

wozu das ganze? auf nem schnellen rechner okay, aber das ist nen lahmer ppc. uebertreib es nicht. ausserdem haben so grosse aenderungen im release branch eh nix verloren. das zapit da wird nurnoch gebugfixt. sonst nix. gilt auch fuer die anderen programme.

vielleicht waers doch besser, die settings in nem binaerformat zu speichern.

- obi

ps:
ich finde uebrigens die zuordnung
1 <-> 1/2,
2 <-> 2/3,
3 <-> 3/4,
4 <-> 4/5
usw. ziemlich leicht zu merken...

[Janus]

Wozu das Ganze?

1) Ausschließen, daß bestimme (Zuordnungs-)Fehler an den XML-Daten liegen.
2) Prüfung zugespielter Daten auf Korrektheit.
3) Verwendung der Box auch für andere Orbitalpositionen als das 'ausgetestete' Astra-System. War da nicht was mit Hotbird, Turksat (Kein Dev-LNB, nicht gefunden, kein Bild, kein Ton)?
4) Entwicklungsgrundlage/Typsicherheit für externe Editoren. Es gibt Leute, die nicht nur eine dBox haben (für die bei den bescheidenen Organisationsmöglichkeiten der Settings der interne BE wirklich ausreicht) Eine receiverübergreifende Settingsbearbeitung verlangt etwas mehr 'Grundsätzliches'
5) Als Ansatz für Settingsaktualisierung über das Netz (Download, WebService)
6) Als Ausgangspunkt für spätere Erweiterungen/Verbesserungen (?) des UI, die über Einträge in den Settingsdaten gesteuert werden können.

Mehr fällt mir auf die Schnelle nicht ein.

Axo: das da oben ist momentan sicherlich nix für den Release Branch.
Da ist aber auf jeden Fall (cramfs v. 10.10) die Zuordnung Bouquets-Services nicht fehlerfrei. Eindeutig wäre "SatID:ONID:TSID:SID"
Aktuellen Stand kann ich aber im Moment noch nicht testen, da make all bei enigma mal wieder (wie cygwin auch) mit der libpng-Meldung ausgestiegen ist. Muß den Rest also einzeln maken.

Binär-Format: Diese Änderung dürfte auch nicht in 10 min erledigt sein. Und der geschätzte(?) User hat danach kaum noch eigene Optionen für die externe Bearbeitung!

Janus

ps:
Ich finde
"1/2" = 1/2
"2/3" = 2/3
"3/4" = 3/4
"5/6" = 5/6
usw. noch leichter zu merken. (wenn ich das mal aus der menschlichen Warte sehe )

[grini]

@obi

...
vielleicht waers doch besser, die settings in nem binaerformat zu speichern.
...

diesem Gedankengang kann ich mich voll und ganz anschließen. Die Vorteile liegen auf der Hand:
Das Lesen/Schreiben geht leichter,
Parsen/Dekodieren entfällt - also schneller - weniger Fehlerträchtig,
geringerer Speicherbedarf,
eine feste Struktur kann mit einer Prüfsumme auf Gültigkeit geprüft werden.
z.B.
struct tag_Header {
char cID[4] // Kennung
int nVersion // Version
int nCRC32 // Prüfsumme
int nItems // Anzahl folgende Einträge
char cReserved[n] // für spätere Erweiterungen
sItems[0] // Einträge 0..n
}

struct tag_Item {
// irgendeine Definition
}

na obi, wie wär's mit einer Änderung im aktuellen CVS ?!

[buelent]

Ihr verplanten Coder habt doch eh keine Ahnung vom Zappen, bei euch Brillentraegern laeuft doch nur 24/7 x-zone bei 22 MSYNCS/PROs.
Ihr habt ja nicht einmal 42°E im Haus, ihr Astrosen...


buelent

[DieMade]

@buelent: na, nix schönes vom Weihnachtsmann bekommen?

[obi]

hrhrhrhr...