Das sind zumindest Auffälligkeiten im TS-Strom. Continuity offset weist darauf hin, dass die TS-Pakete nicht aufsteigend durchnummeriert sind, was normalerweise als Hinweis gezählt wird, dass Pakete verloren gegangen sind, und Unexpected NALU fill data überprüft, ob die Fülldaten auch schön brav 0xFF Bytes sind, wie vorgeschrieben. Hier sind durch das Weglassen von TS-Paketen wohl Nutzdaten in den Fill-Block gerutscht, naludump bricht dann sofort das dumpen dieses Fill-Blocks ab.
Gruß,
Udo
Etwas spät, aber zwei Dinge noch zur Ergänzug:
--numeric-owner schadet nicht. Nützlich ist es aber insbesondere, wenn man eine Sicherung in eine tar-Datei macht, und diese später von einem anderen System (z.B. Live-CD) zurück spielen will. Ohne den Switch versucht tar, die Benutzernamen an die des laufenden Systems anzupassen.
Das | (cd Ziel ; tar ...) kann man sich sparen, dafür gibts | tar -C Ziel ...
Gruß,
Udo
Generell kann erst mal jedes Vorkommen von PrimaryLimit durch 0 ersetzt werden, nichts anderes ist in VDR passiert.
Streamdev-Patch und epgsearch-Patch im Anhang.
Außerdem: Experimenteller Patch für osdteletext, nutzt das neue Verhalten von MsgChannelSwitch.
Gruß,
Udo
Ein Veranstaltungsort, der mal mehr als 50km von einer deutschen Grenze weg liegt, wäre zwar auch mal eine nette Abwechselung, aber beide Orte sind mir immer noch lieber, als gar kein Camp!
Auch wenn letztes mal die 8 Stunden Heimfahrt echt keinen Spaß gemacht haben, verpassen wollte ich es trotzdem nicht.
Gruß,
Udo
Hier ist der vor einiger Zeit versprochene patch fuer das dvbhddevice-Plugin zur Konfiguration des Ein- und Ausschaltens des Fernsehers ueber CEC.
Hab nur mal kurz über den Patch drübergeschaut, ich bin selbst auch ganz ohne CEC glücklich. Ich würde aber dennoch als Verbesserung vorschlagen, in MainThreadHook auf Veränderung des Ergebnisses von ShutdownHandler.IsUserInactive() zu pollen, und ggf. InitCec aufzurufen. Zumindest wenn der VDR für einen Timer aufgewacht ist, würde der Fernseher dann auf VDR-Tastendruck angehen, eventuell kriegt man ihn sogar dazu, bei der Meldung "VDR schaltet später aus" den Fernseher abzuschalten.
Gruß,
Udo
Technisch möglich ist viel, die ganz durchgedrehten kommen schon nahe an 8W Idle heran. Allerdings sind dafür reichlich Kompromisse unvermeidbar. Rekorde kann man da nur mit SSD-Disk, abgeschaltetem Monitor, nur 1 Speicherriegel, DC-Wandler-Netzteil und allen Onboard-Komponenten deaktiviert erreichen. Führend sind immer noch AMD E350 (Zacate) Systeme, allerdings nur mit sehr sparsamen Mainboards, der Prozessor selbst braucht idle fast nichts. Um so mehr entscheidet das drumherum den Speicherbedarf.
Will man noch nen Sat-Empfänger und ne hardwarebeschleunigte Videowiedergabe dazu haben, kann man sich von den Leistungsdaten auch gleich wieder verabschieden.
Gruß,
Udo
grep: ./PLUGINS/src/xvdr/Makefile: Datei oder Verzeichnis nicht gefunden
ERROR: plugin xvdr doesn't honor APIVERSION - not compiled!
VDR sucht nach der Unterstützung für APIVERSION seit 1.3.48, und untersucht dafür das Makefile - die auch für das gesamte Übersetzen zuständig ist. Ein Plugin ohne Makefile kann VDR nicht übersetzen. Die Frage ist also, warum gibt es die Datei PLUGINS/src/xvdr/Makefile nicht, wo ist sie stattdessen, bzw. wo soll sie herkommen. Kontrollier nochmal, dass die Quelltexte richtig entpackt sind, und les noch mal alle READMEs und INSTALLs.
Gruß,
Udo
Der OSD-Fehler ist auch noch vorhanden. Ich habe das Gefühl, dass wenn viel los ist im OSD, z.B. Meldungen vom VDR und gleichzeitiges bedienen mitt Menü, OK oder Exit, dass dann das OSD verschwindet. Bedienen kann man alles noch - nur halt ohne Anzeige. Im Log steht wie immer nichts was auf einen Fehler hindeutet.
Verwendest du einen speziellen Skin? Wenn ja, kannst du vorübergehend auf TNG-Skin wechseln, ob das Problem da auch auftritt? Wenn es ein Überlastungs-Problem ist, könnte die Komplexität des OSD einen Einfluss haben.
Gruß,
Udo
Etwas wie eine libdvb wäre eine universelle Möglichkeit, aber so etwas gibt es halt derzeit nicht.
Warum es keine libdvb gibt, das frage ich mich auch schon lange. So eine lib könnte problemlos die Unterschiede der verschiedenen DVB API Versionen verstecken, und wäre leichter zu aktualisieren, als immer die zum Programm passende Kernelversion einzusetzen. Von Anbindungen an udev mal ganz abgesehen.
Ich antworte mir dann mal selbst. Wer nicht unbedingt auf DVBAPI 3 zurückgestuft werden möchte (Urig's Patch), kann den angehängten Patch nehmen. Funktioniert mit DVBAPI 5.2 pefekt.
Wie du schon bemerkt hast, geht es nur mit dem Header auch. Viel mehr, als die fehlenden Teile des Headers zu ergänzen, macht der Patch ja auch nicht.
Deswegen muss ich auch dem 'zurückgestuft' widersprechen: Mit Patch bleibt die komplette Funktionalität von V5.3 erhalten. Auch meine TT-6400 läuft mit dem Patch, und sie würde sogar noch laufen, wenn ich gegen DVBv3-Header übersetzt hätte - passenden Kernel vorausgesetzt.
Gruß,
Udo
Also ich verwende hier openSUSE 11.4 mit Kernel 2.6.37.6.
Man muß also nicht gleich kernelmäßig auf Linux-3.0 wechseln.
Aber zumindest auf aktuelle DVB-Treiber. Ok, Powarman hat just-in-time auch die 5.3 API in seinen Treiber aufgenommen. Den verwende ich zusammen mit 2.6.32.
Aber mein build-pc (VM) läuft mit dem originalen Debian 2.6.32 Kernel, und dabei soll es auch bleiben. Und nicht jeder hat die allerneueste Hardware, und braucht dafür die allerneuesten DVB-Treiber. Es soll auch DVB-Hardware geben, die von älteren Kerneln voll unterstützt wird...
Was spricht denn dagegen den Patch von Urig mit in den VDR zu übernehmen?
Ich hab kein Problem damit, dass das ein Patch ist. VDR - insbesondere die Entwicklerversionen - sollten sich nach vorne orientieren, und nicht Kompatibilität für uralte APIs mitschleppen. Der Patch beinhaltet noch immer die Unterstützung für DVB V3 API, und das ist wirklich schon aus jeder Distribution verschwunden...
Wieso müsste hierfür denn VDR von libudev "abhängig" sein?
Ich dachte, mit UDEV-Regeln wird bestimmt, in welcher Reihenfolge die Devices erzeugt werden. VDR benutzt sie halt dann in der vorgefundenen Reihenfolge (ohne irgend etwas von "UDEV" zu wissen).
Das ist eins der Probleme: udev benennt nur die Devices um, ändert aber nicht die eigentliche Device-Nummer. Da VDR aber über die Device-Nummer unter /sys nachschlägt, geht das dann schief, wenn /dev/dvb/adapterX nicht mehr zu /sys/class/dvb/dvbX passt. Udev-Regeln funktionieren daher nicht.
Alternativ könnte man entweder VDR beibringen, symlinks zu interpretieren, z.b. /dev/dvb/primary -> /dev/dvb/adapter2 zu verfolgen, oder die Device-Nummer aus der device node Nummer zu interpretieren, was aber auch gewagt ist.
Gruß,
Udo
Für diese Anwendung kennt printf (zumindest in der Bash) den Parameter %q:
#>test=$(printf "ls -l %q" "te st");eval "$test"
ls: Zugriff auf te st nicht möglich: Datei oder Verzeichnis nicht gefunden
Dabei wird allerdings mit \ gequotet, was aber auf das gleiche hinausläuft:
#>printf "ls -l %q" "te st"
ls -l te\ st
Die Lösung hat den Vorteil, dass sie auch alles andere richtig quoten kann, nicht nur Leerzeichen.
Gruß,
Udo
Ich hab den alten S2API-Wrapper aufgefrischt, damit er DVB API 5.3 emulieren kann, damit kann man wieder einen lauffähigen VDR übersetzen, ohne auf Linux-3.0 upgraden zu müssen. Der neue Patch läuft auf allen DVB-Headern von API 3.0 bis API 5.3, und rüstet jeweils genau die fehlenden Funktionen nach. Gestartet auf einem neueren Kernel sollten auch alle neueren Funktionen zur Verfügung stehen.
http://www.udo-richter.de/vdr/patches.html#dvb-api-wrapper
Und da dachte ich, ich könnte den Patch mal endgültig beerdigen... yay...
<edit> Jetzt werde ich schon von meinen eigenen Beiträgen überholt... der ist ja noch nichtmal wieder zurück in meiner Inbox gewesen... </edit>
Gruß,
Udo
Der Bandwidth-Limit Patch begrenzt die Wiedergabe-Bandbreite, wenn Daten gleichzeitig über die FF aufgenommen werden. Dazu werden erst nur I-Frames, dann nur noch Audio ausgegeben. So lange nichts aufgenommen wird, verhält sich der Patch neutral.
Der Patch war (ist) bei mir noch aktiv, allerdings ist der alte VDR seit Ostern nur noch Reserve. Es gibt auch ein bekanntes Problem, dass bei reiner Wiedergabe irgendwann der EPG-Scan die FF-Karte benutzt, und so eine Bandbreitendrosselung auslösen kann. Warum VDR überhaupt die FF für EPG-Scan verwendet, statt der freien Budget, ist mir schleierhaft. Jedenfalls hab ich den Patch öfters ein- und ausgeschaltet.
Abgesehen von der 1.6er-Version des Patches habe ich auch eine Version für 1.7.16+ und eine für 1.7.21+, falls jemand Interesse hat. Mangels allgemeinen Interesses habe ich die nicht mehr veröffentlicht.
Gruß,
Udo
Ohne dich demotivieren zu wollen: Aktuelle VDR-Versionen schließen von der /dev/dvbX Nummer zurück auf den Pfad unter /sys/class/dvb/dvbX, und den kannst du nicht zusammen mit der udev-Regel ändern...
Gruß,
Udo
Macht der VDR nicht sowieso für die Inaktivitätstimer einen educated guess ob er vom Nutzer oder aufgrund eines Timers eingeschaltet wurde? Evtl. könnte man das auswerten...
Diese Information ist über ShutdownHandler.IsUserInactive() abfragbar. Startete der VDR für einen Timer, liefert die Funktion true zurück, sonst false. Betätigt man eine Taste auf der Fernbedienung, wechselt der Status auf false. Nach Ablauf der shutdown time, oder durch Betätigen der power-Taste bei laufender Aufnahme wechselt der Status wieder auf true. Das war von vornherein auch dafür gedacht, um z.B. Fernseher oder Videodekoder ausschalten zu können.
Das Problem der klebenden Schnittmarken scheint mit der neuen 0.3.5 Firmware vorerst gelöst zu sein.
Ich hab die Gelegenheit dann auch gleich mal genutzt, und habe versucht, einen Absturz durch schnelles Verschieben zu provozieren, ist mir aber erst mal nicht mehr gelungen!
Der Vollständigkeit halber: Ich hatte inzwischen wieder einen Hänger durch schnelles Schieben von Schnittmarken, das Problem ist also nicht ausgestanden.
Gruß,
Udo
Nach einer kleinen Cache-Bereinigung (vorübergehend browser.cache.check_doc_frequency=1) werden die first-new-posts jetzt als expired im Cache abgelegt, und jedes mal neu geladen. Das sollte also geholfen haben. Danke!
Gruß,
Udo
Der Patch wird von mir weiterhin gepflegt, und läuft zumindest bei mir ohne Störungen.
Übrigens, dieser Thread ist der ältere bis zur 0.0.1, das letzte Announce für 0.1.0 ist [ANNOUNCE] naludump-0.1 - NALU fill data Patch
Gruß,
Udo
Mit einer guten Mainboard-Lüfterregelung, durchaus möglich.
Ich hab nur Erfahrungen mit einem ähnlich 'abgemagerten' Celeron E3400 (Core 2) 2.6GHz, den ich mit Boxed-Lüfter betreibe. Direkt beim Booten dreht er kurz auf 100% hoch, da hört man ihn. Im normalen Betrieb hab ich ihn dagegen noch nie gehört, also ist er leiser, als meine WD Green (5400rpm) Platte.
Gruß,
Udo
Bei HD-Aufnahmen (ARD/ZDF) habe ich beobachtet, dass die Schnittmarken beim Verschieben an einer Sendungs-Grenze 'kleben bleiben':
Es gibt was Neues: http://www.aregel.de/vdr/39/neue-firmware-034-fuer-s2-6400
Das Problem der klebenden Schnittmarken scheint mit der neuen 0.3.5 Firmware vorerst gelöst zu sein.
Ich hab die Gelegenheit dann auch gleich mal genutzt, und habe versucht, einen Absturz durch schnelles Verschieben zu provozieren, ist mir aber erst mal nicht mehr gelungen! Also Bitte an Alle: Neue Firmware aufspielen, beim Schnittmarken schieben wieder rücksichtslos sein, und eventuelle Abstürze melden!
Gruß,
Udo
PS: Und Danke an Powarman für das Weihnachtsgeschenk!
Technisch ist das nahezu unmöglich. Mal abgesehen von der fehlenden Bandbreite, können PCI-Karten direkt per DMA auf die ersten 4GB des Arbeitsspeichers zugreifen und sich in den Arbeitsspeicher einblenden, wohingegen USB-Geräte ohne Hilfe des PC gar nichts machen können - sie müssen warten, bis der PC nach eventuellen Wünschen fragt (Polling).
Die meisten PCI-Karten blenden dann auch gleich ihre Register direkt im Arbeitsspeicher ein, wo die Treiber direkt zugreifen können. Und da wird aus einem CPU-liest-Register, was in ein paar Bustakten erledigt ist, eine längere Kette: Der Registerzugriff muss vom USB-PCI-Treiber virtualisiert werden, als USB-Kommando an den externen Controller gesendet werden, auf eine Antwort gepollt werden, und als virtualisierte Register-Leseoperation dem anderen Treiber wieder untergeschoben werden. Das ganze ähnelt dem Xen PCI passthrough, allerdings ohne Hardwareunterstützung und ohne Paravirtualisierung...
Gruß,
Udo
