Nö sieht alles ganz normal aus.
RGB [Moderator] Fremdimage, verstößt gegen die Boardregeln [/Moderator]

ich mach mal schnell die 3.40

mit 3.40 auch keine Auffälligkeiten.

Habe weder Unschärfe noch Probleme mit den Halbbildern.
Muss wohl an der nachträglichen Bearbeitung in deinem Monitor liegen.
Hab hier einen M1921A von LG.

beste Grüße
adenin

Ich nicht.

Oh, ich hab da keine Ahnung, ob da was faul ist. Da müsste ich schon die Testbilder haben um das zu untersuchen. Ich weiß im Moment auch nicht, ob die Werte, wenn man das Bildformat ändert, zurückgesetzt werden (dann müsste man ein Script schreiben, das dies wieder rückgängig macht). Möglicherweise ist aber auch der Monitor/TV mit schuld.
Das Wissen ist nur ein Abfallprodukt aus der Forschung für gutemines QuickTV.

beste Grüße
adenin

Zitat

Vielleicht auch noch interessant: Um Probleme mit dem Zeilensprung zu vermeiden, sollte man immer nur Änderungen von einem Vielfachen von 2 Zeilen vornehmen (da ansonst das untere Halbbild das obere darstellt und umgekehrt > Sync und Deinterlace Problem am TV)

Das ist wirklich interessant, werde ich heut Abend mal ausbrobieren.

Zitat

Verdammt, nach einem reboot sind wieder die Standardwerte drin!

Bau's doch in eines der Startscripts ein.

In der 7025 könnt Ihr das Bild stauchen und auseinanderziehen, in dem Ihr die Parameter /proc/stb/video/pal_v_start und /proc/stb/video/pal_v_end ändert. Die Änderung wird nach Umschaltung auf einen anderen Sender wirksam.

Standartwert für pal_v_start ist hex 0x27
Standartwert für pal_v_end ist hex 0x267

Wenn also oben ein Stück fehlt, dann kann man zB. mit

echo 37 > /proc/stb/video/pal_v_start

das Bild etwas stauchen, in dem der Bildstart um 10 Zeilen nach unten verschiebt (Achtung, es handelt sich um Hexadezimalwerte). Wenn das Bild nicht gestaucht werden soll, sondern nur verschoben, dann mussman eben auch pal_v_end um 10 erhöhen.

echo 271 > /proc/stb/video/pal_v_end

Das geht auch mit der horizontalen

Standartwert für pal_h_start ist hex 0x21a
Standartwert für pal_h_end ist hex 0xd2b

Das ist brauchbar, um zB. ein Minibild im Sendermenü ähnlich von Baumarktreceivern zu erzeugen.

beste Grüße
adenin

NeSi
Ich denke nicht, das das am Tuner der 7025 liegt. Das Problem ist eher, das man mind. einen 80cm Spiegel benötigt um Astra 19.2° und Eutelsat W2 sauber zu trennen. Der Grund ist ist nicht die Signalstärke des Eutelsat W2, da würde theoretisch eine 50cm Schüssel reichen, sondern, das auf 19,2° 10.964 GHz H das ZDF analog ausgestrahlt wird, das Alsat einfach überstrahlt, wenn man beide Positionen nicht räumlich sauber trennen kann. Und dazu braucht man eben einen großen Spiegel.

tmbinc
Wir verwenden StandartLNB's. Die Ablage stört mich nicht, weil ich nicht jede Transponderfrequenz einzeln korregiere (und dann in der satellite.xml abspeichere), sondern ich korregiere damit LFOlow und LOFhigh. Schließlich sind die Transponderfrequenzen ja konstant.
Selbst die miesesten LNB's hatten bisher höstens 3.5MHz Offset und der bleibt weitgehen konstant, es sei den das LNB ist wirklich von Reisbauern zusammengebaut. Bei 10MHz Basebandfilter (für wirklich kleine Symbolraten) und mit dem Wissen das praktisch nie benachtbarte SCPC-Transponder identische Symbolraten haben, kann man leicht einen Derotatorscann machen, und mit den erhaltenen Daten ganz genau die Transponderfrequenz ermitteln.
Egal, jeder hat sein eigenes Rezept.

