Beiträge von hivdr

Zitat von Jarod

Ich hab da ne Vermutung, bin mir aber nicht sicher. Unter Umständen hat die Karte ein Problem mit dem Stromsparmechanismus der CPU.
Installier mal cpufreq, falls nicht schon getan und probier mal aus, was passiert, wenn Du die CPU immer mit vollem Takt laufen lässt (perfomance).
Ich hab Dir hier mal 3 Zeilen zusammen geschrieben.

1. gibt Dir den aktuellen Wert aus
2. stellt powersaving aus
3. schaltet powersaving ein

Code

cpufreq-info |grep current
for i in $(awk -F: '/processor/{printf ("%d ",$2)}' /proc/cpuinfo); do  cpufreq-set -c $i -g performance; done
for i in $(awk -F: '/processor/{printf ("%d ",$2)}' /proc/cpuinfo); do  cpufreq-set -c $i -g ondemand; done

Alles anzeigen

Danke für die Mühe, aber ich kanns wie gesagt nicht mehr testen, die Kiste ist jetzt anderweitig im Produktivbetrieb.
Vielleicht versuche ich übernächstes WoE mein Glück dann richtig mit einer für den VDR gedachten HW, und da peile ich schon wieder H67 an.

Wäre natürlich schön, wenn es bis dahin jemand anderer (erfolgreich) testen könnte. Generell ist powersaving heute ja bei jedem modernen System aktiv. Könnte also eigentlich jeder mit Klötzchen mal testen. Auch steato (liest Du hier auch mit?) aus dem Thread "TT S2-6400 und H67 ITX Mainboards -TT wird nicht erkannt - gelöst"
hat ja zB ein H67-Board und auch mal Artefakte.
Natürlich wäre es auch nicht gut, das Runtertakten abschalten zu müssen - dürfte sich recht negativ auf den Stromverbrauch auswirken.

Also jedenfalls muss man jetzt doch festhalten, dass zahlreiche Leute solche Probleme haben, in unterschiedlicher Schwere, und also die Karte noch weit weg ist von einer Eignung für einen produktiven VDR. Denn solange auch nur die geringste Gefahr besteht, dass eine Aufnahme nach dem Aufwachen verpixelt ist, ist das absolut indiskutabel, das dürften die meisten hier ja wohl genauso sehen. Scheinbar kann man es mit der richtigen HW-Kombi (und SW) und etwas Glück hinbekommen, dass es stabil ist, aber das kanns ja auf Dauer nicht sein.

Ich habe mein Board mal der Wiki-Seite hinzugefügt:
http://www.vdr-wiki.de/wiki/index.php/TechnoTrend_S2-6400_-_Mainboard_Kompatibilitätsliste

..und dort auch noch eine Problem-Beschreibungs-Spalte eingefügt - wär wohl gut wenn alle statt hier zu posten direkt dort eintragen..

Dann hoffe ich wie gesagt auf Fortschritte beim Treiber, Danke für Eure Bemühungen!

Ah, da ist ja der Thread mit dem H67-Board. Also gibt es doch jemanden, der die 6400 auf so einem Board einsetzt.

steato
Keine Probleme mit dem Gigabyte-Board, keine Klötzchen? Dann wars vielleicht nur speziell mein MSI-Board (H67MA)..

