Beiträge von cyberjunk

moin zulu,

mensch die neuen versionen erscheinen hier ja fast täglich, da komm ich ja gar nicht mehr mit meine VDR sources zu updaten Aber weiter so!

Ich schreib mal noch ein paar Dinge, die mir so in den Sinn gekommen sind und evtl. nützlich für dich/den extensions Patch sein könnten (rein informativ..)

1) VDR-Patch für SoftOSD per xineliboutput aufnehmen?

In dem entsprechenden Thread [ANNOUNCE] xineliboutput-SOFTOSD-Patch (nicht NUR für Softies) wird ein Patch "osdbase.diff" angeboten, ich nutze ihn hier auf meinen VDR Versionen mit xineliboutput+SoftOSD. Wenn ich den Thread richtig verstehe ist er dafür Pflicht(?).

Der Patch funktioniert hier mit sämtlichen VDR Versionen ohne rejects, ist auch super winzig (fügt nur wenig hinzu, ändert nichts)

Da du bereits einen "SOFTOSD" drin hast (ich denke für FF-Karte?), wäre es evtl. interessant diesen auch mit aufzunehmen?

Probleme sofern kein xineliboutput (andre ausgabevarianten) oder kein xineliboutput mit softosd-patch genutzt wird konnte ich nach ersten Tests nicht feststellen, aber garantieren tu ich natürlich für nix

Ich hab den Patch auch nochma angehängt...

2) HUD-OSD Patch für VDR mit aufnehmen?
Auch seit einer Weile gibt es ja diesen Patch, der die Werte der maximal mögliche OSD Größen hochsetzt. Im Umfang auch super-winzig (funktioniert mit jeder VDR Version eigentlich), kaum problematisch aber nötig für zumindest die Ausgabe per xineliboutput und HUD-OSD und daher doch evtl. auch eine Integration wert?

Ich hab den Patch auch nochma angehängt...

grüße

moin jensa,

interessantes und v.a. großes Projekt, das du da vor hast...

Ich glaube im Inneren träumen wir alle von so einem vollautomatisierten High-Tech Haus, deswegen schonmal viel Erfolg bei der Umsetzung

Zu deinem größen Fragepunkt kann ich Dir leider auch nicht viel helfen, also hierzu:

Zitat

Und Als große Komponente soll noch Hausautomatisierung den Einzug finden.

Also das Automatisierung von Rollläden usw... leider muss ich die noch von Hand ziehn

Da du aber viel das Thema Telefonie/ISDN angesprochen hast wollte ich Dir aber evtl. noch einen evtl. nützlichen Hinweis auf ein Open-Source Projekt geben, das Stichwort fiel bei Dir glaube ich bisher nicht:

Asterisk
http://www.asterisk.org/

Ich persönlich find es eine tolle und v.a. extrem günstige All-round Lösung für den Bereich Telefonanlage. Die Möglichkeiten sind vielzählig, aber es ist auch nicht ganz einfach aufzusetzen, bzw. zu konfigurieren...

Bei mir ist es auf meinem 0815 Linux-Router-PC installiert, verbindet sich dann nach aussen/extern über einen bestehenden online SIP Account bei meinem ISP sowie per ISDN über eine herkömmliche FritzCard über den ISDN-Hausanschluss.

Nach innen werden diese verfügbaren externen-Leitungen dann auf bestehende "Asterisk-Accounts" gemapped, welche dann entweder über SIP-Software-Clients(an den Haus-PCs) oder SIP-Hardware-Clients(Telefone) genutzt werden können. Natürlich bietet das Ganze allen gewohnten Komfort von Telefonanlagen, also Weiterleitungen, interne Gespräche, Mailbox, Warteschleifen usw...

Vielleicht ein Blick wert, zumindest günstiger als jede kaufbare Alternative...

Aber Vorsicht: Suchtgefahr
Damit kann man sich schon fast so ausgiebig beschäftigen wie mit dem VDR

grüße

moin zulu,