beste Grüße
adenin

Hallo tmbinc
wann soll den der stb0899 abgekündigt worden sein? Hör ich jetzt das erste mal, hab aber mal an meinen Distri (sascoholz) gemail, was da los ist.
Zigzag verwende ich nicht, ist viel zu lahm (ich hab dir ja mal gemail was ich so mache, und mein System hat da echt nicht viel Zeit um den Satelliten zu finden). Wenn du nur den Derotator kontinuirlich duchlaufen lässt, geht das ersten viel schneller und zweitens hat Demodulator eine größere Chance zu locken, wenn die Parameter sich nicht andauernd abrupt andern.
Und für die Vorselektion der Sender ist der PLL-Chip zuständig, wozu ist den sonst seine einstellbare Bandbreite da?

Ich werd heut abend mal sehn was auf Türksat los ist, und ein paar Messungen machen.

beste Grüße
adenin

Tja, die meisten Tunerhersteller haben Tunertypen mit unterschiedlichen Linkchips im Angebot, ALPS ist macht da aber eine Ausnahme und ist von ST nach Conexant gewechselt (damit habe ich von ALPS nach Sharp als Lieferant gewechselt, der Chip war ein KO-Kriterium).
Warum man das macht?
Der ALPS-Tuner war sicher früher zu bekommen.

Das Tunernodul ist aber steckbar. Möglicherweise gibt es ja irgendwann bessere Tuner zu austauschen.

beste Grüße
adenin

Das ist natürlich schlecht.
Der Conexant-Chip hat mindesten zwei entscheidende Nachteile:
1. man kommt mit der Symbolrate nicht weit genug runter um alle Sender empfangen zu können.
2. man ist abhängig von der Firmware die Conexant für seinen Chip liefert, was bedeutet, wenn irgendwelche Bug's drin sind, kann man nix mache.

Im Moment benutze ich eine Sharp-Tuner mit STB0899. Meine Erfahrung: super Empfang, super kurze Lockzeiten bei niedrigen Symbolraten (ich hänge immer auf dem Hellas2 rum: 11.15197 GHz V 3/4 1.5kSym )

beste Grüße
adenin

Nö, ich glaube nicht, das dies der Grund für die Abstürze war. Wenn sich dieses Byte tatsächlich auswirken würde, dann auf das Bild. Aber es scheint ja ausserhalb der Datenpackete zu liegen.
Interesanterweise hab ich aber Abstürze bekommen, als ich in der idct.c nur die geradzahligen "Zeilen" der Blöcke zu Bildberechnung nehmen wollte. Dass das Bild gruselig aussehen würde hab ich erwartet, Abstürtze aber nicht. Das werde ich aber noch untersuchen.
Eine (vorerst teilweise) Umstellung von copy_chunk() und skip_chunk() von "ein Byte" auf "vier Byte" Modus brachte keine sichtbare Geschwindigkeitssteigerung. Möglicherweise ist aber noch etwas durch das Ersetzen von memcpy() durch eigene Routinen herauszuholen.

beste Grüße
adenin

Naja, ich vermute eher, dass das Verwerfen der Bilder wohl durch den Decoder erledigt wird, oder durch die Dreambox selbst, wenn irgend einer der Puffer voll läuft. Das passiert aber nur bei Sendern mit hoher Bitrate (irgendwo über 4MBit/s).
Ich kritisiere das Verhalte ja nicht, ich versuch nur, bevor ich etwas zusätzliches dazu programmiere, Schritt für Schritt rauszufinden, wie das Ding funktioniert. So findet man auch noch (ok - zufällig) Fehler im Enigma.

beste Grüße
adenin

