Hallo Leute,

wenn man über das WebInterface einen Timer editiert, wird das Feld "Name" immer mit "N/A" und "Description" immer mit "1" gefüllt.
Der Effekt hängt an keiner bestimmten Namensgebung oder sonstigen Eingaben, er ist mit jeglichen Eingaben reproduzierbar.
Ich hoffe das ist bald behoben, da ich viel an den Timern im WebIf herumbastle.

LG
dandjo

Zitat

Originally posted by ritzMo

Was ist da bitte doppelt negiert? "Do x if not y" ist eine Negation, "Don't do x if not y" wäre doppelt, ist hier allerdings nicht gegeben.

*grübel*grübel*schäm* Stimmt, hast recht. Trotzdem, das "not" hat zumindest mich vollkommen verwirrt und verunsichert. Als ich dann die Erklärung hier gelesen habe, habe ich es dann auch richtig gelesen und verstanden. Dennoch fände ich eine positive Formulierung ohne "not" einfacher zu verstehen und sprechender. Sollte nur eine Anregung sein.

Zitat

Originally posted by ritzMo

Ja.

Alles klar, vielen Dank!

Zitat

Originally posted by mozo
Bei mir ist nach einem Durchlauf Schluss.

Danke! Das heißt, das Plugin schaltet (in meinem Fall) im Zeitraum von 3 bis 6 Uhr Früh irgendwann einmal meine konfigurierten Sender durch?
Mal angenommen, wenn ich von 2 bis 7 Uhr Früh mit meiner Dreambox fernsehe, und die "Force" Option nicht aktiviert habe, zieht der EPGRefresh nicht. Habe ich die Zeitraum-Einstellung so richtig interpretiert?

Zitat

Originally posted by SiennaRoot
wenn ich die Optionen richtig verstanden habe, arbeitet die Automatik des EPG Refreshs nur im STAND-BY & wenn KEINE Timer aktiv sind (Aufnahme läuft), ausser ich setze die "force" Option. Ist das so richtig interpretiert ?

Zitat

Originally posted by SiennaRoot
Ja, richtig interpretiert.

Erstmal danke für das tolle Plugin! Weiter so!

Ahaaa. Die Option "Force scan even if not in Standy or Recording [enable | disable]" hätte ich zum leichteren Verständnis dann eher so formuliert: "Force scan even if box is powerd on or recording [enable | disable]". Ich musste dieses Forum erst aufsuchen um das zu kapieren. Doppelte Negationen sind schwer zu verstehen und macht immer unsicher.

Dazu noch eine Frage. Wenn ich "Refresh EGP after" auf 03:00 und "Refresh EPG before" auf 06:00 setze, geht das Plugin her und schaltet je nach Minuteninterval von 3 bis 6 Uhr in der früh ständig alle konfigurierten Sender durch, richtig? Läuft das im Loop oder ist nach einem Durchlauf alles Sender Schluss?

Danke schonmal!

Stimmt.

Hier habe ich mal Windows Batch-Skripte geschrieben, die anhand einer Konfigurationsdatei die Picons von Name nach Referenz oder umgekehrt wandeln. Die Konfigurationsdatei besteht aus Name und Referenz, getrennt mit Strichpunkten. Hat man sich mal eine Konfigurationsdatei angelegt, kann man seine Picons ganz einfach verwalten. Viel Spaß damit.

Zitat

Vermutung: Es gibt einige Sender mit Zeichen im Namen, die in einem Dateinamen nicht möglich sind (z. B. "/"), für die konnte in der alten Version kein Picon benutzt werden.

Das kann man ganz einfach umgegehen. Den "/" interpretiert die DreamBox als Verzeichnis, also legt man für den ServiceNamen "Sender/Nochwas" einfach "/etc/picon/Sender/Nochwas.png" an. Funktioniert super.

Sieht toll aus. Könntest du mir mal eine "alpha" Version des jetzigen Standes zukommen lassen? Gibt es wo ein öffentliches Source Projekt?

Das mit dem Streamproxy ist in der Tat ärgerlich. Mich stört es eigentlich ständig, dass der Tuner nach dem Streamen (auch mit VLC) nicht sauber freigegeben wird. Abhilfe verschafft hier lediglich der Stop Button im VLC, aber das funktioniert auch nicht immer.

Hi LazyT,