hier noch eine Rückmeldung zum neuesten extp69
(in diesem fall vdr 1.6.0, die andren bisher nicht getestet)

Wenn ich "HARDLINKCUTTER" aktivier in der Make.config

Zitat

HARDLINKCUTTER = 1

dann mag der VDR 1.6.0 nicht mehr compilen:

Zitat

g++ -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses -c -DUSE_ANALOGTV -DUSE_ATSC -DUSE_CHANNELSCAN -DUSE_CMDRECCMDI18N -DUSE_CMDSUBMENU -DUSE_CUTTERLIMIT -DUSE_CUTTERQUEUE -DUSE_CUTTIME -DUSE_DDEPGENTRY -DUSE_DELTIMESHIFTREC -DUSE_DOLBYINREC -DUSE_DVBPLAYER -DUSE_DVBSETUP -DUSE_DVDARCHIVE -DUSE_DVLRECSCRIPTADDON -DUSE_DVLVIDPREFER -DUSE_DVLFRIENDLYFNAMES -DUSE_EM84XX -DUSE_GOTOX -DUSE_GRAPHTFT -DUSE_HARDLINKCUTTER -DUSE_JUMPPLAY -DUSE_LIEMIEXT -DUSE_LIRCSETTINGS -DUSE_LIVEBUFFER -DUSE_LNBSHARE -DUSE_MAINMENUHOOKS -DUSE_SETUP -DUSE_NOEPG -DUSE_OSDMAXITEMS -DUSE_PARENTALRATING -DUSE_PINPLUGIN -DUSE_PLUGINMISSING -DUSE_PLUGINPARAM -DUSE_ROTOR -DUSE_SETTIME -DUSE_SOFTOSD -DUSE_SOURCECAPS -DUSE_SORTRECORDS -DUSE_SYNCEARLY -DUSE_STREAMDEVEXT -DUSE_TIMERCMD -DUSE_TIMERINFO -DUSE_TTXTSUBS -DUSE_VALIDINPUT -DUSE_VOLCTRL -DUSE_WAREAGLEICON -DUSE_YAEPG -DREMOTE_KBD -DREMOTE_LIRC -DLIRC_DEVICE=\"/dev/lircd\" -DRCU_DEVICE=\"/dev/ttyS1\" -D_GNU_SOURCE -DVIDEODIR=\"/video0\" -DCONFDIR=\"/etc/vdr\" -DPLUGINDIR=\"/usr/vdr/plugins\" -DLOCDIR=\"/usr/vdr/locale\" -DUSE_DVDCHAPJUMP -DUSE_PLUGINAPI -I/usr/include/freetype2 -I/usr/local/src/DVB/linux/include -I/usr/include/dvdread videodir.c videodir.c: In function 'bool HardLinkVideoFile(const char*, const char*)': videodir.c:309: error: 'cStatus' has not been declared videodir.c:309: error: 'scMod' was not declared in this scope make: *** [videodir.o] Fehler 1

Deaktivier ich HARDLINKCUTTER im extp69 verschwindet der compile-fehler.. Mit extp68 ging es aber auch noch mit aktiviertem HARDLINKCUTTER...

grüße

Hm, in dem neuen extp69 ist der Patch "vdr-1.6.0-ext69_gotox.diff" entpackt ~4 MB groß und tauscht praktisch die gesamten vdr-sources aus (einschließlich rejects )

im extp68 ist der patch noch deutlich kleiner...
ein fehler ??

grüße...

Hallo ihr,

Zitat

Hat jemand schon Anpassungen für die CVS Version 1.0.4 gemacht? xineliboutput-1.0.3-softosd-0.0.3.diff liefert rejects in config.c config.h und menu.c

das hab ich mich auch gefragt und mal etwas getestet,
dabei kam folgendes heraus:

1) Der Patch "xineliboutput-1.0.3-softosd-0.0.3.diff " auf der ersten Seite funktioniert zumindest hier noch gegen xineliboutput-1.0.4:

2) Der zugehörige Patch für den VDR (osdbase.diff, auch erste Seite) funktioniert auch noch mit vdr-1.7.4 (1.7.0 natürlich auch):

3) Für das aktuelle xineliboutput cvs von heute (30.03.2009) hab ich versucht mir ausgehend von xineliboutput-1.0.3-softosd-0.0.3.diff den im Anhang befindlichen Patch zusammen zu stellen.

die Patchstellen, die rejects gaben fügen fast alle nur an gewissen Stellen etwas hinzu, ich hab die Stellen einfach nach bestem Gewissen von Hand gesucht und (eigentlich) auch gefunden und dann den gleichen block nach patchvorschrift eingefügt...

Nach meinem ersten Test funktioniert also SOFT-OSD in der Kombination:
a) vdr-1.7.4 + osdbase.diff
b) xineliboutput cvs (30.03.2009) + Patch hier im anhang

mit der aktuellen xineliboutput-cvs von heute (30.03.2009) hab ich Probleme mit VDR 1.7.0, daher hier auch nicht wirklich weiter getestet, da funktioniert aber hier:
a) vdr-1.7.0 + osdbase.diff
b) xineliboutput-1.0.4 + xineliboutput-1.0.3-softosd-0.0.3.diff

Lange Rede kurzer Sinn: probiert's aus

Hallo zulu,

zuerst wollt ich nur mal DANKE sagen

Hab deinen auf der ersten Seite verlinkten Patch:
vdr-1.7.0-ext-h264-s2_dvbdevice-fix.diff

nun in meine easyVDR VDR 1.7.0 sources eingebaut und es funktioniert hier nach ersten Tests prächtig.

Die getesteten DVB-S Karten werden wie gewünscht nicht länger als DVB-S2 Karten erkannt, sondern als DVB-S.

Gibt es irgend einen guten Grund, nun nochmals auf deine neue Version:
vdr-1.7.0-ext-h264_s2ng.diff

zu ändern? Ich konnte mit der ersten Variante oben bisher keinerlei Probleme feststellen. Der vdr-1.7.0-ext-h264_s2ng.diff sieht für mich eher auf den ersten Blick so aus, als ob du dort nur diese 2 Patches gemerged hast:

vdr-1.7.0-ext-h264_s2.diff
vdr-1.7.0-ext-h264-s2_dvbdevice-fix.diff

Oder bringen die angesprochenen Änderungen mit der Übernahme von channels.c+h usw. aus dem VDR 1.7.4 sinnvolle Verbesserungen?

Ansonsten würd ich nämlich einfach bis zu deinem (hoffentlich) nächsten EXTP-Stand warten

Viele Grüße & nochmals DANKE

Hallo Leute,

wollte nur DANKE@Nano sagen !!!!

der dvbloop-s2api-0.2 patch funktioniert hier mit dem s2-liplianin & 2.6.28

saubere Arbeit

grüße

Hallo ihr,

Zitat

wenn hier was kommen würde bzw. wenn real_schorsch hier helfen könnte dann hätte man ja mal eine Chance

Hmm.. also so wie ich das sehe, fehlt doch gar nicht mehr viel....
Wir haben doch nun festgestellt:

a) das dvbloop-s2api hier braucht Anpassungen wegen dem Kernel 2.6.28
b) das dvbloop-s2api hier ist (wenn auch auf S2API angepasst) auf einen etwas anderen v4l abgestimmt als er im 2.6.28 steckt
(stichwort: inkompatilität des dvb-core moduls). ob das ding nun nen eigenen dvb-core baut oder nicht wäre ja letztlich wurscht, solange das gebaute dvb-core modul kompatibel/das gleiche zum 2.6.28 dvb-core wäre...

Nun zu a)
das wäre ja inzwischen schon besprochen/gefixed hier. die nötigen änderungen sind gepostet....

Was fehlt ist b), also die Kompatibilität zum restlichen v4l-Treiber, so wie er im 2.6.28 ist... da das Paket hier schon auf die S2API abgestimmt ist, kann da doch nicht so viel zu drehen sein? Maximal ein Einbau der Änderungen von ein paar Wochen HG-Stand...?

Aber sorry, stecke nicht tief genug in der dvbloop&v4l Materie um hier weiter helfen zu können

Ich würde jedenfalls mögliche Integrationspatches in den 2.6.28 v4l hier sofort testen

grüße

Zitat

Ich bin gerade dabei dvbloop mit den hier vorgeschlagegen Änderungen (class etc) in den aktuellen dvb-tree zu mergen und erstelle dann nachher mal ein diff... Edit: dvblo: dvblo_init(): successfully initialized DVB Loopback Adapter Version 0.9.4-s2api diff kommt gleich

Das klingt vielversprechend
diff her

Hallo ihr,

ich häng gerade an der gleichen Stelle.
2.6.28 und dieses dvbloop-s2api Paket....

Genauer beim compilen an der "dvblo_char.c"

Leider komm ich auch nicht ganz durch, aber evtl. kann ich noch was beisteuern...

a)

Zitat

dvblo_char.c:31:27: error: asm/semaphore.h: No such file or directory

Konnte ich auch wie glaub bereits hier angesprochen wurde beheben, indem ich den include von <asm/semaphore.h> geändert hab in <linux/semaphore.h>, dort liegt die Datei nämlich wohl in neuren Kerneln.. (?)

b)

Zitat

dvblo_char.c:116: error: array type has incomplete element type
dvblo_char.c:723: error: implicit declaration of function 'class_device_remove_file
dvblo_char.c:729: error: implicit declaration of function 'class_device_destroy'
dvblo_char.c:793: error: implicit declaration of function 'class_device_create' dvblo_char.c:813: error: implicit declaration of function 'class_device_create_file'

Bei den Fehlern hat mir geholfen:
http://www.mail-archive.com/da…incidsp.com/msg06415.html

Zwar ein ganz andres Modul, passt allerdings sehr gut. Liegt wohl an einer Änderung im Kernel von 2.6.25 --> 2.6.26. Lässt sich "beheben" so wie die Quelle angibt, in dem überall das "class_"-prefix entfernt wird, danach gibt's bei mir nur noch warnings (ob das korrekt ist/sauber geht, keine ahnung)
Auf Grund der Angaben dort würd ich aber fast sagen, dieses dvbloop-s2api Paket hier mag mit nix über 2.6.25.X aktuell?

c)

Zitat

dvblo_char.c:136: error: dereferencing pointer to incomplete type
dvblo_char.c:195: error: dereferencing pointer to incomplete type

Bei den beiden häng ich im Moment leider ...

edit, eine kleine weitere ergänzung:
zumindest scheint c) die letzte problematische Stelle zu sein, wenn man das ganze an den 2 verbleibenden fehlerstellen"dirty" fixed: (achtung, das folgende macht keinen sinn!)

Zitat

ssize_t rv = SUCCESS, minor = 0/*MINOR (dev->devt)*/;

dann compiled der Rest des modules durch, allerdings gibt ein insmod dvbloop.ko dann:

Zitat

dvbloop: disagrees about version of symbol dvb_dmxdev_init
[10521.176443] dvbloop: Unknown symbol dvb_dmxdev_init
[10521.176762] dvbloop: disagrees about version of symbol dvb_register_adapter
[10521.176763] dvbloop: Unknown symbol dvb_register_adapter
[10521.177225] dvbloop: disagrees about version of symbol dvb_unregister_device
[10521.177226] dvbloop: Unknown symbol dvb_unregister_device
... gekürzt ...

Alles anzeigen

ich kapier nicht so ganz, warum ein eigenes dvb-core.ko modul miterstellt wird, das ganze ist wohl im gegensatz zum original dvbloop als "standalone/mini v4l-treiber" gedacht?