Im "grossen" Thread hatte ich grade was zu meinem Stromverbrauch gepostet, ich sag mal mit einer Platte (3.5") dürfte der Verbrauch im normalen VDR-Betrieb bei etwa 40 Watt liegen. (Nachtrag: ist ein mATX Board mit normalem ATX Netzteil 380W - bei einer Kiste für VDR wird man ggf. noch was kleineres haben)

Von wegen BIOS, ich hab da jetzt keine Zahlen, und war vielleicht bisher auch nicht grade verwöhnt in Sachen Bootzeit, aber gefühlt ist das schon sehr sehr (sehr) flott. Wobei Ubuntu 11.04 per legacy BIOS MBR arbeitet (grub-pc, nicht grub-efi). Ich habe auch keine efi-Partition angelegt, damit kenne ich mich kaum aus - hatte nur auf einem anderen Rechner schon jede Menge Probleme damit, weil der Natty-Installer eine efi-Partition vermutet hat (war was von Win7), grub-efi verwendet hat, und so war kein Booten möglich. Erst nach manuellem Wechsel von grub-efi zu grub-pc hat er sich wieder in den MBR installiert. Und auch mit diesem Rechner war der Installer beim grub-Installieren gescheitert (Ursache unbekannt) und ich musste es manuell nachholen. Insofern ist EFI noch etwas mit Vorsicht zu geniessen, jedenfalls mit dem Ubuntu-Installer..

(Uff, bin ich echt der einzige, den die Ironie von andreash - erster Post auf dieser Seite - förmlich anspringt?)

So, dann sind es also doch mehr Leute mit Klötzchen-Problem, dann muss ich wohl die "warum immer ich"-Jammerei zurücknehmen. Zuletzt wars da ja eher ruhig und es gab eher Erfolgsmeldungen zu hören - wenn auch mittlerweile zT schon wieder revidiert.
Mein Fall schien trotzdem anders zu sein, da ja absolut reproduzierbar und unabhängig von irgendwelchen cold/warm-boots oder vdr-restarts, dafür mit Abhängigkeit zu CPU-Last.

traxanos - unter den 11 MB ist dann wohl keines mit SandyBridge Technik?
Zu neu? Zu teuer für einen VDR? Ich habe eigentlich genug von den extra-lahmen Atoms. Der Server mit i3 hatte mit Karte und zwei Platten (braucht ein VDR ja nicht) max. ca 45 Watt unter Last. Damit wär ich zufrieden.

Ich hoffe sehr dass sich da noch was tut und man auf der Plattform mit der 6400 was anfangen kann.

sewn4
Bei mir waren die Dateinamen (gestern später Nachmittag) bereits OK, ich habe definitiv die alten Dateien in /lib/firmware überschrieben. Und wie gesagt, hat ja auch ohne die zugehörige Änderung im Treiber dann erst mal gar nichts mehr funktioniert.

powarman
Die maxcpus=2 hatte ich schon probiert (stand ja auch in einem Beitrag weiter oben schon), mit =1 habe ich es jetzt auch noch mal probiert (in der Tat zeigt cpuinfo oder hwinfo nur 1 CPU): hilft alles nix! Übelste Klötzchen. Quer durch sämtliche HD, auch FTA, je höhere Bitrate grade desto schlimmer.

Dagegen hilft es tatsächlich nachvollziehbar, sobald man den Rechner unter Last setzt. Ich starte nur einen mencoder, und der lastet nur einen Kern aus (nun wieder mit 4 unterwegs)! Trotzdem hilft es: keinerlei Störungen solange das Encoding läuft.

Diesmal übrigens wieder mit 2 Tunern - und dabei funktioniert nur
die #1 mit den kommerz. HD, obwohl ich dieses andere dvbhddevice
verwende - wobei gestern mit nur 1 Tuner ist es ja die #0 die damit
funktioniert hat - auch sehr seltsam!

Also, es scheint wirklich ein Problem mit dem H67-Chipsatz und dem Core i3-2120 zu geben - jedenfalls mit dem aktuellen Ubuntu (11.04 64bit).
Daher nochmal die Frage: sonst hat keiner der 6400-Tester hier diese Plattform? Konkret ist es das MB MSI H67MA.
Ich glaube jemand hat mal ein Gigabyte Mini-ITX Board mit H67 erwähnt.

Als würde der PCIe-Bus gestört, wenn sich der Rechner i.w. langweilt..

Die Karte muss jetzt raus, weitere Tests kann ich nicht mehr machen.
In ca zwei Wochen versuche ich dann vielleicht wirklich einen neuen VDR damit zu bauen. Fragt sich nur, ob mit SandyBridge. Und ob ich dann wieder Pech habe. Warum immer ich..

Das Ding würde mir vorschweben: http://www.heise.de/preisvergleich/a631839.html
Hat sogar zwei PCIe, allerdings noch nicht lieferbar

Ich habs jetzt auch nochmal probiert. Erst mal die neue Firmware. Damit waren sämtliche FTA HD-Sender schwarz. Es scheint also unbedingt auch der neue Treiber dazuzugehören. Direkt aus dem powarman-Repo ist der ja immer noch nicht übersetzbar unter 2.6.38, aber mit der Vorgehensweise aus dem UFO-Thread (offenbar wird da ja, wenn man es "frisch" macht, der aktuelle Stand von powarman geholt und so eingebunden, dass es übersetzbar ist) hat es geklappt.

Leider immer noch massive Klötzchen, jetzt sogar auf den FTA-Sendern und zT sogar leicht bei SD.
Also habe ich mal femon installiert. Und ich liege bei ca 64% Strength. Also im "gelben" Bereich. Mit der gleichen Leitung am anderen VDR zeigt femon 80% (TBS, mit der TT 3600 hat femon keine Anzeige, aber auch die hat keinerlei Störungen).

Das könnte wohl schon gut ein Grund für die Klötzchen sein? Nur an meiner Leitung kann ich nix ändern, und warum hat die beim einen VDR 80% und hier nur 64%?
Schaut fast aus als wären die Tuner extrem unempfindlich, empfangsschwach. Hat hier allerdings bisher noch niemand erwähnt?
Dann wiederum kann man die Anzeige verschiedener Karten wohl nicht direkt vergleichen, glaub ich mal gehört zu haben.

Und grade habe ich nun mit nur einem Tuner (-D0, mit dem hier verlinkten alternativen dvbhddevice klappts nun auch bös mit nur einem) einen absolut störungsfreien Betrieb (gleiche schwache Werte in femon). Dann plötzlich wieder Störungen - zufällig war gerade eine Kopieraktion fertig geworden. Und tatsächlich: sobald ich wieder IO-Last erzeuge (Kopieren groesserer Datenmengen auf der HD), keine Störungen. CPU-Last ist dabei minimal: auch beim Kopieren sind häufig 3 der 4 Kerne ganz runtergetaktet (1600 statt 3300 max. beim i3-2120). Andererseits scheint dann doch auch hohe CPU-Last zu helfen: werfe ich einen mencoder an, auch wenn ich nach /dev/null schreibe und er aus dem Cache liest, keine Störungen.

Was ist das nun wieder? Sonst noch jemand hier mit SandyBridge unterwegs?

Die Karte muss nun eh wieder raus aus der Kiste, aber den neuen VDR wollte ich eigentlich schon auch auf SandyBridge-Basis bauen, ist einfach im Moment die bei weitem beste Plattform, sparsam und flott.

Also - hat es mit dem CPU-Runtertakten zu tun? Oder was mit Interrupts?
Hier noch die lspci-Ausgabe, falls es einem Experten was sagt: http://pastebin.com/cdhZ7jQ0

Irgendwas, was man auf die Schnelle noch testen könnte, bevor die Kiste ihrer eigentlichen Bestimmung zugeführt wird?
Kann man irgendwie den CPU-Takt hochhalten? (dann ist es mit der Sparsamkeit halt vorbei?)
Oder den Interrupt wechseln. Das mit MSI sagt mir auch wenig, wie aktiviert man das - aber scheint ja auch nicht zu klappen (Banzai).

Warum muss das immer so kompliziert sein..
Good night and good luck..

Also die Kiste ist zwar noch kein Jahr alt, aber ich werde dann (Ende nächster Woche) auf jeden Fall auch mal in ein Live-Ubuntu reinbooten und sehen was passiert.. Gebe dann Bescheid.

((OT: ich sagte mir macht Putzen keinen Spass, nicht dass ich nicht putze. So zweimal im Jahr.. ;))

Kühlung ist gut, liegt ein grosser Lüfter auf allem.
Log-Auszüge: schon klar, nur leider wird das wie gesagt dauern.. war gestern einfach schon zu spät.

Ich war auch erstaunt, dass nach dem dist-upgrade noch was als "zurückgehalten" angezeigt wurde. Ist aber so. Ein yavdr-essentials, das laut Liste installierter Pakete vorher sowas wie 0.2xxxx war und danach nun 0.3xxxx, nach explizitem apt-get install.
Nein, ich habe nie irgendwelche testing/unstable Quellen aktiviert. Lediglich mal eine aus der ich was grauzoniges probiert hatte, wenn auch ohne Erfolg, ist aber schon lange her, und deinstalliert - aber die Quelle ist wohl noch in den apt-sources drin. Aber ist wohl unwahrscheinlich dass von dort ein yavdr-essentials kommt. (definitiv verifizieren geht leider wie gesagt nicht so bald)

Putzfrau? Um Himmels Willen nein, weder bin ich Krösus noch würde ich das Eindringen in meine Privatsphäre haben wollen (aber das ist wohl Geschmackssache, Putzen macht mir auch keinen Spass..) Also der steht da ganz unbehelligt und wohlbehütet in seinem Fach!

Gegen die HW-Theorie spricht halt, dass zB während des dist-upgrade alles glatt lief, da wird ja auch langwierig kompiliert (irgendwas dkms), sowas würde doch auch gerne abbrechen, wenn was Gröberes bei der HW nicht mehr stimmt. Aber klar, memcheck werde ich dann schon mal anwerfen.

docadams

Danke, aber die Firmware-Files hatte ich schon entsprechend umbenannt, der Fehler "not found" ist ja relativ klar. Die werden dann also gefunden, aber der Treiber lädt trotzdem nicht richtig, und lsusb hängt.

Die Sache mit "update-initramfs -u -k all" dürfte sich ja wenn dann darauf beziehen, wenn man mit angestecktem Device bootet und da schon in einer frühen Phase der Treiber geladen werden soll, aus dem initramfs. Alle meine Tests waren aber im bereits hochgefahrenen Zustand, erst dann angesteckt und geschaut was passiert.

Leider kann ich erst in knapp zwei Wochen weitertesten..

Gestern ist das passiert, was ich immer gefürchtet habe: mein yaVDR ist komplett unbrauchbar geworden, und ich blicke nicht mehr durch..

Das ganze passierte einfach so, ohne dass ich mir irgendeiner Schuld (Basteln) bewusst wäre: nach dem Booten verschwand dauernd das Bild nach wenigen Sekunden, um dann wieder kurz aufzutauchen - also dauernder Frontend-Restart. Bootete man neu, war es dann anfangs manchmal wieder OK. Dann lief es mal eine Weile gut, dann fing das wieder an. Und schliesslich war es immer so. Auf der Kommandozeile konnte man mit Müh und Not sowohl vdr wie auch vdr-frontend stoppen - aber eine vdr Instanz blieb noch da, und die konnte sogar Aufnahmen machen. Killt man alles komplett weg (-9), so bleibt noch Xorg mit beträchtlicher Last - killt man das, ersteht es sofort wieder auf. Woher kommt die Last?

Ich habe dann, nachdem eh schon nix mehr ging, ein dist-upgrade gemacht. Danach war das Flackern noch viel schneller, zwischen Schwarz und yavdr-Logo.
Im Log entsprechend (auch vorher schon) vdr-segfaults. Ich habe sämtliche plugins ausser den xine* aus /usr/lib/vdr/plugins/ entfernt - keine Besserung. Ich habe über das Webfrontend (erreichbar, der eine erste vdr Prozess scheint ja "stabil" zu laufen, obwohl ein zweiter vdr Prozess ständig crashed und neu gestartet wird, ebenso wie die vdr-sxfe bzw. xine) von xineliboutput auf xine umgestellt - nun zeigt er halt das nosignal-Logo (immer noch ständige segfaults).

Fazit: komplett unbrauchbar. Vermutlich dank des Update auch noch die FB ausser Gefecht.
In meiner Verzweiflung hatte ich zuletzt auch noch explizit das "zurückgehaltene" yavdr-essentials per apt-get install aktualisiert - eine grundsätzlich schlechte Idee?
Wie könnte man dieses einzelne Paket wieder zurücksetzen? (einige Grundlagen der Ubuntu-Paketverwaltung kenne ich ja inzwischen, aber sowas..)

Was könnte man probieren? Gibt es sowas wie einen "ReInstall" auf Paket-Ebene? Ein Zurücksetzen der Konfiguration?

Oder riecht das gar nach HW-Defekt?

Danke für alle Tips! -
Leider kann ich sie erst ab Freitag Abend nächster Woche umsetzen oder Rückfragen beantworten (es sei denn aus dem Gedächtnis), wenn ich wieder dort vor Ort bin (das kann lustig werden, bis das wieder läuft - man sollte sich für Zweitwohnungen wohl wirklich keinen VDR bauen sondern einfach eine Dreambox kaufen.. aber da kann scheints ja auch wild gebastelt werden..)

Ich kann leider bestätigen, dass speziell die S660 nicht mag, und zwar probiert mit zwei verschiedenen Kisten.
Einmal ein Acer Revo (Atom/ION) mit Ubuntu 11.04 (2.6.38 ), und einmal ein Fitpc2 (Atom) mit Suse 11.2 (2.6.31).
In beiden Fällen liefert lsusb zunächst nach dem Anstecken schon eine Ausgabe - allerdings nur die IDs, keinen "Text" für das Gerät. Module wurden noch gar nicht geladen oder Firmware fehlte.
Sobald man aber die Firmware bereitlegt und aktuelle Treiber verwendet (im ersteren Fall hatte ich ein Paket aus einem HowTo verwendet, im zweiten Fall das aktuelle s2-liplianin), hängt lsusb und im Log findet sich das "cannot enumerate".
Die Module werden zwar geladen (bis zum dvb-usb-dw2102 - müsste da noch mehr folgen?), aber es gibt kein /dev/dvb.

Schade, steht explizit im v4l-wiki als unterstützt..
Werde wohl doch nochmal ein TT 3600 bestellen, recht viel mehr Optionen hat man ja dann auch schon nicht mehr für USB/DVB-S2.

War übrigens alles völlig unabhängig von yaVDR (s. oben: Ubuntu plain, Suse - insofern falscher Thread bzw. falsches Forum, aber das Thema ist nun mal genau das)

Habe nun auch die neue Treiber-Sammlung von ufo aus dem anderen Thread probiert. Ist besser: keine Störungen mehr auf ZDF HD oder 1festival.
Aber die Privaten HD, vielleicht etwas besser, aber je höher die Bitrate (scheints), desto übler die Klötzchen.
Schade, so wird das nix.
Laufen die jetzt bei jemandem "normal"?
Man sollte meinen man kann der Karte kein besseres Umfeld bieten als ein brandneues Sandy Board (MSI H67MA) und einen x16-Slot. (ist nur Testumgebung)
Wie war das, die Theorie ist dass hier die Übertragung des Datenstroms über PCIe bei der FF zu langsam ist, wenn dekodiert werden muss? An Rechenleistung mangelts jedenfalls nicht.
Mein Traum von der HD-FF als Heilsbringer wankt grade gewaltig..

Nachdem ich mich nun bald zwei Jahre mit einem vdpau-auf-ION-basierten VDR arrangiert habe (tuts, aber macht nicht wirklich glücklich) und jahrelang das Erscheinen der HD-FF erwartet habe, hatte ich mir auch kurz danach ein Exemplar bestellt. Bis daraus ein neuer VDR gebastelt wird dauert es noch Minimum zwei Wochen, aber ich habe die Karte mal in einer anderen Kiste angetestet (H67 mit kleinem Corei3-2xxx, Kubuntu 11.04).

Ich bin nach der Anleitung aus dem Wiki (Link auf einer der vorderen Seiten hier drin) vorgegangen. Nur beim Treiber, der ja so noch nicht mit dem aktuellen 2.6.38 kompiliert, habe ich mich nach der Anleitung auf www.aregel.de gerichtet (gepostet vor 13 Tagen), sprich das Paket von dort verwendet. Das tuts mit dem 2.6.38 aus Natty, nachdem man in der v4l/.config alles mit *TIMBERDALE* rausnimmt (=n).

Und man muss sagen, das Einrichten klappt wirklich recht gut: Treiber, VDR, plugins (mit dvbhddevice), remote - und es läuft! So muss das sein, wie früher.

Die Tests sind noch nicht sehr ausgiebig gewesen, aber was ich davon ausgehend bisher sagen kann: Wiedergabe von HD-Aufnahmen und insbesondere Spulen geht wieder richtig schön smooth, einwandfrei. So muss das sein, wie früher.

Allerdings ist das längst noch nicht perfekt.
Auf ZDF HD gibt es dauernd Klötzchen und sporadische Tonprobleme.
Das OSD erscheint mit gut einer halben Sekunde Verzögerung (an der FB liegts nicht, ist man mal im Menu, geht es flott voran).
Bei SD habe ich auch den Eindruck, dass die Qualität etwas schlechter ist als mit vdpau.
Nach Umschalten wird das Bild oft nochmal schwarz, nachdem es schon da war.
Bei Wiedergabe nach Pause hat man meist nochmal zwei Tonaussetzer.
Seine Bösigkeit (nur HD--, wenn man schon für Werbung löhnt muss das auch tun) mag nur wenn beide Tuner aktiv sind, also mit zwei unabhängigen Kabeln (hab ich im Prinzip, nur eigentlich nicht zum Testen) - und wenn es dann läuft, ist das Material (live und Aufnahme) massivst von Störungen betroffen, absolut unbrauchbar. Liegt an den Tunern/DVB-Treibern, anderswo aufgezeichnetes Material wird sauber wiedergegeben.

Im Moment also leider noch nicht praxistauglich. Bleibt zu hoffen dass es kein HW-Problem ist, sondern mit Treibern/SW zu 100% aus der Welt zu schaffen ist.

Ja, ich habe hier schon von neuer FW und Patches gelesen. Die aktuelle FW müsste ich ja haben, gestern Abend gezogen. Der Treiber von aregel dagegen ist wohl nicht auf dem aktuellen Stand. Wäre schön, wenn da demnächst mal eine konsolidierte aktuelle 2.6.38-taugliche Treiber-Quelle materialisiert.

Und überhaupt - jetzt ist die Karte schon über zwei Wochen da, es ist praktisch, als hätte es sie schon immer gegeben - wo also bleibt der neue VDR 2.0 !?
Was sag ich, die rundum-sorglos-VDR-2.0-Distribution..

Also, ich bleibe gespannt, hoffe auf baldige Besserung, und Danke an alle die daran arbeiten!
Auf dass man bald auch als Gesamt-Fazit ziehen kann: So muss das sein, wie früher!

So, Jahrzehnte später habe ich jetzt auch mal das Update von 0.2 auf 0.3 gewagt (lief eigentlich ganz gut, bis auf ein HDMI-Ton-Problem).

Und ich kann bestätigen, dass die Umschalt-Probleme beim LNB-Sharing sich erledigt haben. Es kommt beim Umschalten auf die "HD-Ebene" sofort ein Bild (jedenfalls so sofort wie sonst auch).

Dank an MarkusE und den todesmutigen Tester spockele

Habe nach vielen Monaten mal wieder ein dist-upgrade gemacht, also sozusagen das Upgrade von 0.2 auf 0.3 - darunter auch ein Kernel-Upgrade von -24 auf -27.

Und es war wieder so wie einst schon mal bei -22 auf -24: kein Sound mehr (HDMI, Atom/ION-Board).

Es hat aber wieder (immer noch) das geholfen, was dieser Thread ganz vorne bzw. in einem der ersten Posts empfiehlt:
dpkg-reconfigure alsa-dkms

Interessant wäre ja schon mal, warum das immer notwendig ist, was beim normalen dist-upgrade da genau schiefläuft. Zweimal gebaut hat er ALSA jedenfalls da schon (auch für -27) - auf Atom dauert das ja ordentlich lange, das bekommt man gut mit..

Was macht das reconfigure eigentlich genau (da fehlen jetzt leider wieder die Grundkenntnisse zu Ubuntu und DKMS..)

Ansonsten hat übrigens das Update deutlich besser funktioniert, als ich befürchtet hatte: er bootet, hat WLAN-Verbindung, zeigt TV-Bild (alle Sender), FB tut, shutdown und nvram-wakeup funktioniert auch noch, ebenso XBMC - alles in allem noch keine groesseren Katastrophen bisher zu verzeichnen (toitoitoi). Starke Performance, Dank an die Macher!

Schön dass sich was tut, aber leider muss ich auch sagen: so mal eben in einem plain VDR testen bekomme ich nicht hin. Meinen Haupt-VDR habe ich zwar wie erwähnt auf diese Art ganz manuell selbst aufgebaut - aber da war ich entsprechend lange beschäftigt. Es ist ja nicht damit getan, den VDR allein zu übersetzen, man braucht mindestens noch die ganze xine-output-Geschichte, und die ist alles andere als trivial. Sorry, wenn ich das nicht im bestehenden yaVDR reinpatchen kann, wirds bei mir nichts mit dem Test.

Aber vielleicht baut es uns ja hotzenplotz gleich rein in den yavdr.

Allerdings bekommt man mittlerweile, wenn man ein normales yavdr-Update macht, wohl die aktuelle Version 0.3 - und ob das so problemlos updated von 0.2 wäre auch sehr interessant. Wie sind denn da die Berichte, kann man das riskieren? Auch diese Kiste ist mittlerweile im "Produktivbetrieb", ein Ausfall nach Update-Versuch wäre fatal..

MarkusE

Danke dass Du noch "dran" bist!

Ich werde so ab Sa 30.10. wieder vor Ort sein, dann etwas länger als nur das WoE. Melde mich dann mit den gesuchten Log-Einträgen.

Allerdings denke ich dass in meinen oben bereits geposteten Logs das mit den devices doch recht klar ist: 0+1 (bzw. 1+2) sind die beiden DVB-S2 devices, im untersten Log habe ich DVB-T ja abgeklemmt, ansonsten ist es halt device 2 bzw. 3.

Meine Log-Auszüge (Post vom 3.10.) enthalten auch jeweils schon einige Einträge von 1min nach dem Umschalten - siehe was ich dazu geschrieben habe. Man sieht jeweils einige Einträge mit LNB, ab der Zeile mit xine ist dann das Bild wieder da und ich glaube es kommt nichts weiter relevantes danach.

Wenn es dann wirklich einen Patch gibt: ich hoffe ich bekomme das mit dem Patchen und build hin - bin da nicht sonderlich geübt. Auf dem anderen selbst-gebauten System (wo ich kein LNB Sharing brauche) wäre das schon klar (make etc), aber mit yaVDR bzw. dem ganzen Ubuntu (Source-)Package-Management und wie man so ein Paket neu übersetzt habe ich keinerlei Erfahrung. Je konkretere Anleitung Du geben kannst desto besser.. Danke

Schön dass sich noch wer meldet. Dann wissen wir jetzt von drei Personen - auch noch nicht das ganz starke Argument viel Zeit zu investieren, fürchte ich. Also jeder der sich denkt "betrifft mich auch" doch auch bitte hier sagen.. und möglichst noch dazusagen in welchem Kontext, also VDR-Installation (bei mir und tüddelkopp wars yaVDR 0.2).

Zitat

testen kann ich allerdings

Ja dann nix wie los: Protokollieren einschalten und einen Log-Auszug von so einem erfolglosen Umschalt-Vorgang posten. Sollte natürlich in etwa aussehen wie bei mir, aber dann ist es zumindest mal von zwei Leuten bestätigt, und wenn nicht umso interessanter.. und vielleicht könntest Du auch etwas kurzfristiger als ich auf Lösungs-Vorschläge eingehen (bin ja im Moment nur recht selten bei der Kiste).

So, lange hats gedauert, aber nun habe ich das Protokollieren mal eingeschaltet (DiSEqC ist wie vermutet abgeschaltet), und folgendes passiert. Kanal 41 ist ARD HD, wobei ich mich vorher auf SD-Programmen rumgetrieben hatte.

Oct  2 23:37:38 flgmedia vdr: [1034] switching to channel 41
Oct  2 23:37:38 flgmedia vdr: [1034] LNB 1: Request for channel 41 on device 0. MaxBadPriority is -2
Oct  2 23:37:38 flgmedia vdr: [1034] LNB 1: Request for channel 41 on device 0. MaxBadPriority is -2
Oct  2 23:37:38 flgmedia vdr: [1034] LNB 1: Request for channel 41 on device 1. MaxBadPriority is -2
Oct  2 23:37:38 flgmedia vdr: [1034] LNB 1: Request for channel 41 on device 1. MaxBadPriority is -2
Oct  2 23:37:38 flgmedia vdr: [1034] LNB -8: Switching device 3 to channel 41
Oct  2 23:37:38 flgmedia vdr: [1034] LNB 1: Switching device 1 to channel 41
Oct  2 23:37:38 flgmedia vdr: [4296] receiver on device 2 thread started (pid=1034, tid=4296)
Oct  2 23:37:38 flgmedia vdr: [4297] TS buffer on device 2 thread started (pid=1034, tid=4297)
Oct  2 23:37:38 flgmedia vdr: [4294] osdteletext-receiver thread ended (pid=1034, tid=4294)
Oct  2 23:37:38 flgmedia vdr: [1034] buffer stats: 0 (0%) used
Oct  2 23:37:38 flgmedia vdr: [4298] osdteletext-receiver thread started (pid=1034, tid=4298)
Oct  2 23:37:38 flgmedia vdr-sxfe[1537]: [1559] [input_vdr] wait_stream_sync: discard_index 12060076538 != curpos 12060052098 ! (diff 24440)
Oct  2 23:37:38 flgmedia vdr-sxfe[1537]: [1559] [demux_vdr] PMT changed, resetting demuxer
Oct  2 23:37:38 flgmedia vdr: [4293] TS buffer on device 1 thread ended (pid=1034, tid=4293)
Oct  2 23:37:38 flgmedia vdr: [4292] buffer stats: 109416 (5%) used
Oct  2 23:37:38 flgmedia vdr: [4292] receiver on device 1 thread ended (pid=1034, tid=4292)
Oct  2 23:37:38 flgmedia vdr: [4295] [xine..put] OSD bandwidth: 199715 bytes/s (1560 kbit/s)
Oct  2 23:37:39 flgmedia vdr: [4295] [xine..put] OSD bandwidth: 331861 bytes/s (2592 kbit/s)
Oct  2 23:37:40 flgmedia vdr: [4295] [xine..put] OSD bandwidth: 221228 bytes/s (1728 kbit/s)
Oct  2 23:37:41 flgmedia vdr: [4295] [xine..put] OSD bandwidth: 221224 bytes/s (1728 kbit/s)
Oct  2 23:37:42 flgmedia vdr: [4295] [xine..put] OSD bandwidth: 221224 bytes/s (1728 kbit/s)
Oct  2 23:37:43 flgmedia vdr: [4295] Text2Skin: channelInfo display update thread ended (pid=1034, tid=4295)
Oct  2 23:37:46 flgmedia vdr-sxfe[1537]: [1559] [input_vdr] No data in 8 seconds, queuing no signal image
Oct  2 23:37:46 flgmedia vdr-sxfe[1537]: [1559] [input_vdr] using custom "no signal" image /usr/share/libxine1-xvdr/nosignal.mpg
Oct  2 23:37:47 flgmedia vdr: [1515] frontend 0/1 timed out while tuning to channel 41, tp 111362
Oct  2 23:38:38 flgmedia vdr: [1034] LNB 1: Request for channel 528 on device 0. MaxBadPriority is -1
Oct  2 23:38:38 flgmedia vdr: [1034] LNB 1: Request for channel 528 on device 0. MaxBadPriority is -1
Oct  2 23:38:38 flgmedia vdr: [1034] LNB 1: Request for channel 516 on device 0. MaxBadPriority is -1
Oct  2 23:38:38 flgmedia vdr: [1034] LNB 1: Request for channel 516 on device 0. MaxBadPriority is -1
Oct  2 23:38:38 flgmedia vdr: [1034] LNB 1: Request for channel 527 on device 0. MaxBadPriority is -1
...

Frage mich natürlich was LNB "-8" sein soll, und "device3" - könnte das DVB-T sein, wobei ja aber der LNB-Sharing-Patch von 0 ab zu zählen scheint, demnach dürfte es nur 0,1,2 geben. Und wie gesagt, auch ohne den DVB-T-Stick ist das Problem das gleiche.

Noch ein Versuch.. Wieder ausgehend von SD Sender zu ZDF HD (42).

Oct  2 23:47:36 flgmedia vdr: [1034] switching to channel 42
Oct  2 23:47:36 flgmedia vdr: [1034] LNB 1: Request for channel 42 on device 0. MaxBadPriority is -2
Oct  2 23:47:36 flgmedia vdr: [1034] LNB 1: Request for channel 42 on device 0. MaxBadPriority is -2
Oct  2 23:47:36 flgmedia vdr: [1034] LNB 1: Request for channel 42 on device 1. MaxBadPriority is -2
Oct  2 23:47:36 flgmedia vdr: [1034] LNB 1: Request for channel 42 on device 1. MaxBadPriority is -2
Oct  2 23:47:36 flgmedia vdr: [1034] LNB -8: Switching device 3 to channel 42
Oct  2 23:47:36 flgmedia vdr: [1034] LNB 1: Switching device 1 to channel 42
Oct  2 23:47:36 flgmedia vdr-sxfe[1537]: [1559] [input_vdr] wait_stream_sync: discard_index 12905546002 != curpos 12909537618 ! (dif
f -3991616)
Oct  2 23:47:36 flgmedia vdr: [4440] receiver on device 2 thread started (pid=1034, tid=4440)
Oct  2 23:47:36 flgmedia vdr: [4441] TS buffer on device 2 thread started (pid=1034, tid=4441)
Oct  2 23:47:36 flgmedia vdr: [4438] osdteletext-receiver thread ended (pid=1034, tid=4438)
Oct  2 23:47:36 flgmedia vdr: [1034] buffer stats: 0 (0%) used
Oct  2 23:47:36 flgmedia vdr: [4442] osdteletext-receiver thread started (pid=1034, tid=4442)
Oct  2 23:47:36 flgmedia vdr: [4437] TS buffer on device 1 thread ended (pid=1034, tid=4437)
Oct  2 23:47:36 flgmedia vdr: [4436] buffer stats: 76140 (3%) used
Oct  2 23:47:36 flgmedia vdr: [4436] receiver on device 1 thread ended (pid=1034, tid=4436)
Oct  2 23:47:37 flgmedia vdr-sxfe[1537]: [1559] [demux_vdr] PMT changed, resetting demuxer
Oct  2 23:47:37 flgmedia vdr: [4439] [xine..put] OSD bandwidth: 206278 bytes/s (1611 kbit/s)
Oct  2 23:47:38 flgmedia vdr: [4439] [xine..put] OSD bandwidth: 213230 bytes/s (1665 kbit/s)
Oct  2 23:47:39 flgmedia vdr: [4439] [xine..put] OSD bandwidth: 213230 bytes/s (1665 kbit/s)
Oct  2 23:47:40 flgmedia vdr: [4439] [xine..put] OSD bandwidth: 213218 bytes/s (1665 kbit/s)
Oct  2 23:47:41 flgmedia vdr: [4439] [xine..put] OSD bandwidth: 213218 bytes/s (1665 kbit/s)
Oct  2 23:47:41 flgmedia vdr: [4439] Text2Skin: channelInfo display update thread ended (pid=1034, tid=4439)
Oct  2 23:47:45 flgmedia vdr-sxfe[1537]: [1559] [input_vdr] No data in 8 seconds, queuing no signal image
Oct  2 23:47:45 flgmedia vdr-sxfe[1537]: [1559] [input_vdr] using custom "no signal" image /usr/share/libxine1-xvdr/nosignal.mpg
Oct  2 23:47:45 flgmedia vdr: [1515] frontend 0/1 timed out while tuning to channel 42, tp 111362
Oct  2 23:47:53 flgmedia vdr: [1518] frontend 1/0 timed out while tuning to channel 0, tp 626
Oct  2 23:48:36 flgmedia vdr: [1034] LNB 1: Request for channel 45 on device 0. MaxBadPriority is -2
Oct  2 23:48:36 flgmedia vdr: [1034] LNB 1: Request for channel 45 on device 0. MaxBadPriority is -2
Oct  2 23:48:36 flgmedia vdr: [1034] LNB 1: Device check for for channel 45 on device 0. OK
Oct  2 23:48:36 flgmedia vdr: [1034] LNB 1: Switching device 0 to channel 45
Oct  2 23:48:36 flgmedia vdr: [1034] LNB -2: Switching device 2 to channel 0
Oct  2 23:48:38 flgmedia vdr: [4440] [xine..put] H.264: Found NAL SPS at offset 6/151

Wartet man eine Minute, dann kommt das Bild doch noch (im Log wohl zu sehen ab der Zeile mit [xine..put]) - wenn auch oft ohne Ton (aber damit habe ich auch so gelegentlich kleine Probleme).

Und nun nochmal ohne DVB-T-Stick, nur die zwei DVB-S2 devices der Satix-Dual-Karte.

Oct  2 23:59:21 flgmedia vdr: [973] switching to channel 42
Oct  2 23:59:21 flgmedia vdr: [973] LNB 1: Request for channel 42 on device 0. MaxBadPriority is -2
Oct  2 23:59:21 flgmedia vdr: [973] LNB 1: Request for channel 42 on device 0. MaxBadPriority is -2
Oct  2 23:59:21 flgmedia vdr: [973] LNB 1: Request for channel 42 on device 1. MaxBadPriority is -2
Oct  2 23:59:21 flgmedia vdr: [973] LNB 1: Request for channel 42 on device 1. MaxBadPriority is -2
Oct  2 23:59:21 flgmedia vdr: [973] LNB -8: Switching device 2 to channel 42
Oct  2 23:59:21 flgmedia vdr: [973] LNB 1: Switching device 1 to channel 42
Oct  2 23:59:21 flgmedia vdr: [1533] receiver on device 2 thread started (pid=973, tid=1533)
Oct  2 23:59:21 flgmedia vdr: [1534] TS buffer on device 2 thread started (pid=973, tid=1534)
Oct  2 23:59:21 flgmedia vdr: [1481] osdteletext-receiver thread ended (pid=973, tid=1481)
Oct  2 23:59:21 flgmedia vdr: [973] buffer stats: 0 (0%) used
Oct  2 23:59:21 flgmedia vdr: [1535] osdteletext-receiver thread started (pid=973, tid=1535)
Oct  2 23:59:21 flgmedia vdr-sxfe[1409]: [1431] [input_vdr] wait_stream_sync: discard_index 40604240 != curpos 40602360 ! (diff 1880)
Oct  2 23:59:21 flgmedia vdr: [1482] [xine..put] OSD bandwidth: 199483 bytes/s (1558 kbit/s)
Oct  2 23:59:21 flgmedia vdr: [1480] TS buffer on device 1 thread ended (pid=973, tid=1480)
Oct  2 23:59:21 flgmedia vdr: [1479] buffer stats: 109604 (5%) used
Oct  2 23:59:21 flgmedia vdr: [1479] receiver on device 1 thread ended (pid=973, tid=1479)
Oct  2 23:59:21 flgmedia vdr-sxfe[1409]: [1431] [demux_vdr] PMT changed, resetting demuxer
Oct  2 23:59:22 flgmedia vdr: [1482] [xine..put] OSD bandwidth: 316499 bytes/s (2472 kbit/s)
Oct  2 23:59:23 flgmedia vdr: [1482] [xine..put] OSD bandwidth: 210980 bytes/s (1648 kbit/s)
Oct  2 23:59:24 flgmedia vdr: [1482] [xine..put] OSD bandwidth: 210974 bytes/s (1648 kbit/s)
Oct  2 23:59:25 flgmedia vdr: [1482] [xine..put] OSD bandwidth: 210970 bytes/s (1648 kbit/s)
Oct  2 23:59:26 flgmedia vdr: [1482] Text2Skin: channelInfo display update thread ended (pid=973, tid=1482)
Oct  2 23:59:29 flgmedia vdr-sxfe[1409]: [1431] [input_vdr] No data in 8 seconds, queuing no signal image
Oct  2 23:59:29 flgmedia vdr-sxfe[1409]: [1431] [input_vdr] using custom "no signal" image /usr/share/libxine1-xvdr/nosignal.mpg
Oct  2 23:59:31 flgmedia vdr: [1330] frontend 0/1 timed out while tuning to channel 42, tp 111362
Oct  3 00:00:21 flgmedia vdr: [973] LNB 1: Request for channel 4 on device 0. MaxBadPriority is -2
Oct  3 00:00:21 flgmedia vdr: [973] LNB 1: Request for channel 4 on device 0. MaxBadPriority is -2
Oct  3 00:00:21 flgmedia vdr: [973] LNB 1: Device check for for channel 4 on device 0. OK
Oct  3 00:00:21 flgmedia vdr: [973] LNB 1: Switching device 0 to channel 4
Oct  3 00:00:21 flgmedia vdr: [1533] [xine..put] H.264: Found NAL SPS at offset 6/151

Kanal 45 (mittleres Log) und Kanal 4 (unteres Log) sind übrigens auch jeweils Kanäle der HDTV-Ebene (Servus-TV und arte SD). Man sieht also ganz gut: sobald auch das zweite device auf die richtige Ebene geschaltet wird, ist das Bild da - aber warum passiert das immer erst (ziemlich exakt) 1min später??
Verwirrend auf jeden Fall immer: in den Zeilen mit LNB -x scheinen die devices mit 1,2 statt 0,1 gezählt zu werden.

Also, ich hoffe der Kenner erkennt jetzt was vor sich geht. Bin gespannt.

In dem oberhalb genannten Thread hat sich nun MarkusE gemeldet und einen Weg beschrieben, wie man das genauer debuggen kann (Protokoll-Option unter den LNB-Einstellungen - in yaVDR wirklich vorhanden?). Da ich erst in zwei Wochen wieder am Gerät sein werde, mag es vielleicht zwischenzeitlich schon mal jemand anderer probieren? tüddelkopp?