[0.4] Bild ruckelt

ofenheizer · 9. November 2011

Hat denn ier niemand mehr eine Idee zu?

So. Lt. Aussage der Benutzer ist es etwas besser geworden. Die Schüssel wurde noch etwas besser ausgerichtet, so dass das Signal nun stark und gut genug ist.
Aber es sind weiterhin ruckler vorhanden.
Meistens geht's einher mit dem Eintrag

Code

set_speed 1000000

das frontend.log sieht dann so aus:

Code

vi: (1800,   50, 1749), ai: ( 800,	0,  800), vo: (22, 18,  1), ao: (32,  0, 32)
video_out: throwing away image with pts 360885845 because it's too old (diff : 11862).
vi: (1800,   31, 1768), ai: ( 800,	0,  800), vo: (22, 17,  2), ao: (32,  0, 32)
video_out: throwing away image with pts 360889445 because it's too old (diff : 8262).
video_out: throwing away image with pts 360893045 because it's too old (diff : 4662).
vi: (1800,   22, 1777), ai: ( 800,	0,  800), vo: (22, 14,  4), ao: (32,  0, 32)
vi: (1800,   12, 1787), ai: ( 800,	0,  800), vo: (22, 14,  4), ao: (32,  0, 32)
video_out: throwing away image with pts 360903845 because it's too old (diff : 9910).
set_speed 125000
video_out: throwing away image with pts 360911045 because it's too old (diff : 11612).
video_out: throwing away image with pts 360914645 because it's too old (diff : 8012).
video_out: throwing away image with pts 360918245 because it's too old (diff : 4412).
vi: (1800,	0, 1799), ai: ( 800,	0,  800), vo: (22,  3, 16), ao: (32,  0, 32)
vi: (1800,	0, 1799), ai: ( 800,	0,  800), vo: (22,  3, 16), ao: (32,  0, 32)
vi: (1800,	0, 1799), ai: ( 800,	0,  800), vo: (22,  3, 15), ao: (32,  0, 32)
vi: (1800,	0, 1799), ai: ( 800,	0,  800), vo: (22,  3, 16), ao: (32,  0, 32)
vi: (1800,	0, 1799), ai: ( 800,	0,  800), vo: (22,  3, 16), ao: (32,  0, 32)
vi: (1800,	0, 1799), ai: ( 800,	0,  800), vo: (22,  3, 16), ao: (32,  0, 32)
vi: (1800,	0, 1799), ai: ( 800,	0,  800), vo: (22,  3, 16), ao: (32,  0, 32)
vi: (1800,	0, 1799), ai: ( 800,	0,  800), vo: (22,  4, 15), ao: (32,  0, 32)
vi: (1800,	0, 1799), ai: ( 800,	0,  800), vo: (22,  5, 14), ao: (32,  0, 32)
vi: (1800,	0, 1799), ai: ( 800,	0,  800), vo: (22,  6, 13), ao: (32,  3, 29)
vi: (1800,	0, 1799), ai: ( 800,	0,  800), vo: (22,  7, 12), ao: (32,  4, 28)
vi: (1800,	0, 1799), ai: ( 800,	0,  800), vo: (22,  8, 11), ao: (32,  4, 28)
vi: (1800,	0, 1799), ai: ( 800,	0,  800), vo: (22,  9, 10), ao: (32,  9, 23)
vi: (1800,	0, 1799), ai: ( 800,	0,  800), vo: (22, 10,  9), ao: (32,  9, 23)
vi: (1800,	0, 1799), ai: ( 800,	0,  800), vo: (22, 11,  8), ao: (32, 10, 22)
vi: (1800,	0, 1799), ai: ( 800,	0,  800), vo: (22, 12,  7), ao: (32, 15, 17)
vi: (1800,	0, 1799), ai: ( 800,	0,  800), vo: (22, 13,  6), ao: (32, 15, 17)
vi: (1800,	0, 1799), ai: ( 800,	0,  800), vo: (22, 14,  5), ao: (32, 16, 16)
vi: (1800,	0, 1799), ai: ( 800,	0,  800), vo: (22, 15,  4), ao: (32, 16, 16)
vi: (1800,	0, 1799), ai: ( 800,	0,  800), vo: (22, 16,  3), ao: (32, 21, 11)
vi: (1800,	0, 1799), ai: ( 800,	0,  800), vo: (22, 17,  2), ao: (32, 21, 11)
vi: (1800,	0, 1799), ai: ( 800,	0,  800), vo: (22, 18,  1), ao: (32, 22, 10)
set_speed 1000000
vi: (1800,   19, 1780), ai: ( 800,	0,  800), vo: (22, 18,  1), ao: (32,  0, 32)
vi: (1800,   96, 1703), ai: ( 800,	0,  800), vo: (22, 18,  1), ao: (32,  2, 30)
vi: (1800,  181, 1618), ai: ( 800,	0,  800), vo: (22, 18,  1), ao: (32, 26,  6)
vi: (1800,  275, 1524), ai: ( 800,   22,  777), vo: (22, 18,  1), ao: (32, 32,  0)
vi: (1800,  366, 1433), ai: ( 800,   50,  749), vo: (22, 18,  1), ao: (32, 32,  0)
vi: (1800,  359, 1440), ai: ( 800,   53,  746), vo: (22, 18,  1), ao: (32, 32,  0)
vi: (1800,  354, 1445), ai: ( 800,   53,  746), vo: (22, 18,  1), ao: (32, 32,  0)
vi: (1800,  358, 1441), ai: ( 800,   47,  752), vo: (22, 18,  1), ao: (32, 32,  0)
vi: (1800,  364, 1435), ai: ( 800,   48,  751), vo: (22, 18,  1), ao: (32, 32,  0)
vi: (1800,  360, 1439), ai: ( 800,   48,  751), vo: (22, 18,  1), ao: (32, 32,  0)
vi: (1800,  365, 1434), ai: ( 800,   47,  752), vo: (22, 18,  1), ao: (32, 32,  0)
vi: (1800,  357, 1442), ai: ( 800,   47,  752), vo: (22, 18,  1), ao: (32, 32,  0)
vi: (1800,  362, 1437), ai: ( 800,   48,  751), vo: (22, 18,  1), ao: (32, 32,  0)
vi: (1800,  358, 1441), ai: ( 800,   48,  751), vo: (22, 18,  1), ao: (32, 32,  0)
vi: (1800,  360, 1439), ai: ( 800,   48,  751), vo: (22, 18,  1), ao: (32, 32,  0)
vi: (1800,  356, 1443), ai: ( 800,   48,  751), vo: (22, 18,  1), ao: (32, 32,  0)
vi: (1800,  362, 1437), ai: ( 800,   50,  749), vo: (22, 18,  1), ao: (32, 32,  0)
vi: (1800,  342, 1457), ai: ( 800,   44,  755), vo: (22, 18,  1), ao: (32, 32,  0)
vi: (1800,  347, 1452), ai: ( 800,   48,  751), vo: (22, 18,  1), ao: (32, 32,  0)
vi: (1800,  343, 1456), ai: ( 800,   48,  751), vo: (22, 18,  1), ao: (32, 32,  0)
vi: (1800,  329, 1470), ai: ( 800,   47,  752), vo: (22, 18,  1), ao: (32, 32,  0)
vi: (1800,  336, 1463), ai: ( 800,   51,  748), vo: (22, 18,  1), ao: (32, 32,  0)
vi: (1800,  340, 1459), ai: ( 800,   53,  746), vo: (22, 18,  1), ao: (32, 32,  0)
vi: (1800,  339, 1460), ai: ( 800,   48,  751), vo: (22, 18,  1), ao: (32, 32,  0)
vi: (1800,  337, 1462), ai: ( 800,   48,  751), vo: (22, 18,  1), ao: (32, 32,  0)
vi: (1800,  345, 1454), ai: ( 800,   53,  746), vo: (22, 18,  1), ao: (32, 32,  0)
vi: (1800,  340, 1459), ai: ( 800,   47,  752), vo: (22, 18,  1), ao: (32, 32,  0)
vi: (1800,  345, 1454), ai: ( 800,   48,  751), vo: (22, 18,  1), ao: (32, 32,  0)
vi: (1800,  342, 1457), ai: ( 800,   48,  751), vo: (22, 18,  1), ao: (32, 32,  0)
vi: (1800,  335, 1464), ai: ( 800,   54,  745), vo: (22, 18,  1), ao: (32, 32,  0)
vi: (1800,  333, 1466), ai: ( 800,   54,  745), vo: (22, 18,  1), ao: (32, 32,  0)
vi: (1800,  336, 1463), ai: ( 800,   57,  742), vo: (22, 18,  1), ao: (32, 32,  0)
vi: (1800,  323, 1476), ai: ( 800,   57,  742), vo: (22, 18,  1), ao: (32, 32,  0)
vi: (1800,  331, 1468), ai: ( 800,   48,  751), vo: (22, 18,  1), ao: (32, 32,  0)
vi: (1800,  326, 1473), ai: ( 800,   48,  751), vo: (22, 18,  1), ao: (32, 32,  0)
vi: (1800,  330, 1469), ai: ( 800,   52,  747), vo: (22, 18,  1), ao: (32, 32,  0)
vi: (1800,  328, 1471), ai: ( 800,   46,  753), vo: (22, 18,  1), ao: (32, 32,  0)

