Posts by ABPSoft

Quote

Original von Cleaner83
Muss doch daran liegen das der Stick zu spät gemountet wird. Wenn der Cache auf meiner Hdd liegt klappts. Allerdings hätte ich gedacht das zunächst auch der Stick gemountet wird bevor der EPG wieder eingelesen wird.

Wer mountet den Stick? Wenn Du das von GP3 machen lässt, ist es wirklich zu spät, da E2 den unmittelbar beim Start anspricht, bevor das Plugin sich um den Mount kümmern konnte. Hatte das Problem auch anfangs und habe lange gerätselt, ich dachte das macht automount zeitig genug. Aber der automatische Mount in GP3 hat nix mit autofs zu tun - läuft also definitiv viel zu spät. Seit der Stick direkt in /etc/fstab steht, klappt das alles erwartungsgemäß.

HTH,
Andre.

Quote

Original von sat+kabel

also willst du sagen, ard benutzt zwar die gleichen encoder intern bei allen ard-hd-sendern,

Wieso sollte ich "das sagen wollen"? Das ist eine völlig aus der Luft gegriffene Annahme von Dir. Warst Du dort? Hast Du die Dinger gesehen? Wie viele haben die? Welche Modelle? Revisionen? Mit welchen Firmwareständen? Wer parametrisiert die? Welche Redundanzen haben die? War das Quellmaterial wirklich bitidentisches SDI? Wer stanzt das Senderlogo womit rein?

Den Rest zu kommentieren spar ich mir, da es eh nur Trollköder ist. Wenn Du willst, kannst Du gern weiter glauben, dass ein im Video-ES gar nicht mehr enthaltenes ECC-Sideband dessen Qualität auf magische Weise verbessert. Ist ungefähr so plausibel wie Homöopathie, und das kaufen noch viel mehr Leute. Und die kommen bei der Konfrontation mit Fakten auch mit "Argumenten", sowas wie Logik wäre "skurril und hilflos".

Quote

Original von sat+kabel
nach abzug dieser daten kamen am ende 3-6 megabit/s videodatenrate bei einsf. hd bei diesem "tatort" heraus.

Wenn zwei MPEG4 AVC Elementary Streams mit vergleichbarer Datenrate deutlich unterschiedlich aussehen, dann gibt es genau einen Faktor, der dafür verantwortlich sein kann: Den Encoder. Warum einige Encoder (im selben Profil) bei einer Bitrate X nur Matsch mit Soße produzieren, wo andere noch knackscharfes Material rüberretten, kannst Du ausführlich bei Dark Shikari nachlesen. Hint: Standardisiert ist der Decoder, d.h. es ist definiert was der aus einem vorliegenden ES zu restaurieren hat (und wie ein konformer ES in einem gegebenen Profil aussehen darf). Der Encoder ist in voller Absicht nicht definiert.

Im Übrigen ist "sah besser aus" höchst subjektiv. Audio-Esoteriker behaupten auch immer, ihre sauerstofffreien Platinkabel rauszuhören, machen aber aus irgendwelchen Gründen nie Doppelblindtests

BTW^2, wenn man die ES vergleicht, ist die FEC (oder jeder andere Parameter der Modulation und selbst des Multiplex) längst Geschichte, verrechnet bzw. weggeworfen, Verpackungsmüll. Der ES ist Netto, und das einzige was (via Decoder) am Bildschirm ankommt. Anders gesagt, das einzige was zählt.

Quote

Original von SuPerfrEa|<
Und das "EPG aktualisieren" im BP ist so ziemlich das gleiche, wie das EPG-Refresh was auf dem feed als plugin zum nachinstallieren liegt.

Würde ich jetzt nicht so sagen. GP3 EPG-Refresh macht nichts weiter, als eine handvoll Zap-Timer in die Timerliste zu setzen. Das ist wirklich alles. Das hat Vorteile und ein paar eklige Nachteile. Wenn man eine Box hat, die eh zur Zeit der Timer im Standby ist, dann stört nur, dass sie bei jedem Zap aus dem Standby geholt wird. Aber wehe, man guckt zufällig gerade live TV.