ich suche schon ewig ein DreamStream E2 für meine 7025 und 800. Wie geht es deiner Entwicklung?
Wäre mplayer eine alternative für deine Software? Damit kenne ich mich gut aus.

LG
dandjo

Versuche mal auf RGB zu stellen und dann die Box ganz neu zu booten.
Ich habe einen ähnlichen Effekt auf der 7025+. Wenn ich im AV-Menü zwischen Y/C und RGB hin- und herschalte, wird das Bild nach dem ersten Schalten von Y/C zu RGB grünstichig. Lasse ich dann RGB und boote neu, ist der Grünstich weg. Das passiert jedes mal wenn ich im AV-Menü über Y/C drüberstolpere.

Hier noch ein paar Screenshots von einigen Sendern. Es ist wirklich kein eindeutiger Trend erkennbar. Manche nutzen die ganzen 720x576 Pixel aus, manche nutzen nur die 702x576 Pixel, manche überhaupt andere Bereiche.

Was nun die Norm ist und welche Sender hier aus der Reihe tanzen, würde mich auch brennend interessieren. Im Endeffekt wird es aber darauf hinauslaufen, dass sich keiner wirklich daran hält und die Receiver dies ohnehin nicht 100%ig korrekt unterstützen können.

Nachtrag: Ich habe mir das nun noch einmal angesehen. Alle Receiver und DVD Player, die ich habe, schneiden links uns rechts vom Bild genau diese 18 Pixel von den 720x576 Pixel weg, um die 702 aktiven zu erhalten. Auch MPEG Streamclip tut das, wenn man ein 4:3 oder 16:9 Bild als Still-Frame oder mit einem PAR von 1:1 exportiert. Das hat schon etwas auf sich. Es sieht ja nicht umsonst das Testbild von Burosch auf jedem von mir getesteten TV aus wie ein flach liegendes Ei. Erst wenn man es auf 702 Pixel Breite umrechnet, passt der Kreis. Dass das alle Geräte falsch machen, kann ich mir keinesfalls vorstellen. Sendern, die diese zusätzlichen 16 Pixel ausnutzen, muss es bewusst sein, dass man diese Pixel im normalen TV Betrieb ohnehin nie zu sehen bekommt. Zudem muss das PAR, obgleich man diese 16 Pixel ausnutzt oder nicht, auf 702 Pixel angepasst sein, sprich einen PAR von 768:702 besitzen.

Die 45 für pal_v_start sind logisch relativ einfach erklärbar.

PAL besitzt 625 Zeilen, davon 576 aktive. Das erste aktive Halbbild beginnt bei Zeile 22,5 und endet bei Zeile 310. Jetzt folgt die vertikale Austastlücke mit ca. 25 Zeilen Dauer (22,5 Zeilen + horizontale Austastlücke). Das zweite Halbbild beginnt dann bei Zeile 336 und endet bei Zeile 623,5. Dann bleiben noch 1,5 Zeilen, die sich mit den 22,5 im ersten Halbbild wieder auf ungefähr 24 Zeilen Dauer addieren, die der Elektronenstrahl von rechts unten nach links oben benötigt. Das sind ungenaue Werte, da hier sehr viel Spiel möglich ist. Im Groben kann man sagen, dass die aktiven Inhalte beide Halbbilder, wenn man immer bei 0 (sprich von oben) startet, bei 22,5 Zeilen beginnen.

Da sich die Werte im Treiber höchstwahrscheinlich auf Vollbilder beziehen, muss man die 22,5 Zeilen, die im ersten Halbbild in die vertikale Austastlücke fallen mal 2 nehmen, womit man auf die 45 (= 0x2d) kommt. Ob man nun bei 43 oder 47 beginnt, ist nur ein Rundungsfehler, 45 ist aber definitiv die goldene Mitte, die sich erwiesenermaßen auch in anderen Geräten so konfiguriert vorfindet.

Zitat

Originally posted by Rafiki
Bei 'Square Pixel' wären es 944 Pixel / Zeile bei 768 aktiven. Die Austastlücken werden ziemlich sicher nicht mitübertragen, wäre ja ein gewaltige Verschwendung.

Ok, überzeugt.

Zitat