wenn ich zumindest mein kerneleigenes dvb-core rausnehme und das mitcompilierte dafür rein, dann will auch der dvbloop treiber fehlerfrei modproben, unnötig zu erwähnen, dass dann aber der rest des v4l, der im 2.6.28 drinsteckt (sämtliche andere tv-karten) nicht mehr funktionieren mit diesem vom dvbloop neuerstellen dvb-core.ko

grüße

Hallo faup,

danke für die tolle Anleitung, lief hier auf einer Lenny/Sid i386 Testinstallation mit dem VDR 1.7.0 auf Anhieb!

Zumindest die fast exakt gleichmäßige Kernauslastung auf dem overclocked (4x 3,17Ghz) QuadCore hier ist beeindruckend, wenn man ffmpeg gewöhnt ist!

Allerdings läuft das Bild leider auch nicht 100% ruckelfrei, obwohl alle 4 Kerne zwischen 10% - 40% rumhängen. (bei ffmpeg ist einer zwischen 40-100% und es ruckelt bei 100% manchmal auch).

Zwischendrin "haken" die Bewegungen innerhalb des Bildes oder das Bild friert gelegentlich ganz ein für kurze Zeit.
Ursachen kann man nur mutmaßen, ob das nun daran liegt, dass es sich eigentlich um einen Windows-Codec handelt, dass die Verteilung auf 4 Kerne "zu" multithreaded ist, der CodecAVC selber noch verbesserungswürdig ist usw...

Außerdem funktioniert das auf der Testinstallation hier nur gut mit "vdr-xine",sprich dem "xine" plugin, welches dann direkt aus der "xine-ui" gestartet wird. (siehe deine Anleitung).

Das "xineliboutput" plugin (starten über vdr-sxfe) stürzt nach kurzer Zeit nach dem Umschalten auf nen HD-Sender ab mit einigen "fifo buffer full" Meldungen. Ich schätze hier dauert es einfach zu lange, bis dekodierte Daten kommen (das dauert nämlich zieeemlich lange). Evtl. lässt sich hier auch was an der Buffergröße drehn.

Zu guter letzt habe ich aber mit dem "xine"-Plugin einen kleinen grünen Rand an der unteren Kante des Bildes, das stürzt jedoch in keinem Fall ab und funktioniert soweit ordentlich.

Fazit: Das Ganze läuft bei mir irgendwie "anders" als ffmpeg, aber nicht wirklich besser. Für Leute, bei denen ein einzelner Kern unter ffmpeg momentan bei weitem zu schwach für HDTV ist, evtl. eine lohnende Alternative.

Werde mir jetzt noch die Sache mit dem Deinterlacer anschaun. Auf den ersten Blick macht das CoreAVC das Deinterlacing ja selber, zumindest seh ich bei deaktiviertem TvTime deinterlacer auf 1080i nix interlaced.... oder?

grüße,
cyberjunk

Ha! Nun habe ich mein Problem gelöst...

wie? ich hab mir eine tt-budget S2-3200 gekauft und die HVR-4000 rausgeschmissen
die S2-3200 läuft in der Kiste problemlos.

Ich kann also in Anbetracht der Unmengen Zeit und verschiedenen Dinge, die ich probiert hab, jedem nur empfehlen, falls er die Meldung kriegt: Karte tauschen!

Alles andere macht euch verrückt

Das soll übrigens nich heißen, dass die Nova-HD-S2/HVR-4000 schlecht ist. Die läuft hier in anderen PCs problemlos... und die Umschaltzeiten sind etwas besser als bei der S2-3200 (vielleicht wird mir das auf diesem Board zum Verhängnis).

grüße

Also, da ich so schnell noch nicht aufgeben wollte und mich mal weiter intensiv auf Ursachenforschung begeben hab, gibt's folgende neue Fakten zu berichten:

a) Ursache des Problems ist eindeutig das Umschalten des Senders, dabei nach erstem Stand auch NUR durch Umschalten auf einen ANDEREN Transponder. Solange ein Sender bleibt passiert dieser "Fehler" nicht... taucht er allerdings auf, löst er sich nicht von alleine.