[EDIT]
Ich nehme mir gerade den Decoder vor und habe da ein Problem.
Der Code zeigt ein Stück aus der Routine copy_chunk.
Mein Problem ist, wieso wird beim Verlassen (also wenn shift == 0x00000100 ist) der chunk_ptr noch einmal erhöht? Er zeigt doch aktuell auf die nächste zu schreibende Adresse. Damit ist doch dann ein nicht definiertes Byte im Datenstrom (ok, ausserhalb der Chunk's und damit anscheinend ohne sichtbare Auswirkung).

do {
	byte = *current++;
	if (shift == 0x00000100) {
	    int copied;


	    mpeg2dec->shift = 0xffffff00;
	    mpeg2dec->chunk_ptr = chunk_ptr + 1; <--- ??? Was soll dieses zusätzlich Pointerincrement ohne vorher Daten zu schreiben???
	    copied = current - mpeg2dec->buf_start;
	    mpeg2dec->buf_start = current;
	    return copied;
	}
	shift = (shift | byte) << 8;
	*chunk_ptr++ = byte;  <-- hier werden Daten übergeben und hinterher der Pointer erhöht, so ist das ja auch ok
    } while (current < limit);

Hat jemand eine Idee wieso das gemacht wurde?

Ja, ich werde mir mal den MPEG-Decoder vornehmen, mal sehn was sich da machen lässt. Dort gibt es die meisten Probleme. Er ist einfach noch zu langsam. Ausserdem spukt er die Bilder einfach aus ohne den richtigen Zeitpunkt anzugeben und pip zeigt die Bilder an, egal ob der richtige Zeitpunkt für das Bild da ist oder nicht, was zur Folge hat, dass das kleine Bild mal vorgeht (wenn nur geringe Bitraten vorliegen) oder nachläuft bist zu Klötzchenbildung und Ruckler, bei höheren Bitraten.

Zitat

Eine weitere Optimierungsmöglichkeit wäre vielleicht, wenn man irgendwie einbauen könnte, dass nur die Zeilen/Spalten des Bildes dekodiert werden, die auch im PiP angezeigt werden.
Wenn ich das richtig verstanden habe, dann wird bisher jeweils das ganze Bild dekodiert und dann werden die nicht benötigten Bildpunkte rausgefiltert.

Dies ist nicht möglich, es muss immer das gesammte Bid decodiert werden. Das ist eben bei MPEG2 so. Aber man könnte Geschwindigkeit gewinnen, wenn man die Rechengenauigkeit und damit aber auch die Bildqualität (die bei dem kleinen Bild aber nicht so ins Gewicht fällt) verringert.

beste Grüße
adenin

[EDIT]

Der Decoder tut doch Zeitinfos (PTS) liefern, pip nutzt sie nur noch nicht.

[EDIT]
Ich hab einige Tests mit verschiedenen Sendern gemacht. Bis ca. 4Mbit/s scheint der Dekoder sicher zu funktionieren, das betrifft die meisten Sender. Bei 4.5MBit/s gibt es mit Sicherheit periodische Bildstörungen. Kritische Sender sind: ARD ,ZDF, 3sat, ZDFinfo ...
also die meisten der größenen öffentlich rechtlichen Sender Deutschlands. Die Grenze liegt im Moment also irgendwo zwischen 4.0 und 4.5 MBit/s.
[EDIT]
Es gibt ein offensichtlich ein Problem mit dem double buffering.
Starte pip, verschiebe die Position des Bildes, beende pip und starte es erneut. pip startet an der Defaultposition aber an der verschobenen Position blitzt periodisch ein altes Bild auf.

Coronas,

lösche einfach ab Zeile 2378 diesen Code

case STATE_SEQUENCE_MODIFIED:
//Log2File("STATE_SEQUENCE_MODIFIED");


		    break;

In Version 0.4.1 der libmpeg2 gibt es kein STATE_SEQUENCE_MODIFIED mehr.

beste Grüße
adenin
[EDIT]
Ich sehe gerade das du eine eine ander Version von pip haben musst. Zeile 2378 gilt für die originale 0.7b von LacyT. Wird also bei dir ab Zeile 2425 sein.
Den Fehler mit FTC_ImageDesc kann ich nicht nachvollziehen, da ich im Moment nicht die Source habe die Du benutzt. Sende sie doch mal per PN.

[EDIT]
Mist, Doppelpost. Ich habe aber eindeutig auf Ändern gedrückt.

Coronas,

lösche einfach ab Zeile 2378 diesen Code

case STATE_SEQUENCE_MODIFIED:
//Log2File("STATE_SEQUENCE_MODIFIED");


		    break;

In Version 0.4.1 der libmpeg2 gibt es kein STATE_SEQUENCE_MODIFIED mehr.

beste Grüße
adenin

(jaja, heute nerve ich)
Ich hab gerade das pip-Plugin von LacyT ausprobiert, und dabei ist die Box mit "getCurrent - and nothing ready!" abgeschmiert.

Das Problem liegt in der Datei enigma_dyn_misc.cpp, und wird akut, wenn man an die Box über das Webinterface die Anfrage "/cgi-bin/currentTransponderServices" macht und zB. gerade keine Antenne angeschlossen hat (wie ich eben).
Der Grund für das Fehlverhalten ist: in der struct addToString wird ein tPAT.getCurrent() veranlasst, ohne vorher mit tPAT.ready() zu prüfen, ob dies überhaupt möglich ist.

beste Grüße
adenin

Na klar, mach ich.
Erste Ergebinsse: ich hab es gerade compiliert und getestet und dabei hat sich Box mit "getCurrent - and nothing ready!" verabschiedet. Das ist aber ein Bug im enigma. Da wird, wenn man über das Webinterface die Transponderabfrage macht vorher nicht geprüft ob die PAT korrekt empfangen wurde (und ich hatte gerade keine Antenne dran).
Ok, gefunden und beseitigt (meckere ich gleich mal in der Bugecke an).

beste grüße
adenin

Tausend Dank,
was man hier so alles findet. Da hätte ich hier schon mal früher alles duchstöbern müssen. An dem Teil wollte ich schon immer mal dran rumfummeln.

beste Grüße
adenin

Fehler:
Ist das Hauptmenü im Modus "Hauptmenü als normales Menü anzeigen" benutzt, dann bleibt das Drücken der Hilfetaste ohne Erfolg. Im graphischen Modus wird der Hilfstext korrekt angezeigt, wenn er sich auch auf ein Gerät vom Ende des letzten Jahrtausends (d-box) bezieht (zuletzt am 6.6.2003 aktuallisiert ).

Lösung:
In der Datei enigma_mainmenu.cpp steht irgend wo

setHelpID(10);

Das bezieht sich aber nur auf das graphische Hauptmenü.

Korrekt funktioniert das ganze so:

wnd.setHelpID(10);
setHelpID(10);

beste Grüße
adenin

Fehlerbeschreibung:
Die "Zapping History" (also das Sammelen der zuletzt gesehenen Sender in der Wiedergabeliste) wird trotz Deaktivierung im Expertenmenu fortgesetzt.

Der Grund ist, das bei der Aktivierung bzw. Deaktivierung in Wirklichkeit der Schlüssel "/elitedvb/extra/extzapping" verändert wird. Und der wiederum steuert die Verwendung des Flag "psSetMode", dass die Umschaltung zwischen TV- Radio- und Filemode beim Zappen in der Wiedergabeliste erlaubt oder verhindert.
Eigentlich müsste auf das Flag "psDontAdd" Einfluss gennommen werden, um das gewünschte Ergebniss zu erzielen.

Das scheint ja nun ein wirklich uralter Bug in meiner neuen 500plus zu sein.

beste Grüße
adenin

Nachtrag:
Ok, das ist möglicherweise kein Bug im Programm sondern in der Bedienungsanleitung sowie ein missverständlicher Menüeintrag.
Mir wäre aber doch lieber, wenn die History tatsächlich abschaltbar wäre.