Originally posted by Rafiki
Sorry, ich muß hier editieren - da passt was nicht zusammen. Wenn 864Pixel 64µs sind (laut CCIR 601), dann sind 720 aktive Pixel 53,3µs. Wahrscheinlich hat man bei der Festlegung der 720 schon etwas Reserve eingerechnet (aktiv im Analogen sind ja 52µs) weil eine so exakte Synchronisierung und Stabilität vor einigen Jahren noch nicht möglich war und man auf analogen TVs die exakt eingestellt sind und dann ev. um 0,5µs wegdriften, nicht einen störenden Balken auf der Seite haben wollte.

...

Wenn 720 Pixel 64µs wären, dann wären 702 Pixel 62,4µs. So kann das nicht stimmen. Also 864 Pixel sind 64us, 720 Pixel sind 53,3333us und 702Pixel sind 52us.

Dann stimmt die Ausgabe. Wenn du dir anschaust, wie ein standardkonformes MPEG2 PAL daherkommt (wie z.B. vom ORF).
Siehe http://www.dream-multimedia-tv…ent.php?attachmentid=1718
Dieses MPEG2 enthält 702 aktive Pixel bei einer breite von 720 Pixel. Manche Sendeanstalten belegen die ganzen 720 Pixel, was meines Wissens jedoch nicht konform ist.

Zitat

Originally posted by Rafiki
Ich glaub auch nicht, daß die Box das sooo falsch macht. Ich kann jetzt nicht die ganzen Berechnungen hier nachvollziehen, aber ich denke da liegt irgendwo ein Denkfehler oder Rechenfehler drinnen. Möglicherweise ist es aber auch so, daß ev. die Sender nicht immer (Programmabhängig?) die ganzen 720x576 auch wirklich ausnützen. Das ist jetzt aber nur eine Vermutung von mir.

Tun sie auch nicht. Man sieht in 98% der Fälle einem MPEG2 Transportstrom links und rechts immer diese schmalen Balken, die je nach Bildinhalt sogar innerhalb der Sendungen selbst variieren. Das liegt einfach daran, wie die Kameras und die Chips das optische Bild abgreifen.

Zitat

Originally posted by Rafiki
Das müßte man mal verifizieren, wenn man wirklich alle 720 Pixel vom Sender auch ausgibt und zwar innerhalb von 53,333333us. Dann könnte man das auch nachmessen und von anderen Effekten (overscan des TVs) auseinander halten.

Mit den schmalen Balken links und rechts erhält man ja die 52 µs im analog gewandelten Signal wenn man die 720 Pixel auf die 53,333333 µs legt.

Wenn wir von den ursprünglichen Werten 21a und d2b für pal_h_start und pal_h_end ausgehen, sind das horizontal 2833 Werte gewesen. Nehmen wir also weiter an, dass der Prozessor mit 53 MHz taktet kommen wir auf folgendes.

2833 / 53 Mhz = 53,4528301

Wenn 53,333333 µs 720 Pixel entsprechen, war der Wert schon nahe am Optimum. Absolutes Optimum wäre.

53,333333 µs = X / 53 Mhz
X = 53,333333 µs * 53 MHz
X = 2826,666666

Somit hätten wir für die 702 aktiv ausgenutzten Pixel im MPEG2 Transportstrom die 52 µs für das analoge Ausgabebild. Von dem her war meine Ursprüngliche Berechnung für die h-Werte falsch.

Wenn wir die 2826,666666 Werte so nehmen und zurückrechnen kommen wir auf folgende Werte. Diese sind optimal, vorausgesetzt die Taktfrequenz mit 53 stimmt in etwa (zweite Kommastelle ist vernachlässigbar, die erste ist schon noch ausschlaggebend).

2833 - 2826,666666 = 6,333333
6,333333 / 2 = 3,1666666 ~ 3
538 (0x21a) + 3 = 541
3371 (0xd2b) - 3 = 3368

Daraus folgt.

pal_h_start > 21d
pal_h_end > d28

Ich werde die Werte mal heute Abend beobachten und berichten. Wenn sie passen, müssen sie eben noch ein mal angepasst werden im Treiber.

Zitat

Originally posted by Rafiki
Ich sehe gerade, in der ITU-R BT.656-5 stehen auch die hier gesuchten Werte drinnen -
Field blanking from Line 624 to 22 (inklusive) und 311-335. Macht zusammen 49 Zeilen --> insgesamt 576 aktive. Erste aktive ist demnach 23 und 336.