Alles anzeigen

Im syslog tauchen dann auch schonmal ab und zu solche Meldungen auf:

Code

Nov  9 18:22:55 vdrmp vdr: [5173] cAudioRepacker(0xC0): skipped 312 bytes while syncing on next audio frame

Woran kann es denn nun liegen. Scheine ja der einzige zu sein, den das Problem betrifft. Kann denn auch der Fernseher mit irgendwelchen Einstellungen das Problem verursachen?

traxanos · 10. November 2011

Tut mir Leid ich habe mich damit abgefunden. Ich habe über 2 Jahre darauf gehofft, dass es endlich stabil läuft. Das war auch der Grund warum ich den Logger integriert habe, ich wollte sehen wo es hängt. Ich vermute das es sogar an vdpau selbst liegt, denn wenn ich alles in Software decodiere läuft es rund. hab auch schon nen Haufen verschiedener DVB-S Karten getestet um Probleme des Treibers auszuschließen. Das einzige was ich aus den unzähligen Tests meine herausgefunden zu haben ist das VDPAU auf langsamen Rechner immer wieder Aussetzer hat. Ein altes Mainboard mit nem alten Athlon und einer 9200er ist aktuell das einzige Mainboard das weitestgehend rund läuft. Mein Ergebniss war dann mir ne 6400 zu kaufen.