b) In den Bildfehlern/Artefakten, die Folge der Fehlermeldungen sind, kann man eindeutig Teile des Bildes des letzten Senders vorm Umschalten erkennen. Das passt finde ich sehr gut zu der von mir ebenfalls geposteten Meldung:

cx88_wakeup: 2 buffers handled (should be 1)

Zur Erinnerung: Tritt diese Meldung auf, entstehen die Fehler im Gegensatz zur "pci_abort" Meldung nicht, es scheint als hätte sich das System "gerade noch gefangen"...

c) So wie dieses Problem urplötzlich, aber definitiv irgendwann im Betrieb durch Umschalten auf einen anderen Transponder entstehen kann, so lässt es sich ebenfalls durch vehementes Umschalten auf andere Transponder beseitigen... (kann unter Umständen genausoviele "Versuche" brauchen, wie um es zu erzeugen, ist also definitiv kein "workaround"

ergänzung: am besten reproduzieren lässt sich das problem bei mir auf diesem system durch kurzes "festklemmen" der kanal+/- taste... sowohl zum erzeugen als auch zum "beheben" des problems ...

Nach diesen Erkenntnissen bin ich mir nicht mehr so sicher, ob es wirklich ausschließlich am verwendeten Mainboard liegt. Ich denke das Ganze könnte zumindest mit Anpassungen am Treiber gefixed werden(?) ....

tadi

Das klingt ja generell mal vielversprechend

Ich muss gestehen, ich habe die aufnahme-streamfunktion der webinterfaces bisher nicht genutzt, die einzige sinnvolle Verwendung hätte für mich darin bestanden, die Aufnahmen doch per streamdev-plugin abzuspielen, um sie z.B. mit dem bereits integrierten mechanismus live umcodieren zu können (wie den Live-TV stream) und mir so zwischendrin in langweiligen Vorlesungen die Zeit zu vertreiben

Wenn die Aufnahme jedoch "normal" als File per HTTP angefordert wird, wird das mit dem live-umcodieren der aufnahmen wohl auch nicht klappen, zumindest fehlt dann die vom streamdev implementierte logik dahinter....

allerdings sollte das http-header field "content-length" dann ja wohl standardmäßig mitgesendet werden, bleibt die Frage, was das VLC-Plugin daraus macht (scheint ja nach deinen berichten nun zu funktionieren...).

Nochmal: Mir geht es eigentlich nur um die Möglichkeit per Webinterface in Aufnahmen hin und her zu spulen und VDR kompatible Schnittmarken zu setzen.
Alles andere (liveStream, Aufnahmen streamen) funktioniert mit genügend vorhandenne Varianten für mich gut genug

(tv livestream --> streamdev, aufnahmen --> samba)

freut mich jedenfalls, dass die sache noch nicht ganz in vergessenheit geraten ist und dann werd ich mal abwarten bis zum frühjahr, was sich bis dahin so getan hat

grüße

Nun ist ja schon etwas Zeit vergangen.... und ich würde gerne mal wissen, ob sich irgendwas in der Sache getan hat?

Vorzugweise geht es mir immernoch um die Funktion Aufnahmen bequem per Webinterface schneiden zu können, bzw. sie abzuspielen zu können und an gewissen Stellen dann Schnittmarken setzen zu können (das Schneiden ist ja das kleinste Problem).

Dazu ist mir beim nochmaligen Durchlesen folgendes Statement aufgefallen:

Zitat

Ja und genau bei dieser Information scheitert es noch bei mir mit dem VLC-Plugin. Ich bekomme weder eine Zeit (wie weit in der Aufnahme schon abgespielt wurde) noch eine Gesamtdauer/Größe vom VLC Plugin gemeldet, obwohl die Javascript API des Plugins diese Werte bereit stellen würde. Bei mir kommt immer 0 als Rückgabewert. Vielleicht mache ich da noch was falsch, aber ich werde noch nicht so leicht aufgeben auch wenn ich momentan nicht meine volle Aufmerksamkeit diesem Thema widme...

Also den Fall, dass die JS-API keinen aktuellen Zeitpunkt innerhalb der Aufnahme anzeigt und auch keine restliche Länge, den krieg ich nur, wenn ich Streams abspiel (also Live-TV und natürlich auch die Aufnahmen gestreamed!). Das er bei einem HTTP-Stream keinen Zeitpunkt/Restlänge anzeigt ist eigentlich klar.... bei Live-TV schlicht weil es kein "absehbares Ende" gibt. Bei Aufnahmen müsste es ja prinzipiell machbar sein die "Contentlänge" des HTTP-response mitanzugeben. (ich gehe mal davon aus, dass das streamdev-plugin dies einfach nicht tut, da es ursprünglich für live-tv streamen gedacht war? bzw. evtl. das vlc plugin bei http streams einfach von sich aus keine länge anzeigt, obwohl die länge des http response evtl. sogar mitgeliefert wurde....? )

Wenn ich die Aufnahmen allerdings als File per z.B. Samba-Mount direkt abspiele, dann sind diese Informationen sehr wohl enthalten und abrufbar (das plugin kann ja das ganze file analysierne, bzw. dessen länge bestimmen)!

Ich träume immernoch von einer web-basierten Schneidefunktion....

grüße

Ich hab 2 HVR4000 hier... ist beidesmal das gleiche Problem

Ich habe auch einen VDR auf einem Asus A8N-SLI (älter, nvidia chipsatz) mit den HVR4000s wunderbar OHNE diese Fehler am laufen...

hier ist eines der Postings, die sich bei google zum stichwort "pci_abort" und meinen dmesg meldungen finden lassen (das thema ist schon öfters aufgetaucht):
http://lkml.org/lkml/2007/10/4/252

obwohl das mainboard älter und deutlich verschieden von meinem "problemboard" ist, so ist mir doch folgender dort geposteter eintrag ins auge gefallen:

PCI bridge: Intel Corporation 82801 PCI Bridge

Genau dieses Gerät habe auch ich in der lspci Ausgabe !!
Vielleicht ein Ansatzpunkt? Bei Zeiten werde ich mal die übrigen threads dies im internet so dazu gibt durchforsten, ob noch mehr verschiedene boards mit dieser pci-bridge evtl. genannt werden?

Oder kann jemand Gegenteiliges behaupten?
Hat jemand ein P43 Chipsatzboard mit einer HVR-4000 am laufen?
Oder sogar jemand eine HVR4000 auf ienem System mit oben genannter PCI-Bridge?

*nach oben schieb*

Also ich bin immernoch an der Sache dran, inzwischen habe ich noch:

1) Eine neuere HVR-4000 Firmware probiert
2) Den aktuellen dev. Kernel (2.6.27 rc5)

nachdem beides keine veränderung brachte, hab ich angefangen das Problem nochmals grundlegend zu analysieren, dabei sind mir 2 dinge aufgefallen.

Solange das Problem noch nicht auftritt, finde ich gelegentliche:
cx88_wakeup: 2 buffers handled (should be 1)

Meldungen im dmesg. Scheint als ob dies, so eine Art "vorfehler" ist, der macht sich aber lange nicht so stark qualitativ bemerkbar, wie der pci_abort.

Diese Meldung taucht dann aber, sobald die "richtige" pci_abort fehlermeldung kommt, nicht mehr auf.

außerdem habe ich noch wahlweise mit setpci manuell an der latency der karte rumgespielt (alles von 0 --> ff (hex) getestet).

Dabei scheint:
Je geringer der latency Wert ist, desto höher frequent wiederholt sich die Meldung und desto stärker sind die Bildfehler. Je höher der Wert ist, desto seltener wiederholen sich die Fehlermeldung und die Bildfehler.
Beides ändert aber nichts an der Tatsache dass,

a) es unakzeptabel für den produktiveinsatz ist
b) beidesmal tritt diese nervige meldung irgendwann eben auf

Hat denn niemand einen Ansatzpunkt für mich .... ?

Inzwischen habe ich übrigens noch etwas weiter getestet, u.a. den alternativen Multiproto treiber von:
http://liplianindvb.sourceforg…gwebdir.cgi/liplianindvb/