Das extra Plugin von ritzMo zappt selbst und versucht dabei, in vielerlei Hinsicht smart vorzugehen (nur wenn im Standby und keine Aufnahme am Laufen, optimierte Kanäle bei Bouquet-Scan und Kanal-Feed aus Autotimer, konfigurierbares Zeitfenster, Scan ohne Vordergrund-Zap z.B. per Hidden PiP oder Pseudoaufnahme). Leider kollidiert es dadurch auch öfter mal mit Software-Neuerungen seitens DMM. Man sollte da checken, ob es im Zeitfenster wirklich dazu gekommen ist, mal durchzulaufen.

Am Ende machen beide natürlich das selbe (insofern hast Du letztlich recht), und das ist kein EPG-Refresh: Sie zappen irgendwie Sender durch. Den EPG refreshed die Software so oder so von allein. Insofern können sie sich auch nur sehr bedingt gegenseitig beißen. CrossEPG andererseits lädt externe EPG-Daten hinzu und versucht, die mit denen von E2 zu mergen. Hier kann es schon viel eher krachen.

Ansonsten: Wenn plötzlich weniger Tage im EPG sind, dann ist die Ursache - wie hier schon mehrfach gesagt - höchstwahrscheinlich der Sender. Vielleicht auch eine zu kurze Scanzeit (ein kompletter Datenzyklus ist AFAIR in 2min durch), aber dann wäre das unsystematisch mal mehr und mal weniger, nicht global weniger. Es sind Feiertage, da läuft die Technik oft auf Autopilot. Trivialitäten fixt da niemand, wenn der Zuständige erst aus dem Urlaub geholt werden müsste. Sieht man ja gerade bei RTL, die seit Tagen verstümmelte Umlaute raushauen...

Andre.

Hi,

ich habe explizit noch nicht abgestimmt, da die 7020HD CC erst seit wenigen Tagen hier steht. Ich konnte im Normalbetrieb die beschriebenen Probleme bisher nicht beobachten, habe aber auch den Großteil der gemachten Aufnahmen noch nicht angesehen. Etwas ist da aber wohl schon dran, denn als ich letztens mit EPGrefresh rumgespielt hatte (extra Plugin) und mal den EPG-Scan im PiP laufen ließ, kam es bei Umschaltvorgängen im PiP gelegentlich zu Rucklern/Macroblocking im Vordergrundprogramm. Letzteres lief dabei auf Tuner B, der EPG-Scan auf Tuner A. Wirkte irgendwie so, als könne Umschalten von A den dahinter in der Kette hängenden B kurzzeitig des Signals berauben. Aber wie gesagt, bisher nur im PiP-Scan von EPGrefresh beobachtet, das könnte also auch noch andere Ursachen haben. Drauf ist momentan das neueste OoZooN 3.2.1, weil die Gelegenheit gut war, mal andere Images anzutesten.

BTW, einen Hardwareschaden hat meine Kiste hier sehr wohl: Nach wenigen Minuten hatte das OLED einen dauerleuchtenden senkrechten Pixelstreifen. Der taucht schon beim Booten auf und geht nicht mehr weg, solange das Display Strom hat (im Deep Standby ist es endlich wieder dunkel). So'n Mist ;(. Frage mich jetzt, ob man da beim Händler auf Gewährleistung geht oder besser gleich bei DMM ein Support-Ticket aufmacht. Weiß jemand, ob das Display unproblematisch zu tauschen ist? Oder muss ich die ganze Riesenkiste quer durch die Repube schicken?

Andre.

Quote

Original von AeonCor
Noch eine Frage: Was ist der einfachste und Gemini-Kompatibelste Weg, wieder ext2 zu verwenden?

In /etc/fstab das blödsinnige "noauto" in der ansich korrekt generierten UUID-Mount-Zeile wieder in "auto" ändern. Ich habe das als erstes probiert, als das "Einhängen" schief ging (die Zeile wird ja hinzugefügt, nur halt fehlerhaft). Danach noch ein "mount /media/hdd" und seitdem keine Probleme mehr.

HTH,
Andre.

Quote

Original von kashmir

Wenn man den USB Stick in der fstab mountet, wird dieser direkt nach dem Start des Linux Kernels und vor dem Start von enigma gemountet und es gibt keine Probleme.

Argh, wenn man natürlich weiß, dass es GP3 ist was den Anschein erweckt, dass ein USB-Stick automatisch gemountet wird, dann ist das zu spät oder zumindest extrem racy. Ich hatte nicht genau hingeguckt und angenommen, wenn da schon ein autofs läuft, dann wird der wohl auch verantwortlich sein, und der wird in rc3.d gestartet, bevor enigma2 in der inittab an der Reihe ist. Löst sich alles in Wunschdenken auf, wenn man mal /etc/auto.* konsultiert.

Ok, also rein damit in die fstab und

Test 1: Restart über Menü. EPG nachher noch da. Nur zur Sicherheit
Test 2: Restart über BP Update. EPG immer noch da. Cool.

Danke für die Schubse in die richtige Richtung,
Andre.

Hi,

Quote

Original von SadButTrue
nach neustarts steht das normale epg immer zur verfügung wird für jeden neustart gesichert...

Das wird hier zwar regelmäßig kolportiert, die Rate, mit der Leute trotzdem danach fragen, ist aber entschieden zu hoch für etwas, das "immer" funktioniert. Bei mir funktioniert es jedenfalls nicht. Es gab erst die letzten Tage wieder ein paar Updates (enigma2 und Drumrum), der dort nach der Installation ausgelöste Neustart ist ja wohl ein Korrekter und kein Crash. Trotzdem hinterher kein EPG. Vor einiger Zeit sah es mal so aus, als wäre da irgendwo ein "/" zuwenig im Code (ich finde den Thread jetzt nicht, aber es schien zu helfen, das epgCacheDir in gemini_plugin.conf mit einem "/" zu postfixen), aber das hat es auch nicht dauerhaft gebracht.

Darf epgCacheDir überhaupt auf externen Medien liegen? Wie zeitig beim Booten wird das versucht zu laden? Nicht dass da irgendeine race condition dafür sorgt, dass das mal geht und mal nicht, je nachdem ob die Medien schon gemountet sind. Bei mir zeigte es ursprünglich auf /media/hdd und inzwischen auf /media/USB1/cache/ - vielleicht setz ich das mal 'ne Weile auf den Flash...

Irgendwas ist da jedenfalls faul, zumindest bei der 800er.

Andre.

Quote

Original von farshad6730
crossepg@googlecode.com to me:

Ok... problem found

To get it working i did this:
- in gemini setup panel i changed the epg dir to /media/usb
- saved and reboot
- edited the file /etc/enigma2/gemini_plugin.conf
- changed the row "str=epgCacheDir=/media/usb" in "str=epgCacheDir=/media/usb/" (note the last /)
- rebooted again

Display More

Thanks for tracking down this one! For months I wondered why some people claimed EPG data would be saved and restored over clean reboots, while others (me included) never saw that working. That trailing slash on the epgCacheDir seems in fact crucial for it to work with current code. After adding it, I've got EPG preservation over reboots all of a sudden.

Quote

I think this need to be reported to GP3 developers

Second that.

Thanks,
Andre.

Quote

Original von niemand0815
nochmal meine frage von vorher:
hat man eigentlich irgendeinen nachteil wenn man die zeit auf ntp eingestellt lässt?

Folgende:

a) AFAIK holt das Plugin die Zeit einmalig beim Booten. Wenn man die Kiste also fast nie neu bootet (bei der 8000er unwahrscheinlich, bei der 800 aber an der Tagesordnung), kann die Uhr langsam wegdriften. Falls das ntpdate inzwischen in einem Cron-Job steht, leiste ich Abbitte.

b) Wenn der NTP-Server mal beim booten nicht erreichbar ist, geht die Uhr anschließend wahrscheinlich falsch (1.1.2000).

c) Wenn man neu flashed, Settings importiert und nicht sofort das Plugin wieder installiert (oder es mal wieder 'ne Weile vom Feed verschwindet, so dass man es nicht installieren kann), dann geht die Uhr falsch. Das Plugin setzt ja transpondertime auf false und das schleppt sich beim Settings-Import weiter.

IMO sind das alles keine ernsten Probleme, außer vielleicht (a) bei Leuten mit einer DB, die selten rebooted wird. Ehrlich gesagt wäre mir ein korrekt eingebundener ntpd aber sehr viel lieber. Leider geht das gar nicht, weil der Kernel (zumindest auf meiner 800) ein völlig zerschrotetes NTP-Handling hat. Sobald man ntpd benutzt, um die Uhr zu disziplinieren, rennt die in irrer Geschwindigkeit davon (der Offset wächst schneller als exponentiell) - ich habe den Versuch beendet, als ich nach ein paar Minuten im Jahr 2016 war...

HTH,
Andre.

Quote

Original von gutemine
Ihr wisst aber schon das jffs2 ein hochkomprimiertes Filesystem ist und wenn Ihr so viel auf einmal updated das nachher aussieht wie ein Schweizer Käse und auch eintsprechend performt ?

Ich dachte mir sowas, habe das aber bisher verdrängt[1]. Bisher funktioniert das hinreichend gut und die zunehmende Fragmentierung macht sich noch nicht in exzessiven Zugriffszeiten bemerkbar[2] - die sind bei Flash wenigstens deterministisch. Auch wenn das hier oller linear flash ist und keine SSD

Aber Danke für den Hinweis, das ist doch mal ein echter technischer Grund, gelegentlich neu zu flashen, und sei es nur ein Backup.

Quote

Macht mal eine Sicherung und restort die und schaut euch nachher und vorher den Freiplatz im Flash an. Das ist eben nicht irgend eine Linux distribition die man hochzieht auf irgend einer Harddisk die man jederzeit und leicht restoren kann.

Sieht nur fast so aus. Der Teufel steckt im Detail.

BTW, gibt's Tools zum Beurteilen eines JFFS2? Sowas wie dumpe2fs? Wüsste gern mal, wie zersiebt das hier schon ist. Ähm, mtd-utils hat dumpjffs2 aka jffs2dump. Mal gucken, ob das in meinem OpenEmbedded baut. Nö, natürlich ni - irgendwas mit ubifs inkonsistent. Nicht mehr heute, heute ist ja schon morgen

Thanks,
Andre.

[1] Ich hatte erst befürchtet, dass es ein reines Zuwachs-FS wäre, das also noch nicht mal den Platz gelöschter Files freigibt. Als es dann nach dem Höchststand wieder deutlich freier wurde im /-Filesystem war die Sache für mich erledigt. IIRC war das mit JFFS (vor 2) noch hässlicher. Aber unfragmentiert neu packen ist natürlich besser.

[2] Sofern man das bei der 800 überhaupt merkt. Die reagiert wohl immer zäh...

Quote

Original von knopers1
@ ABPSoft

Du scheinst wohl hier ein wenig mehr Ahnung haben als mancher.... BEE-Tester...

Linux ist (zum Teil) mein Alltagsjob, daher habe ich damit keine Probleme - ich habe eine dreistellige Anzahl von Debian-Upgrades durch (seit 1995) und trau mir zu, auch arge Ruinen wieder zusammenzuflicken. Das heißt nicht, dass ich im Detail von der Dreambox Ahnung hätte. Mir ist völlig klar, dass ich das auf eigene Gefahr mache, dass ich widrigenfalls neu flashen muss - und wenn es richtig kracht, das serielle Kabel aus dem Schrank holen darf, um den 2nd neu zu flashen. Aber ich mag in-place upgrades und hasse Neuinstallationen. Daher meine bisher erfolgreichen Versuche, iCVS einfach upzugraden statt neu zu flashen. Das neue iCVS-Image (und ein FlashBackup vom alten, plus sichergestellte Dateien und ein GP3Settings-Backup) liegen natürlich extern vor, bevor ich zuschlage.

Quote

Kannst Du mir mal sagen wie Du dein Update ohne neuflashen gemacht hast?
Würde es wenigsten versuchen, bevor ich mir das CVS (ohne ständiges neuflashen) draufspiele...

Wie maxl auch schon mehrfach andeutete: In /etc/opkg alle Feed Configs manuell anpassen auf das neue Feed-Datum (22032011 wurde ja inzwischen "offiziell bestätigt"). Viel Platz im Flash frei haben. Dann "opkg update". Wenn das gut läuft, tief durchatmen und "opkg upgrade". Dabei darauf achten, dass alles Wichtige sauber abläuft. Hier insbesondere der 2ndstage upgrade:

Configuring dreambox-secondstage
*** raw flash write tool. Don't have bad sectors or it won't work.
*** uncompressing... ok!
*** FLASH_GEOM: 04000000 00004000 00000200 00000010 00000005
*** CRC check ignored!
*** stage 0: ..00000000 | 00000008..00000014 (12 bytes)
*** stage 1: ..00040000 | 00000018..000243a8 (148368 bytes)
*** stage 2: ..00000000 | 000243ac..000243ac (0 bytes)
*** stage 3: ..00000000 | 000243b0..000243b0 (0 bytes)
*** bad block list: none
*** writing.. ok!
*** done!

Danach ein beherztes "reboot" und Daumen drücken. Wenn *irgendwas* schiefgeht, dann musst Du das aber selber flicken können, und gerade bei diesem Upgrade könnte das eklig werden, wenn es den 2ndstage zerlegt. Also serielles Kabel, PC und Windows für DreamUp zumindest zur Hand haben.

Die "Anleitung" ist absichtlich so knapp. Entweder man weiß was gemeint ist und kann blind mit SSH und vi(1) auf der Dream rumgurken, oder man weiß, dass man es besser lässt. Genau deswegen wird Neuflashen empfohlen - das ist ein Reset auf ein known package, keine potenzielle permutative Explosion von Dingen, die alle schiefgehen können - und Murphy sagt, das sind alle

Mir ist völlig klar, dass das niemand supporten will - ich auch nicht

Du musst wissen was Du tust.

HTH,
Andre.

Quote

Original von netman
Bis jetzt haben alle Images auf dem CVS 3.0.* aufgesetzt. Seit dem letzten Update
wurde auf CVS 3.1.* gewechselt mit einer Menge Änderungen die so gross sind, daß
ein Update nicht funktionieren würde. Die Boxen haben schlichtweg zu wenig Flashspeicher.
Deshalb ist ein Neuflashen unumgänglich

Meine 800 hatte vorher 17.1MB freien Flash, während des "opkg upgrade" habe ich ein bissel drauf geachtet, das dabei gesehene all time low war

Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/root                61440     46116     15324  75% /

Das war völlig entspannt

Quote

Das ganze war ein Major Release

Mag sein, aber der Upgrade auf 01022011 (von der vom 23.12.2010) hat mehr gerummst. Da war ich IIRC bis auf 11MB runter. Damals kamen jede Menge gstreamer-Updates mit, dagegen war das hier Kindergeburtstag. Eigentlich nur Kernel+Module und E2, plus etwas Drumrum (incl. Secondstage). Und E2 kracht auch nur so wegen der l10n. Wenn die mal in einzelne Pakete ausgegliedert würden (aber das müsste wohl DMM machen, ihr wollt sicher kaum die Paketstruktur inkompatibel ändern)...

HTH,
Andre.

Quote

Original von netman
Hier ist aber aktueller Stand mit updates 26.03.2011. Fehlen wohl doch ein paar
Updates

Beziehst Du dich auf das 22032011? Das ist das Feed Tag, das ich manuell ermittelt habe. War das falsch? Ich war zu faul, das NFI auszupacken um nachzusehen, und sogar zu faul für einen wget-ad-hoc-Script (der 3. Versuch war ja schon erfolgreich)...

Quote

Es kommt auf dein Image an. Wenn ich deine Signatur sehe, dann sehe ich iCVS, das
kann also nicht upgedatet worden sein (ausser du hättest irgendwelche Feeds manuell
hinzugefügt, von denen ich dringend abrate). Also von welchem Image sprechen wir?

Von iCVS (NFI 20101223, bereits genau so hochgezogen auf 01022011) und allen relevanten Feeds umgestellt auf 22032011. Ist ja keine Raketenwissenschaft

root@dm800:~# cat /etc/version ; opkg list-installed | egrep 'seconds|kernel-im'
201012232120
dreambox-secondstage - 82-r0
kernel-image - 2.6.18-r11.0

Wieso rätst Du dringend ab? Außer, dass es nicht getestet ist. Das meinte ich: Wenn ihr böse Showstopper vorher wisst, wäre es cool die zu benennen (statt eines opaquen "geht nicht").

Thanks,
Andre.

Quote

Original von netman
Psst: Ich verrate dir was, alle müssen neu flashen

Welchen exakten technischen Grund hat das?

Ich frage nur, weil hier gerade ein manueller Upgrade auf 22032011 anstandslos durchgelaufen ist.

Secondstage wurde hochgezogen (da ist es wohl besser, genau auf die Ausgaben zu achten), Kernel und Driver sind neu, Aufnehmen & Wiedergeben geht (letzteres war wohl die Crux bei Secondstage/Driver/E2-Mischmasch).

Mir ist klar, dass ihr das nicht supporten wollt - ich sehe aber schon noch einen Unterschied zwischen "das geht zwar, aber wenn Du nicht selber weißt, wie, dann flashst Du besser neu" und "das geht nicht, weil dann XYZ passiert/nicht passiert". Insofern wäre ein klarer Warnhinweis angebracht, wenn es mal keinesfalls upzugraden geht - mit 'ner nachvollziehbaren Begründung. Man will die Kiste ja nicht bricken

Thanks,
Andre.

Hi,

ich bemerke gerade eine zunehmende Zombie-Horde:

root@dm800:~# ps | grep Z | grep -v grep | wc -l
134

Nach etwas Rumgesuche wird klar:

Die Zombies werden mehr, sobald die Infobar aktiv ist. Sekündlich. Mit ein paar flott nacheinander abgesetzten ps und etwas gegurke in /proc lässt sich zeigen, dass es Child Processes von /usr/bin/gdaemon sind, die von der HDD Temp Anzeige getriggert werden:

3552 root      2532 S    sh -c smartctl -d ata -A /dev/sda 
 3553 root      3920 R    smartctl -d ata -A /dev/sda

sieht anschließend so aus

3552 root         0 Z    [sh]

und bald sind es wieder ein paar mehr.

Sieht also aus, als würde gdaemon seine Children nicht ordentlich reapen.

root@dm800:~# opkg search /usr/bin/gdaemon 
geminitools - 0.23-r0

Mir scheint, dass das neu ist, gestern habe ich das Upgrade auf 0.24-r10 eingespielt. Ich bin aber auch vorhin mal der Empfehlung gefolgt, diverse Caches und Picons auf einen USB-Stick auszulagern, damit ist also noch was anderes geändert worden. Und wenn es um HDD Temp geht, mag die Anwesenheit eines /dev/sdb schon irgendwas beeinflussen können - wenn auch eigentlich nicht das child reaping in gdaemon.

Sieht das noch jemand?

Image ist das iCVS vom Februar.

BTW, hatte nach dem Upgrade gestern beim Reboot nach dem allerersten Bootlogo kein Bild mehr, die Kiste war fast tot aber nicht ganz (Spinner kam noch, Menü ging noch). Nach einem Power Off und 5min Kurzurlaub ging dann aber erstmal wieder alles.

TIA,
Andre.

Quote

Original von Binsche

Ich habe keinen Vergleich aufgestellt,

Huch, das war mehr auf mich gemünzt. Und ich war verwirrt

Quote

sondern versucht deine Frage nach der Signalstärke (RF-Power) damit zu beantworten. Wir in der Antennen/Empfangstechnik sprechen eben nicht von dBm, sondern von den etablierten dBµV.

Ja, dass das in diesem Teil der HF-Welt der etablierte Bezugspegel ist, ist mir inzwischen auch klar. In dem Teil, mit dem ich zu tun habe (WLAN), denkt halt jeder (Hersteller von APs und WLNICs, Mess- und Surveysoftware, mein Spectrum Analyzer etc) in dBm

Quote

Abgesehen davon kann man dBm nach dBµV herrlich umrechnen (und umgekehrt), in Abhängigkeit von der Eingangsimpedanz
http://www.itwissen.info/defin…oV-decibel-microvolt.html
Das nochmal zum Pegel auf der Leitung bzw zur Signalstärke...

Thanks, ich wollte ja Aufklärung

Damit ist mir klar, wo mein Thinko lag: natürlich sind die dB aus Feldgrößenverhältnissen mit denen aus Leistungsgrößenverhältnissen direkt vergleichbar, genau deswegen werden Erstere ja anders gebildet (quadrieren der Feldgrößen bzw. 20log10 statt 10log10). Damit ist es auch völlig Wurst, ob wir eine SNR aus dBm oder dBµV ermitteln. Kommt davon, wenn man jahrelang nur noch mit Leistungsgrößen operiert und in einer dunklen Ecke der Erinnerung rumspukt, dass bei Feldgrößen irgendwas anders war mit 20-rule und so.

Quote

Für 4096QAM liegt (nach meinem aktuellen Wissensstand) noch keinerlei Wert fest, wobei man davon ausgehen darf, dass dieser oberhalb von 40dB MER liegen würde

Die 35dB kamen mir in einem c't-Artikel zu DVB-C2 unter, der wirkte gut recherchiert.

Thanks,
Andre.

Quote

Original von ibrahim
du kannst gerne in deinem alten icvs probieren, in den opkg config dateien die feed url der icvs spezifischen feeds von 23122010 auf 01022011 zu ändern, und das update laufen zu lassen.
wenn du aber größere probleme dadurch hast, auf jedenfall neu flashen!

Ehe ich neu flashe, dachte ich, probierste das mal. Mit 17MB frei also die Feeds angepasst, opkg update && opkg upgrade. Das ging 99% völlig glatt, nur das CrossEPG-Paket hatte einen MD5sum-Fehler. Da ich das eh loswerden wollte, half ein beherztes opkg remove. Danach noch ein wenig Unsicherheit, weil unter /boot jetzt ein Symlink ins Leere zeigt. Aber autoexec.bat verweist auf vmlinux.gz, und das ist da. Also reboot. Und siehe da: Box kommt mit neuem Kernel wieder hoch und alles ist easy & roger - und noch 15MB sind frei.

Ich würde das als Erfolg deklarieren, aber ich mach auch alle Nase lang Upgrades auf diversen Debian-Kisten und hatte einen Exit Plan (neues Image flashen). Ich glaube mal, das Hauptproblem hier ist Testing von Rolling Upgrades auf Verträglichkeit mit allen möglichen vergurkten Nutzerkisten (wenig Flash frei, Pakete von sonstwo drauf) sowie Support im Fehlerfall. Wer sich selbst zu helfen weiß, kann das aber versuchen und kriegt es sehr wahrscheinlich auch hin. Und wenn es doch mal schiefgeht, flashen geht immer noch. Im Release Announcement darf also gern auch der Feed Tag stehen.

Ich frage mich bloß noch, was ich in /etc/version reinschreib

HTH,
Andre.

Re kodo,

Quote

Original von kodo
Das ist der Ablesewert aus dem WebIf meiner 7025. Und ja, da steht dB

Ich glaub Dir, dass das da steht. Ich glaub bloß nicht, dass es irgendwie mit der Realität korreliert

Ich hab mal im WebIf meiner 800C geguckt, da steht gerade 41.73dB. Das ist identisch mit der Anzeige in der Infobar (danke übrigens für die sechs konfigurierbaren Sensorfelder an iCVS, GP3 und JD, das ist richtig cool). Ich würde jetzt vermuten, dass die 7025 da vielleicht irgendwas verwurschtelt. Was steht denn bei SNR %, AGC und BER?

Wie Rene schon dargelegt hat, sind Werte jenseits von 50dB SNR im Kabel eigentlich physikalisch fast unmöglich. Das BK ist ein riesiges Antennensystem, das großflächig jede Menge "Dreck frisst", den dann mit Verstärkern auch noch im Pegel anhebt und deswegen mit Müh und Not auf SNRs über 40dB getrimmt werden muss. Es rauscht analog z.B. auch signifikant mehr als ein gutes terrestrisches Signal (hat mich damals sehr gewundert, als es das noch gab - eine Grabberkarte offenbarte das ganze Grauen erst so richtig, und wenn ich heute mal aus Versehen am TV auf analog schalte könnte ich heulen).

Ok, wenn man jetzt mit FTTH versorgt würde und nur ein Gerät mit wenigen Metern höchstwertigem Kabel direkt hinter dem Glas-Koax-Umsetzer angeschlossen hätte, alle anderen Ports sauber terminiert wären etc pp - oder ein eigener Kabelkopf in einer kleinen feinen (G)GAA - nee, nicht wirklich 78dB. Du hast nicht zufällig noch 'nen anderen Receiver zwecks Vergleich?

Nix für ungut,
ein Skeptiker.

Ahmd,

Quote

Original von Binsche
Ich gehe mal davon aus, der kodo meinte ein SNR von 78%

Ich glaube da eher an einen Anzeigefehler.

Quote

Im Übrigen kommt es bei DVB-C auf die verwendete QAM an. QAM64 kommt mit einem niedrigeren SNR aus. QAM256 ist da etwas anspruchsvoller und braucht ein paar dB SNR mehr, um die gleiche BER zu erzielen (Abhängig vom KNB, wie er einspeist)

Yep, so isses. AFAIK braucht man für DVB-C mit QAM256 (was wir so momentan meistens verpasst bekommen) mindestens 30dB SNR, um BER von praktisch 0 zu erreichen. Deckt sich perfekt mit meinen Beobachtungen, darunter geht die BER stetig in die Höhe, bis die FEC dann irgendwann versagt.

Mit DVB-C2 und QAM4096 sind dann schon 35dB Pflicht. Ist aber noch Zukunftsmusik.

Quote

Die Norm EN 50083-7 fordert einen Pegel an der TAD bei DVB-C und QAM64 zwischen 47-67dBµV, welchen man nur mit einem (digitalen) Messgerät ermitteln kann

Gefährlich wird es, wenn wir ein- und zweidimensionale dB vergleichen. Ich gehe bei solchen Angaben im HF-Umfeld eigentlich davon aus, dass man sich auf Leistungsflussdichten bezieht, also zweidimensionale Größen. Damit gilt dann 10dB = eine Größenordnung und 78dB SNR klingen sehr unwahrscheinlich. Aber wenn im Kabel-Umfeld oft mit der reinen elektrischen Feldstärke operiert wird, ist das natürlich eine eindimensionale Größe (geht als ein Faktor in die Leistung ein) und damit 20dB = eine Größenordnung. Kläre mich mal jemand auf, was wir hier anzeigen. Rein gefühlt kommt man hier bei 30dB SNR mit QAM256 (ohne OFDM) auf ca. 50Mbps, das kann eigentlich nur auf 'ner Leistungsflussdichte (also dBm) beruhen, nicht auf dBµV...

Quote

Nein

Hilf mir mal: Steht AGC für automatic gain control? Dann sollte sie zumindest ein Hinweis auf den Pegel sein. Ich kann das hier ganz gut nachvollziehen, ich sehe AGCs von 39% bis 48% und die Multiplexe mit dem schlechtesten Pegel (die beim Ausfall letztens komplett weg waren) haben die höheren AGC-Werte. Das ist natürlich nur qualitativ, Zahlen hat man da noch lange nicht (es sei denn, ein Entwickler sagt uns mal, was die AGC da nach welcher Formel auswertet, um zu % zu kommen - und % von was, wie ich mich gerade auch bei SNRs immer frage).

Ansonsten: Wer misst, misst Mist

Thanks,
Andre.