ofenheizer · 10. November 2011

Hm. Danke für die Rückmeldung.
Aber wir haben es ja lauffähig bekommen unter der 0.1
Habe es ja nur ersetzt, da die PLatte den Geist aufgegeben hatte..
Langsam würde ich die Hardware ja auch nicht bezeichnen - Asus-Board mit Sempron LE-1250 und 1GB RAM, dazu noch eine Gainward 210 Grafikkarte. Schon komisch - und ich habe noch immer den Philips-LCD mit in Verdacht. Denn wie gesagt bei Tests an meiner Röhre hatte ich keine solchen Probleme.
Ich habe jez auch mal die Pufferwerte für xine erhöht und lass beobachten. Evtl. teste ich noch mal mit xinelibout (das mag ich eh lieber, schon alleine wegen des integrierten Players.

hotzenplotz5 · 10. November 2011

ich kann solche aussagen nicht verstehen.
scheinbar gibt es ja genug mit lauffähigem system ?
ich hab solche fehler nie !

macht es dvb-c besser ? an der bitrate kann es nicht liegen.
die wird hier doch 1:1 übernommen sat <-> wilhelm tel.

also glaube ich immer noch -> hardware, nix vdpau problem.

ich kann sogar mit meinem ion2 endlich anthra (wow) flüssig betrachten, ohne das was hängenbleibt ...
das einzige was auffällt ist die laufschrift bei hud/opengl bzw. die dadurch schlechtere bildqualität.

aber dafür gibt es ja das xine plugin, welches wiederum den nachteil mit dem osd einpassen hat (bähh hässlich)

ofenheizer · 10. November 2011

Zitat von hotzenplotz5

ich kann solche aussagen nicht verstehen.
scheinbar gibt es ja genug mit lauffähigem system ?
ich hab solche fehler nie !

macht es dvb-c besser ? an der bitrate kann es nicht liegen.
die wird hier doch 1:1 übernommen sat <-> wilhelm tel.

also glaube ich immer noch -> hardware, nix vdpau problem.

ich kann sogar mit meinem ion2 endlich anthra (wow) flüssig betrachten, ohne das was hängenbleibt ...
das einzige was auffällt ist die laufschrift bei hud/opengl bzw. die dadurch schlechtere bildqualität.

aber dafür gibt es ja das xine plugin, welches wiederum den nachteil mit dem osd einpassen hat (bähh hässlich)

Alles anzeigen

hardware schliesse ich aus. erstens hat sich nur die dvb-hardware geändert. statt dvb-c jetzt dvb-s2. weiter habe ich diese aktuelle kombi (jetzt schreibe ich es bestimmt zum x-ten mal) an meiner sat-anlage betrieben. keine probleme!! die neue umgebung war nur neue sat-anlage und neuer fernseher (bei mir halt röhre mit vga2scart). die sat-anlage ist inzwischen super ausgerichtet. bleibt hier jetzt nur noch der philips-lcd.

und ja, auch vorher mit dvb-c (standard dvb-c karten mit satelco und terratec 1200) hatten wir an dem philips anfänglich probleme. aber das war noch zu yavdr 0.1er zeiten, wo man noch bei sound und xorg eingreifen musste.

ich schiebe hier nichts auf vdpau, aber auch die hardware schliesse ich auch, denn die TT1600 und die Tevii S480 ist hier im Forum mehrfach in betrieb, ohne das laufend Meldungen dazu kommen. Auch ohne die Tevii gabs die Probleme und auch nur mit der Tevii gabs die Probleme. Ist ja nicht so, dass ich nicht versucht hätte, da was auszuschliessen.
Auch Aufnahmen ruckeln teilweise bzw. die Wiedergabe einer *.avi. Also denke ich schonmal nicht, dass es ein Hardwareproblem ist.

Mit anthras habe ich auch keine Probleme.

hotzenplotz5 · 10. November 2011

trotzdem merkwürdig, ich hab das nicht.
was mach ich falsch ?

ofenheizer · 10. November 2011

Zitat von hotzenplotz5

trotzdem merkwürdig, ich hab das nicht.
was mach ich falsch ?

find ich nicht so lustig.
ist eben blöd, wenn man nicht direkt vor der kiste sitzen kann und testen. beschreibungen sind immer subjektiv.

bei mir lief es ja auch und meine hardware läuft auch. ich weiss ja auch nicht, woran es liegen könnte. ich habe halt immer noch den 'blöden' philips in verdacht, dass da irgendwas in der kommunikation per hdmi nicht stimmt.

ich bleibe dran ....

hsteinhaus · 10. November 2011

Zitat von hotzenplotz5

ich kann sogar mit meinem ion2 endlich anthra (wow) flüssig betrachten, ohne das was hängenbleibt ...
das einzige was auffällt ist die laufschrift bei hud/opengl bzw. die dadurch schlechtere bildqualität.

Kann ich nicht bestätigen. Mit dem ION2 läuft das OSD hier nur mit HUD einigermaßen ruckelfrei. Leider führt das zu einem ziemlichen Totalschaden des Bildes - alle senkrechten und sich bewegenden Kanten zittern. Die Laufschrift ist nur die Spitze des Eisbergs. Xine wiederum führt früher oder später reproduzierbar zum Totalausfall mit >50% Framedrops auf HD-Sendern (z.B. ARD HD). Der einzige tolerable (aber nicht einwandfreie) Weg ist momentan xineliboutput ohne HUD aber mit nervigem OSD und gelegentlichen Segfaults / Buffer Overflows (etwa einer in 5h). Über die OSD-Ruckler hinaus läuft der Stream aber einwandfrei.

Grüße,
Holger

hotzenplotz5 · 10. November 2011

Code

find ich nicht so lustig.

ich auch nicht.
mich nerven nur die haltlosen verdächtigungen.
keiner weiss warum ihr das habt, aber einfach generalverdächtigungen aussprechen ist scheisse.

einer hat irgendwann mal angefangen, dass es vdpau wäre, seitdem schreien es alle nach.

ich kann mich an falsche aufnahmenlänge noch erinnern.
alles hat gebrüllt xineliboutput ist esm dabei war es vdr.

aber am ende mir auch wurscht. macht was ihr wollt.
ich seh ja an den fernbedienungen wie bescheuert das ganze ist.

einer macht es falsch vor, und bevor die anderen die durchaus vorhandene doku lesen (sache von 3min.)
machen es alle falsch nach !

weiter so !

ofenheizer · 10. November 2011

@hoplo
hm. also ich habe völlig neutral ein problem geschildert, mit der hoffnung, dass wissende was dazu beitragen können.
ich habe nicht mit einem wort irgendwelche vermutungen in richtung vdpau oder sonst was gestellt.

eher kam sowas deinerseits, siehe hardware oder die unangebrachten kommentare zu dynamite ... wenn sogar traxanos das problem hat/hatte, scheint es ja existent zu sein und nur weil es bei dir läuft, heisst es nicht, dass es woanders nicht richtig läuft.
deinen frust über die unzähligen fernbedienungsthreads (ja auch ich nehme das leicht genervt zur kenntnis) jetzt hier auszulassen, finde ich auch nicht in ordnung.

hotzenplotz5 · 10. November 2011

Code

und mit den Pufferwerten in der config habe ich auch schon gespielt

naja ....
ja sehr neutral bemerkt das es an den pufferwerten liegt.
also doch vorher woanders falsch gelesen.

nochmal, mir ist klar das es probleme gibt.
auch deine hatte ich schon. es lag an einer anderen dvb-c karte und warscheinlich am treiber weil er mit windows am selben pc ohne probleme lief.
aber lass gut sein.

ich denke nicht, das solche threads zur problemlösung beitragen.
ich hab schon hundertmal gepostet, dass wenn einer von euch damit ein problem hat, warum er das nicht dem autor zukommen lassen kann/will ?

was soll das hier ? was hilft es ?
es gibt tausende versuche seinen empfang besser zu machen in dem man den puffer bei libxine erhöht ......
und auch nach tausend threads wird es nicht besser.

traxanos · 10. November 2011

Also meine aussagen sind nicht haltlos, denn ich kann es auch jedem System reproduzieren. Ausnahme ist deiner, dafür hab ich da lange nicht genug getestet ob mit Sicherheit sagen zu können das du das problem nicht hast. aber du nutzt auch dvb-c. Und in meinem Bekanntenkreis haben alle das Problem auch. Es stören nur keinen von denen. UNd auhc ich hab schon mal gesagt die die 0.1 die Probleme nicht hatte mit damaliger Hardware. Und wer es nicht glaubt, kann vorbei kommen. Ich zeigt es jedem auf verschiedener Hardware!!! Und nochmal ohne VDPAU geht es. Den Deinterlacer hab ich auch schon ausgeschlossen, da es ohne Deinterlacer sowie mit Softwaredeinterlace auch zu den Rucklern kommt.

Ich "mein Meinung" glaube daher immer noch das es VDPAU schuld ist. Ich kann auch nicht nachvollziehen warum, wenn man ein OSD etwas länger nicht geöffnet hat, immer extrem ruckelt und das Bild kurz hängt. Manhcmal sogar einfriert und flackert bis das Menu zu ist. Danach kann ich paar mal Menü offnen ohne Problem mit nur 1 Framedrop. Warte ich wieder längere zeit hängt es. Irgend was passiert intern. Spromspar vom ATOM oder der GFX ich weis es nicht. Die Ruckler habe ich auch in Filmen die 100% in Ordnung sind (XBMC stable sowie pvr), somit glaube ich auch nicht das es mit dem Empfang zu tun hat.

ChrisP · 10. November 2011

So meld ich mich auch mal zu Wort.
Was ich schon alles getrieben habe um diese ruckler wegzubekommen... (noch einen andere tv Karte, x-mal Sat Schüssel eingestellt, verchiedene distris, mehr RAM, WLAN-LAN, Plugins deaktiviert, Puffer geändert,...)
Aber sie gehen nicht weg...
Dank euch beiden kann ich jetzt einen Schlussstrich ziehen da es ja scheinbar nicht an mir liegt...
Mit den rucklern muss ich wohl leben
Der VDR muss jetzt wohl ins Schlafzimmer, denn mich stören die ruckler und vor allem auch das beschriebene stocken wenn man das osd mal eine Stunde nicht verwendet hat.

traxanos · 10. November 2011

kleiner nachtrag: wenn ich etwas aufnehme, und es ruckelt, und ich dann zurück spring, ruckelt es nicht. somit kann es keine empfangstörung sein.

Fozzybär · 11. Dezember 2011

Zitat von traxanos

mal in /etc/init/vdr-frontend.conf

das # vor BUFFER_LOGGER ö.ä. raus nehmen.

und dann in /tmp/vdr-frontend.log schauen.

Schön guten Morgen und einen schönen dritten Advent wünsche ich,
der Thread ist zwar schon etwas älter, jedoch vermute ich, dass ich irgendwo/wie das gleiche Problem habe.

Mein "Problem" sieht so aus, dass ich circa nach einer einen kleinen Tonaussetzer habe, nicht wirklich schlimm..

Aber die Tonaussetzer kommen immer wieder und in kürzeren Abständen, bis es dann alle paar Minuten kommt,
irgendwann kommen sogar in sehr seltenen Fällen sogar Bildstörungen dazu.

Dazu habe ich nun eine in dem Xine-Plugin den Audio buffer von 6 auf 10 gestellt und den Überwachungsmodus auf
dauerhaft gestellt. Und es scheint damit wesentlich besser zu sein. Des Weiteren (das war sehr wichtig) den USB-Legancy-Modus
im Bios ausgeschaltet.

Das heisst folgendes:
Etwa eine Stunde das selbe Programm geschaut, dann kam der nächste erst eine halbe Stunde später, der nächste
wieder erst 30 Minuten später... wenn es so bleibt, ist es für mich OK.

Ich schreibe, um eventuell den Forenmitgliedern, die diese Probleme analysieren können und etwas mit der Ausgabe
vom frontend.log etwas anfangen können. Eventuell dient es ja zur Fehlersuche/Behebung.

Wenn so ein aussetzer kommt, sieht es so im log aus:

Code

DFAtmo: grab 1323594534.078: vpts=509077676
DFAtmo: grab 1323594534.118: vpts=509084174
set_speed 125000
DFAtmo: grab 1323594534.158: vpts=509084876
DFAtmo: grab 1323594534.198: vpts=509091368
DFAtmo: grab 1323594534.238: vpts=509094971
DFAtmo: grab 1323594534.278: vpts=509095676
DFAtmo: grab 1323594534.318: vpts=509099276
DFAtmo: grab 1323594534.358: vpts=509105772
DFAtmo: grab timed out!
DFAtmo: grab 1323594534.498: vpts=509106476
set_speed 1000000
DFAtmo: grab 1323594534.533: vpts=509110076
DFAtmo: grab timed out!
DFAtmo: grab 1323594534.668: vpts=509113676
video_out: throwing away image with pts 509117276 because it's too old (diff : 8110).
DFAtmo: grab 1323594534.703: vpts=509125386
video_out: throwing away image with pts 509124476 because it's too old (diff : 4541).
DFAtmo: grab 1323594538.938: vpts=509507044
200 frames delivered, 0 frames skipped, 2 frames discarded

Alles anzeigen

Wenn ich diese Zeilen versuche zu verstehen, sieht es für mich so aus, als würde das DFatmo da irgendwas machen.

steffen_b · 11. Dezember 2011

Die interessanten Zeilen sind:
video_out: throwing away image with pts 509117276 because it's too old (diff : 8110).
video_out: throwing away image with pts 509124476 because it's too old (diff : 4541).

Warum und weshalb das passiert weiss ich nicht. Mein momentanes Verständnis sagt mir das die Standardmethode (resample) mit Digitalausgabe nicht funktionieren kann. Ob man das wegschmeissen von Bildern besser steuern kann (wenn hier und da ein Frame discarded wird dürfte es nicht zu sichtbaren Störungen kommen) konnte ich nicht ergründen. Es kann andersrum auch gut sein daß das altbekannte NVidia Treiberproblem hier zuschlägt und vdpau ab und zu zu lange braucht um einen Frame zu dekodieren und damit das Problem auslöst.

ofenheizer · 17. Dezember 2011

So, nach langem rumprobieren haben wir den Verursacher dieser Störungen gefunden.
Es ist die Tevii S480. Nachdem die Karte ausgebaut wurde und nur noch die TT1600 im Sytem war, sind alle Ruckler verschwunden. Die Puffer wie in den Logs dargestellt laufen nicht mehr leer.
Ist natürlich jetzt die Frage, ob die Karte einen Defekt hat oder ob sie einfach nicht mag. Da aber andere die Karte auch benutzen und nicht diese massiven Fehler haben, gehe ich eher von einem Hardwaredefekt aus.
Werde nun mal versuchen gleichwertigen (im Finanzrahmen) Ersatz zu bekommen (Mystique Sky S2).
Weiteres Problem, was sich daraus ergibt, ist das nach Installation des media-dkms die FB (Harmony am Antec-Empfänger) nicht mehr ging und es über 500km Entfernung schwer ist die FB dann wieder ans Laufen zu bekommen.

Gruss
Markus

hotzenplotz5 · 17. Dezember 2011

jajaja soll noch einmal einer sagen ich hätte das nicht vorher gesagt:
[0.4] Bild ruckelt

14.Nov.

aber auf mich will ja keiner hören ...

ich sag doch : eure satkarten sind alle scheisse

CKone · 17. Dezember 2011

Zitat von ofenheizer

Werde nun mal versuchen gleichwertigen (im Finanzrahmen) Ersatz zu bekommen (Mystique Sky S2).

verkauft hier nicht jemand im Board ne cine/Mystique für kleines Geld, Markus, meine ich hätte letztens sowas gelesen....

[Edit] hier: V: VDR Hardware (TV Karten, AlphaCrypt) [\Edit]

Lass dir aber unbedingt ne Rechnung dafür geben.

Gruß Christian

ofenheizer · 19. Dezember 2011

Naja, ich denke mal nicht, dass die S480 eine so schlechte Karte ist. Empfang war immer gut. Und bei anderen funktioniert sie ja auch tadellos unter yavdr.
Nun habe ich nochmal alte Logs durchforstet und mit den aktuellen verglichen, dabei ist mir folgendes aufgefallen:

mit eingebauter Tevii S480 bekomme ich im Kernel-Log beim Booten folgendes:

Code

Dec 13 18:05:55 vdrmp kernel: [	1.552876] Freeing unused kernel memory: 1440k freed
Dec 13 18:05:55 vdrmp kernel: [	2.030955] usb 3-1: new high speed USB device using ehci_hcd and address 2
Dec 13 18:05:55 vdrmp kernel: [	2.182956] usb 3-1: config 1 interface 0 altsetting 0 bulk endpoint 0x81 has invalid maxpacket 2
Dec 13 18:05:55 vdrmp kernel: [	2.490644] usb 2-1: new high speed USB device using ehci_hcd and address 2
Dec 13 18:05:55 vdrmp kernel: [	2.565949] <30>udev[111]: starting version 167
Dec 13 18:05:55 vdrmp kernel: [	2.642394] usb 2-1: config 1 interface 0 altsetting 0 bulk endpoint 0x81 has invalid maxpacket 2
Dec 13 18:05:55 vdrmp kernel: [	2.850601] usb 6-1: new low speed USB device using ohci_hcd and address 2
Dec 13 18:05:55 vdrmp kernel: [	3.290912] usb 6-2: new full speed USB device using ohci_hcd and address 3
Dec 13 18:05:55 vdrmp kernel: [	3.551165] vesafb: framebuffer at 0xcf000000, mapped to 0xffffc90010580000, using 3072k, total 3072k
Dec 13 18:05:55 vdrmp kernel: [	3.551218] vesafb: mode is 1024x768x32, linelength=4096, pages=0
Dec 13 18:05:55 vdrmp kernel: [	3.551267] vesafb: scrolling: redraw
Dec 13 18:05:55 vdrmp kernel: [	3.551318] vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0
Dec 13 18:05:55 vdrmp kernel: [	3.556711] Console: switching to colour frame buffer device 128x48
Dec 13 18:05:55 vdrmp kernel: [	3.557584] fb0: VESA VGA frame buffer device
Dec 13 18:05:55 vdrmp kernel: [	3.920549] usb 6-7: new low speed USB device using ohci_hcd and address 4
Dec 13 18:05:55 vdrmp kernel: [	5.720937] irq 9: nobody cared (try booting with the "irqpoll" option)
Dec 13 18:05:55 vdrmp kernel: [	5.720944] Pid: 162, comm: blkid Not tainted 2.6.38-13-generic #52-Ubuntu
Dec 13 18:05:55 vdrmp kernel: [	5.720946] Call Trace:
Dec 13 18:05:55 vdrmp kernel: [	5.720949]  <IRQ>  [<ffffffff810d515b>] ? __report_bad_irq.clone.2+0x2b/0xa0
Dec 13 18:05:55 vdrmp kernel: [	5.720963]  [<ffffffff810d555a>] ? note_interrupt+0x19a/0x1e0
Dec 13 18:05:55 vdrmp kernel: [	5.720967]  [<ffffffff8106d559>] ? __do_softirq+0xf9/0x1c0
Dec 13 18:05:55 vdrmp kernel: [	5.720970]  [<ffffffff810d644d>] ? handle_fasteoi_irq+0xdd/0x110
Dec 13 18:05:55 vdrmp kernel: [	5.720975]  [<ffffffff8100e9c2>] ? handle_irq+0x22/0x40
Dec 13 18:05:55 vdrmp kernel: [	5.720980]  [<ffffffff815cb3fd>] ? do_IRQ+0x5d/0xe0
Dec 13 18:05:55 vdrmp kernel: [	5.720983]  [<ffffffff815c3753>] ? ret_from_intr+0x0/0x15
Dec 13 18:05:55 vdrmp kernel: [	5.720985]  <EOI>  [<ffffffff815c374e>] ? common_interrupt+0xe/0x13
Dec 13 18:05:55 vdrmp kernel: [	5.720990]  [<ffffffff81038bef>] ? __ticket_spin_lock+0x1f/0x20
Dec 13 18:05:55 vdrmp kernel: [	5.720993]  [<ffffffff815c31de>] ? _raw_spin_lock+0xe/0x20
Dec 13 18:05:55 vdrmp kernel: [	5.720997]  [<ffffffff81134e80>] ? vma_adjust+0xa0/0x4a0
Dec 13 18:05:55 vdrmp kernel: [	5.721001]  [<ffffffff811353ba>] ? __split_vma+0x13a/0x280
Dec 13 18:05:55 vdrmp kernel: [	5.721004]  [<ffffffff811362ed>] ? do_munmap+0x34d/0x360
Dec 13 18:05:55 vdrmp kernel: [	5.721009]  [<ffffffff812daf3a>] ? find_next_bit+0x9a/0xb0
Dec 13 18:05:55 vdrmp kernel: [	5.721012]  [<ffffffff811367f7>] ? mmap_region+0xa7/0x500
Dec 13 18:05:55 vdrmp kernel: [	5.721015]  [<ffffffff81045882>] ? flush_tlb_mm+0x42/0xa0
Dec 13 18:05:55 vdrmp kernel: [	5.721019]  [<ffffffff81136f85>] ? do_mmap_pgoff+0x335/0x370
Dec 13 18:05:55 vdrmp kernel: [	5.721022]  [<ffffffff811371be>] ? sys_mmap_pgoff+0x1fe/0x230
Dec 13 18:05:55 vdrmp kernel: [	5.721026]  [<ffffffff81010b49>] ? sys_mmap+0x29/0x30
Dec 13 18:05:55 vdrmp kernel: [	5.721029]  [<ffffffff8100c002>] ? system_call_fastpath+0x16/0x1b
Dec 13 18:05:55 vdrmp kernel: [	5.721031] handlers:
Dec 13 18:05:55 vdrmp kernel: [	5.721032] [<ffffffff813374d4>] (acpi_irq+0x0/0x31)
Dec 13 18:05:55 vdrmp kernel: [	5.721038] Disabling IRQ #9

Alles anzeigen

der gleiche Bereich sieht nach Ausbau der Karte so aus:

Code

Dec 18 23:39:23 vdrmp kernel: [	0.583340] Freeing initrd memory: 13244k freed
Dec 18 23:39:23 vdrmp kernel: [	0.594364] Freeing unused kernel memory: 960k freed
Dec 18 23:39:23 vdrmp kernel: [	0.595045] Write protecting the kernel read-only data: 10240k
Dec 18 23:39:23 vdrmp kernel: [	0.595872] Freeing unused kernel memory: 184k freed
Dec 18 23:39:23 vdrmp kernel: [	0.601421] Freeing unused kernel memory: 1440k freed
Dec 18 23:39:23 vdrmp kernel: [	0.628632] <30>udev[93]: starting version 167
Dec 18 23:39:23 vdrmp kernel: [	0.672975] vesafb: framebuffer at 0xcf000000, mapped to 0xffffc90010580000, using 3072k, total 3072k
Dec 18 23:39:23 vdrmp kernel: [	0.672981] vesafb: mode is 1024x768x32, linelength=4096, pages=0
Dec 18 23:39:23 vdrmp kernel: [	0.672983] vesafb: scrolling: redraw
Dec 18 23:39:23 vdrmp kernel: [	0.672986] vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0
Dec 18 23:39:23 vdrmp kernel: [	0.673128] Console: switching to colour frame buffer device 128x48
Dec 18 23:39:23 vdrmp kernel: [	0.673151] fb0: VESA VGA frame buffer device

Alles anzeigen

Kann mir da einer auf die Sprünge helfen? Irgendeine Bioseinstellung?
Muss einen Grund haben, dass die S480 diesen Kernel-Fehler verursacht. Oder doch ein Hardwaredefekt?

Danke und Gruss.
Markus

[0.4] Bild ruckelt

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema