Hi,
gst-plugins-base-0.10.36-r3-dream1 macht auch Probleme.
Ist der Fehler reproduzierbar?
source /Storage/dev/marc_dev/dreambox/opendreambox/bitbake.env; cd /Storage/dev/marc_dev/dreambox/opendreambox/build/dm7020hd; bitbake -cclean gst-plugins-base; bitbake gst-plugins-baseHast Du eigene Änderungen vorgenommen?
It's already there.
mtdcore
CONFIG_MTD=y ist bereits gesetzt.
Aus drivers/mtd/Makefile:
obj-$(CONFIG_MTD) += mtd.o
mtd-y := mtdcore.o mtdsuper.o mtdconcat.o mtdpart.oSquashfs wird nicht benutzt, da es in Verbindung mit Unionfs (wie bei der 7025 benutzt) bei Updates langsam aber sicher den Speicher vollschreibt.
Es könnte an der Signalqualität liegen. Du könntest SNR- und BER-Werte mit denen anderer Sender vergleichen, die nicht das Problem zeigen. Außerdem könntest Du die Frequenzen vergleichen, auf denen gesendet wird. Am aussagekräftigsten sind dabei Vergleiche unter Sendern gleicher Modulatonsart (z.b. 8-PSK). Wenn Sender auf höheren Frequenzen niedrigere SNR-Werte und höhere BER-Werte haben, dann liegt es vermutlich am Signalverlust durch lange oder schlecht geschirmte Kabel. Bei Unicable-Installationen kann es helfen, die Unicable-Frequenz des Receivers bzw. der Antennendose auf einen niedrigeren Wert zu stellen. Häufig hilft es bereits, das Kabel zwischen Dose und Reciever auszutauschen, um Signalverlust zu verringern. Dein Zweitreceiver kann evtl. schlechteres Signal besser kompensieren.
You can use python to calculate the free disk space yourself:
#!/usr/bin/python
from os import statvfs
s = statvfs("/media/hdd")
print s.f_bsize * s.f_bavailErst mal nachträglich frohe Ostern, gutemine!
Aus /proc/progress lesen zu wollen ist sicherlich der falsche Weg, da es den Treiber unnötig verkomplizieren würde. Ab opendreambox 2.0 gibt es nur noch eine Zeile in /etc/init.d/rc, in der nach /proc/progress geschrieben wird. Dort ließe sich auch eine zweite Zeile hinzufügen, die z.B. in eine FIFO schreibt. Oder es ließe sich ganz durch eine FIFO ersetzen, so dass Dein Programm sowohl auf den TV als auch auf das LCD zeichnen würden. Wie verhält sich Dein Programm, wenn die initscripts fertig sind und Enigma2 startet (ab 50%)? Benutzt es den Framebuffer oder den Video-Decoder? Da Enigma2 den Framebuffer exklusiv nutzt, darf gleichzeitig kein weiteres Programm darin schreiben.
obi, genügt das, oder brauchst du noch mehr infos?
Unter http://dreamboxupdate.com/open…/1.5/dm8000/experimental/ findest Du alle Treiberversionen aus OE 1.5. Inklusive der von Dir genannten sind die zetilich darauf folgenden:
dreambox-dvb-modules_2.6.12-5.1-brcmstb-dm8000-20100401-r0_dm8000.ipk
dreambox-dvb-modules_2.6.12-5.1-brcmstb-dm8000-20100414-r1_dm8000.ipk
dreambox-dvb-modules_2.6.12-5.1-brcmstb-dm8000-20100528-r0_dm8000.ipk
dreambox-dvb-modules_2.6.12-5.1-brcmstb-dm8000-20100605-r0_dm8000.ipk
dreambox-dvb-modules_2.6.12-5.1-brcmstb-dm8000-20100612-r0_dm8000.ipk
dreambox-dvb-modules_2.6.12-5.1-brcmstb-dm8000-20100623-r0_dm8000.ipk
Interessant wäre nun, bei welcher Version die Änderung zuerst auftrat. So lässt sich der Zeitraum eingrenzen.
Installieren kannst Du die Treiber z.B. mit folgendem Befehl:
ipkg install http://dreamboxupdate.com/opendreambox/1.5/dm8000/experimental/dreambox-dvb-modules_2.6.12-5.1-brcmstb-dm8000-20100414-r1_dm8000.ipkNach jeder Treiber-Installation wird ein Reboot nötig, bevor die neuen Treiber wirksam werden.
Vor dem Ausprobieren würde ich eine Sicherung empfehlen. Unter Umständen kann die Installation von Treibern ohne zugehörige Pakete wie Secondstage oder Kernel zu Problemen führen.
Ich will Dir erst mal keine allzu großen Hoffnungen machen, aber wenn Du herausfinden könntest, ab welcher genauen Treiberversion das Bild nicht mehr Deinen Anforderungen entspricht, könnte ich immerhin mal in den Treibern nachsehen, welche Änderungen in dem Zeitraum gemacht wurden, um den Aufwand in etwa abschätzen zu können, Deinen Wunsch zu berücksichtigen.
Welche Treiberversion installiert ist, siehst Du mit
opkg list_installed dreambox-dvb-modules, wenn Du über telnet oder ssh auf der Box angemeldet bist.
SEW 123 F ist wohl billiger und hat eine geringere Dämpfung als SEW 121 F. Von einem einfachen "T-Stück" würde ich abraten, um die LNB-Speisespannung der Box vom Kabel-Hausverstärker fern zu halten.
Danke für die Informationen!
PS: Ist es evtl. technisch Möglich das das Sat und das KabelTv Kabel nicht über den Multiswitch verbindet sondern
nach dem Multiswitch (ausgang) mit eine T-Stück Verbindet um evtl. zu Prüfen ob die Fehlerquelle der Multiswitch sein kann?
Ja, das geht. Ich benutze dafür eine Spaun SEW 121 F, siehe http://www.spaun.de/?lang=de&modul=products&product=871108
Da es mit PiP nicht aufzutreten scheint, liegt ein Problem im Zusammenspiel mit Deiner Festplatte nahe. Du könntest das evtl. bestätigen, indem Du während des PiP-Tests Dateien auf die Festplatte kopierst. Uns würden in dem Fall Hersteller und Modellbezeichnung der Festplatte interessieren, um der Sache auf den Grund gehen zu können.
Passiert das auch mit PiP oder nur bei Aufzeichnungen?
Ich habe auch Sat und Kabel auf derselben Dose (Axing SSD 1-10), habe aber nicht dieses Symptom.
schade nur, dass von Dream tmbinc, ghost nichts dazu geschrieben wird. Aber fremde Patches werden so ungern eingepflegt ... das wissen wir eh und dann beklagt man sich, wenn von der Community nichts zurück kommt ... sehr sehr schade
Ich möchte an dieser Stelle widersprechen: Fremde Patches werden sehr gerne eingepflegt, wenn sie dazu geeignet sind. Leider ist das nicht immer der Fall.
Soweit ich weiß, beklagt sich niemand darüber, dass von der Community nichts zurück käme. Im Gegenteil. Die Community hat sich bisher insgesamt hervorragend engagiert und verdient Lob dafür! Dass von anderen Herstellern meines Wissens nach bislang nichts zurück kam, steht auf einem anderen Blatt. Darum geht es hier sicherlich nicht.
Es ist im Allgemeinen schwierig, die richtigen Worte zu finden, wenn ein Patch ablehnt wird. In der Regel erzeugt das negative Stimmung und nur sehr selten kommt nach einer Kritik ein überarbeiteter Patch, der auf alle Kritikpunkte eingeht. Das verleitet dazu, nicht auf jeden Beitrag zu reagieren, wenn die Kritik zu umfangreich ausfallen würde.
Da Du explizit darum gebeten hast, werde ich exemplarisch einige Punkte aus den Patches auflisten, die es - jeder für sich alleine betrachtet - unmöglich machen, sie zu übernehmen:
Damit ein Patch übernommen wird, muss man lediglich wenige Faustregeln befolgen:
Es ist sicher nicht immer möglich, diese beiden Regeln vollständig zu befolgen. Wenn aber der Wille dazu anhand des Patches und dessen Beschreibung erkennbar ist, steht sicherlich nichts im Weg, die notwendige Unterstützung zu bekommen.
P.S.: Patches für enigma2 sollten an die Mailingliste enigma2-devel@lists.elitedvb.net geschickt werden.
HD-Ready ist ein Begriff, der nur auf Fernseher anwendbar ist: http://de.wikipedia.org/wiki/HD_ready#Anforderungen. HD-taugliche DVB-Empfänger müssen sowohl 720p als auch 1080i unterstützen.
Danke für die Fehlerbeschreibung! Es wäre hilfreich, wenn Du die Modellbezeichnung(en) des per HDMI verbundenen Fernsehers oder AV-Verstärkers nennen könntest.
Hi Rico,
könntest Du bitte Vergleichswerte von z.B. 113 MHz messen?
Your XML file contains faulty data:
- Only bandwidth and constellation need to be specified.
- The first 59 entries are invalid, because they miss a digit, e.g. 47400000 means 47.4 MHz, but should be 474 MHz and so on.
- 60200000 appears twice.
- Channels between 177500000 and 226500000 have 7 MHz spacing, but you set bandwidth to 0, which means 8 MHz.
- All channels but 126400000 (126,4 MHz) are already covered by "Europe, Middle East, Africa: DVB-T Frequencies".
Is there actually a signal on 126,4 MHz or is this a typo?
Can you provide a copy of the NIT instead?
Please run
dvbsnoop -n 16 0x10 > /tmp/nit.logand attach the resulting log file here.