Der Wert 2D für das derzeitige pal_v_start wäre bei Zeile 45.

45 - 23 = 22

Pal_h_start passt oder? Oder wie würdest du diese Norm auf unsere Werte umsetzen?

tmbinc & Entwickler:
Kann man die genaue Taktfrequenz mal eruieren und verifizieren? Dieser Faktor ist der entscheidendste, wenn man genau berechnen will.

Update: Zwischen den Werten, die jetzt im Treiber sind und denen von mir hier neu berechneten, sieht man keinen Unterschied. Die feinen Linien in meinem Testbild sehen mit den hier berechneten Werten genauso aus wie mit den aktuellen Werten im Treiber.

Wenn man berechnet, kann man den Unterschied auch nicht sehen. Das sind im Vergleich zum ursprünglichem Wert nur 2 Werte horizontal Unterschied.

0xd27 - 0x21e = 0xb09 (2825) ... im aktuellen Treiber
0xd28 - 0x21d = 0xb0b (2827) ... hier berechnet


2825 / 53 MHz = 53,301887 µs

Da ich die Werte d27/21e für geometrisch richtiger empfand (Referenzbilder), denke ich, dass die aktuellen schon passen. Zudem ändern die rein rechnerisch exakteren Werte kein Bischen am Bild. Wenn die Taktfrequenz des Prozessors auch nur um eine Kommastelle höher oder geringer ist, sind die Werte rechnerisch ohnehin wieder falsch. Ich würde mich also eher auf das Referenzbild berufen und die Werte so lassen, wie sie jetzt sind.

Berücksichtigst du bei deiner Überlegung auch die Aspektverzerrung? Die 720 Pixel sind ja gestaucht, sprich schmäler als hoch. Meiner Ansicht nach ist die horizontale Austastlücke mit vorderer und hinterer Schwarzschulter sehr wohl in diesen 720 Pixel vorhanden, oder ist das komplett falsch angedacht?

Wenn ich deinen Gedankengang nun folge, dann müssten die 52 µs des analogen Signales (also ohne Austastlücke) mit 720 Pixel abgetastet werden um bei 64 µs auf 864 Pixel zu kommen, richtig?

Wenn ich also so weiterdenke und das DVB-S Signal mit deinen 720x576 Pixel (im Optimalfall) hernehme und wieder auf die 52 µs analog wandle, passt alles. Die Berechnungen auf Seite 11 (Vertikaler Bildversatz) verdeutlichen aber, dass 702 Pixel auf die 52 µs gelegt werden und 720 auf die 64 µs.

Wenn die Dreambox das wirklich falsch macht, machen es zig andere Markenhersteller auch falsch, was ich nicht ganz glauben kann.

Es kommen ja nicht 864 Pixel pro Zeile daher sondern 720 passiv und 702 aktiv. Da wird ja nicht skaliert, sondern einfach die 720 Pixel in die 64 µs Zeilendauer analoggewandelt. Wenn man von diesen Umständen ausgeht, wo würde hier skaliert werden?

Ist in der Entwicklung von DMM gerade Sommerpause oder warum meldet sich keiner?

Das mit den schwarzen Effekten ist glaube ich schon gefixet.

Teste mal den Stream von pieterg oder mir.

Bitte dieses Thema hier weiterdiskutieren.

Bug: Fehler im Bild

Gibt es denn diesbezüglich keine Aktivitäten seitens der Entwickler mehr?

Wunderbar, besten Dank!

Wenn dann auch noch der Bug mit der Farbverschiebung gefixet ist, kann sich das Bild der 7025er wieder sehen lassen.

tmbinc: Ich sehe gerade, die neuen h-Werte sind nicht in dem neuen Treiber. Vielleicht hast du das überlesen. Hier nochmal die letzten von mir als die "besten" herauskristallisierten Werte. Bitte auch noch die h-Werte anpassen. Danke!

2d > /proc/stb/video/pal_v_start
26d > /proc/stb/video/pal_v_end
21e > /proc/stb/video/pal_h_start
d27 > /proc/stb/video/pal_h_end

Nachtrag: Ich würde dringend empfehlen die h-Werte noch anzupassen, da ich mit den 21c/d29 Werten bei manchen Sendungen horizontale Streifen sehen konnte, die mit den 21e/d27 Werten nicht auftreten.