in Zusammenhang mit dem frisch-freigegebenen 2.6.26er Kernel...
leider keine Veränderung

Zusätzlich noch einen RAM-Test gemacht -> auch alles ok.

Da ich wie gesagt die HVR-4000 schon mit mehr als 3 anderen Boards bei Bekannten problemlos am Laufen habe, denke ich das Problem liegt klar am Board

Bleibt die Frage:
Möglicherweise ein allgemeines Problem des Chipsatzes (P43/ICH10R) mit der HVR-4000, oder einfach nur Schlamperrei bei dem Mainboard?
(Ich verweise nochmal auf den Fakt, dass seit Markteinführung des Mainboards etwa 14-tägig neue BIOS-Versionen erscheinen....)

Hat denn schon evtl. irgendwer eine HVR-4000/Nova-HD-S2 auf einem Mainboard mit gleichem Chipsatz problemlos am Laufen? (denke gerade über alternativ-mainboards nach...)

Monroe
oehm, das ist mir schon klar, das wollte ich mit folgendem satz ausdrücken:
"die wetterkarte kann nicht mehr über die urls geladen werden" <-> "die urls sind falsch"

frage war eher:
hat schon wer wer neue / abgeänderte / korrekte urls für wetterkarte/nord-süd usw. gefunden? in meinem script sind auch diverse auskommentierte zeilen, scheint als ob die quellen schon ein paar mal geändert werden mussten ....

Hallo zusammen,

ich habe aktuell folgendes Testsystem hier:

Gigabyte EP43-DS3 Mainboard (P43 + ICH10R Chipsatz)
mit einem Intel Quadcore drauf, sowie einer HVR-4000 (DVB-S2).

Nun habe ich schon mehr als 3 HDTV Systeme mit HVR-4000 eingerichtet und hatte bisher nie Probleme, leider erhalte ich aber mit diesem Board, im dmesg Log folgende nervige Fehler (Multiproto-Treiber):

cx88[0]: irq mpeg [0x80000] pci_abort*
cx88[0]/2-mpeg: general errors: 0x00080000

Das ganze zeigt sich als Artefakte wie man sie von schlechtem Empfang her kennt im Bild, bis hin zu Stand-/Ruckelbild, abhängig wie oft sich dieses Meldung im Log wiederholt. Leider habe ich inzwischen absolut keinen Anhaltspunkt mehr, was ich noch tun könnte, folgendes habe ich bereits probiert:

- Bios update auf aktuellste verfügbare Version (18.08.2008)
- Durchtesten aller 4 verfügbaren PCI-Slots ( bei den unteren beiden, 3+4 taucht diese Meldung praktisch sofort auf, in den Slots 1+2 meist erst nach einer Weile, vorzüglich nach dem Umschalten)
- Diverse Kernelversionen (2.6.22.15, 2.6.24.5, 2.6.25.16) in Zusammenhang mit verschiedene Distributionen (64-bit LennyBeta2, 32-bit easyVDR)
- Manuelle IRQ zuweisung für die Karte / BIOS-Einstellungen
- Deaktiviern möglichst sämtlicher sonstiger hardware im BIOS
- Verschiedene Kernel Paramter (acpi=off, pci=routeirq, apic=off usw..)

Taucht diese Meldung erst einmal im Log auf, geht sie auch nicht mehr weg, genauso wie die Bildfehler. Dann hilft nur noch ein Entladen & Neuladen des Treibers.

Hat denn vielleicht noch irgendwer einen Tipp für mich?
Einen Anhaltspunkt? Bei google finden sich nur Leute mit dem gleichen Problem, ich find aber keine Lösungansätze

grüße

PS: Eine tt-budget 1500 statt der HVR-4000 funktioniert mit gleichem multiproto Treiber/Installation in allen PCI-Slots fehlerfrei