Die PTS Werte in den Dateien werden nicht zusammen passen.
Dieses Zusammenschneiden ist in der "neuen" Schnittfunktion des VDR explizit vorgesehen. Wenn man exakt die Ueberlappung der beiden Teile rausschneidet (Schnittmarken auf dem selben I-Frame) passt der resultierende TS-Strom exakt und ist nicht von einer durchgaengigen Aufnahme zu unterscheiden.
Gruss,
S:oren
@Sören: bei deinem Wunsch würden aber einige Infos auf der Strecke bleiben müssen. Wie wilst du denn in einen schmalen Menüpunkt, der so niedrig ist, dass ca. 20 Elemente auf eine Seite gehen, die ganzen Infos reinkriegen? Da würde dann maximal der Titel reingehen, und das fände ich ein bisschen dürftig...
Ja, einige Infos wuerden evt. auf der Strecke bleiben, aber in der breiten Ansicht mit 20 Zeilen ist bei mir die rechte Haelfte des Bildes sowieso leer. Die Infos der breiten Ansicht wuerden so also in eine schmale Ansicht reinpassen. Mit einem Icon am Zeilenanfang fuer den Timerstatus der Sendung (in Programme) oder dem neu/geschnitten-Status in Aufzeichnungen muesste es vom Platz her gehen.
Da würde der Vorschlag von Ofenheizer schon eher Sinn machen. Aber da müsste ich den kompletten Teil mit den Menüelementen ein zweites mal neu schreiben und dann wieder konditional benutzen, je nach Setup. Das wird mir dann auch irgendwann zu unübersichtlich.
Das verstehe ich. In der breiten Ansicht gibt es aber jetzt ja auch schon den grafischen Fortschrittsbalken in "Jetzt", ein aehnliches grafisches Element fuer den Timer-/Neu-Status koennte man evt. unterbringen - ich bin eben noch an skinelchi gewoehnt 
. Vielleicht ist es das, was Ofenheizer meint, keine "dritte" Ansicht. Faende ich auch gut, waere ja fast mein Wunsch, nur eben in voller Breite.
Mal schauen...vielleicht kommt sowas irgendwann nach der 1.0.0, aber in diese Version werde ich das definitiv nicht mehr mit einbauen.
Ich will auf keinen Fall draengeln. Vielleicht hat ja sonst noch jemand eine Idee, wie man mehr Eintraege uebersichtlich unterbringen kann...
Gruss,
S:oren
louis: Ich habe hier noch einen Wunsch, passend zum Thema, aber in eine ganz andere Richtung.
Das (der, die?) Skin sieht wirklich Klasse aus, insbesondere im Programme- und Aufzeichnungsmenue passen mir aber einfach zu wenige Eintraege auf eine Seite (so ~20 sollen es fuer mich sein). Deshalb habe ich schweren Herzens auf die breite Ansicht in diesen Menues umgestellt, die wirkt im Vergleich aber schon sehr altbacken. Deshalb mal die Frage: Waere es moeglich, fuer Programme und Aufzeichnungen eine einzeilige Darstellung (wie im breiten Menue), aber in schmal mit dem skalierten Fernsehbild daneben und Icons fuer Timer bzw. neu/geschnitten vorzusehen? Einen konkreten Patch/Designvorschlag habe ich leider nicht...
Gruss,
S:oren
Ich benutze die RSS Feeds im Skin selbst auch nicht mehr...war ein Schuss in den Ofen. Eigentlich sollte ich das komplett wieder rausnehmen und ein eigenes Mini Plugin draus machen.
Faende ich gut: weniger build-Abhaengigkeiten fuer skinnopacity...
Gruss,
S:oren
Das benoetigte Modul ist in der config nicht aktiviert. Wenn Du diesen Kernel verwenden willst, wirst Du um ein nachtraegliches Bauen von dvb_usb_dib0700 (und wahrscheinlich mt2266) nicht drumrum kommen...
Gruss,
S:oren
Ist der Stick so alt, dass er aus dem 3.9.5-Kernel geflogen ist?
Nein. Hast Du auch das Modul dvb_usb_dib0700 plus die automatisch ausgewaehlten Tuner/Demods mitgebaut?
Gruss,
S:oren
leider konnte ich in der letzten Zeit nicht mehr so intensiv testen.
Bei Dir ist ja soweit auch alles klar...
Mein Fazit bisher ist: alle phi_mode mit den phi_clk 0 und 1 sind bei mir uneingeschränkt einsetztbar, phi_clk 2 ist bei mir bei allen phi_mode mit sporadischen Fehlern (Menü, Bild und Reset) verbunden.
Ob phi_clk=2 noch funktioniert ist rein eine Eigenschaft des individuellen PCIe-Chips auf der Karte, hat nichts mit dem Treiber an sich oder dem FPGA zu tun. Bei dieser Einstellung wird zusaetzlich zu phi_clk=1 ein interner Takt in der Bridge erhoeht. Leider steht in dem mir vorliegenden Datenblatt der Bridge nur drin, wie man die Takte einstellt und was der Standardtakt ist, nicht welche Takte maximal zulaessig sind (da steht nur: kann auch mit mehr als dem Standardtakt funktionieren, tolle Aussage). Muss man also probieren, wenns nicht zuverlaessig laeuft, dann nicht benutzen.
Da sich mit Deiner neuen Firmware/Treiber-Kombination meine Kaltstartprobleme soweit erledigt haben, würde ich einen produktiven Einsatz befürworten.
Hoert sich sehr gut an. Am Treiberpatch wirds nicht liegen, kann aber schon sein, dass das neue FPGA-Design stabiler funktioniert. (kannst Du ggf. ja mal mit dem alten Treiber testen, das neue FPGA sollte auch damit funktionieren, nur eben nicht schneller, aber vielleicht trotzdem stabiler)
Wenn ich das richtig verstanden habe, sonst korrigiere mich bitte, bedeutet - kein Parameter = phi_moe 0 und phi_clk 0 - und das entspricht in etwa dem wie es vorher war. Also verhält es sich doch immer prinzipiell erst einmal so wie vorher.
Ja, ohne spezielle Parameter wird phi_mode=0, phi_clk=0 benutzt. Damit funktioniert alles aehnlich wie frueher, nur etwas schneller - Du hattest ja 13% zu 10% CPU-Last gemessen...
Gruss,
S:oren
Da es laenger keine Meldungen mehr gab, hier mal eine Zusammenfassung des aktuellen Standes.
Nach eigenen Messungen und Feedback von anderen Usern sieht es fuer mich so aus: Auf ARM und x86_64 funktionieren immer alle phi_mode-Werte, auf x86_32 haben CyberChris und PaulPanther mit phi_mode 3 bis 5 Bildstoerungen, die ich leider bei mir nicht nachvollziehen kann. Sowohl auf einem Via C7 als auch auf einem extra neu aufgebauten Testrechner mit Core-2-Duo sehe ich keinerlei Problem. Ich kann also nichts weiter testen, wenn jemand noch ein Problem hat und weitere Patches ausprobieren moechte, kann er mir gerne eine E-Mail schreiben...
Da es mit den Standardeinstellungen (phi_mode=0, phi_clk=0) keinerlei Stoerungen oder andere Verschlechterungen durch den Patch gibt, sehe ich diesen Entwicklungsstand hier erstmal als final an. Hoehere Werte fuer phi_mode und phi_clk sollte man eben nicht einstellen, wenn es damit Stoerungen gibt. Ansonsten sind Durchsatzsteigerungen ueber Faktor 4 moeglich, mit entsprechend geringerer CPU-Last. Das bringt natuerlich besonders bei Single-Core-CPUs Vorteile.
Ich bin mir aber trotzdem nicht sicher, ob der Patch in dieser Form mit den vielen Einstellmoeglichkeiten in den "offiziellen" Treiber uebernommen werden sollte...
Gruss,
S:oren
Klar mag dir das jetzt eher unsinnig erscheinen, aber was ist, wenn es in der VDR-Version 2.1.z eine Änderung am Plugin-API gibt, die auch das dvbhddevice-Plugin betrifft? Spätestens dann könnte das Plugin in VDR-Version 2.0.x nicht mehr die gleiche Versionsnummer haben wie in 2.1.x.
Das kann ich so nicht nachvollziehen. Nahezu jedes ausserhalb des vdr gepflegte Plugin wird 2.0 und 2.1 parallel unterstuetzen (hat ja mit 1.6 / 1.7 / 2.x auch funktioniert), freilich mit unschoenen #ifdef.
Glaub' mir, ich würde auch lieber nur an der Version 2.1.x arbeiten und die 2.0 einfach so lassen, wie sie ist. Aber Bugfixes müssen halt auch in einer stabilen Version sein.
Keine Frage. Aber was spricht dagegen, einfach bei jeder (veroffentlichten) Aenderung des Plugins die Versionsnummer hochzuzaehlen? Dann waere mir auch egal, ob 2.0 oder 2.1 davorsteht, solange es einheitlich ist. Der vdr hat ja diese strenge Trennung von stable/developer, bei Plugins ist das (nach meinem Eindruck) eher unueblich.
Aber ich will mich hier keinesfalls um die Strategie streiten, nur verstehen, wie es mit den Nummern gemeint ist. Das ist nun ja klar und absolut ok fuer mich, auch wenn ich eine einheitliche Plattform ohne forks besser gefunden haette.
Gruss,
S:oren
Alles, was in der Version 2.1.x "angefasst" wird, bekommt eine Versionsnummer, die mit 2.1 beginnt. Daß jetzt das dvbhddevice-Plugin zufällig 2.1.1 hat, so wie VDR selber, liegt halt daran, daß beide gleichzeitig erhöht wurden. Die nächste VDR Developer Version wird 2.1.2 heißen, und das dvbhddevice-Plugin wird dann weiterhin 2.1.1 haben - es sei denn, es wird darin auch wieder was geändert.
In der kommenden 2.0.3 Stable wird das dvbhddevice-Plugin die Versionsnummer 2.0.1 haben, weil es die erste Revision der Release 2.0 ist ;-).
Die Verwirrung hat also Methode? Wenn die italienischen und finnischen Uebersetzungen von 2.1.1 nach 2.0.3 uebernommen werden, dann bekommt dort das identische Plugin zu 2.1.1 die Nummer 2.0.2 (2.0.1 gibts schon)?
Aber da powarman die Versionsnummer nicht erhöht, muß ich das wohl tun...
Ich wollte ihm gerade einen entsprechenden Patch schicken, weiss aber nicht, welche Nummer nun die richtige ist...
Zur Klarstellung: Mir waere eine getrennte Pflege des Plugins fuer 2.0 und 2.1 durchaus recht (ich nutze da z.B. einen outputonly-Patch zum Strom-(Hitze-)Sparen, der in 2.0 ziemlich reingewuergt ist und mit einer potentiellen kleinen Aenderung am dvbdevice in 2.1.x elegant waere), aber das vertraegt sich ja nicht so recht mit einem einzelnen Referenzrepository. Und zum Ausgangsproblem: Dort kann es ja nur eine Versionsnummer geben (ich gehe mal davon aus, dass Andreas nicht mehrere Branches pflegen wird)...
Gruss,
S:oren
Mir ist gerade aufgefallen, dass sich die Versionsnummer des dvbhddevice-Plugins auch auf 2.1.1 geaendert hat. Wird die Version jetzt auch immer auf die vdr-Version angepasst, war das nicht nur fuer 2.0.0 geplant?
Die Nummern selbst sind mir eigentlich relativ egal, verwirrend ist jetzt nur, dass die Version im powarman-Repository deutlich niedriger ist, bei im Prinzip gleicher Codefunktionalitaet. Ist der VDR jetzt der Referenzcode fuer dieses Plugin, findet die Entwicklung jetzt hier statt?
Gruss,
S:oren
Muss im dvbhddevice noch etwas eingestellt sein/werden?
Nein.
Bei mir das gleiche mit den Bildfehlern
Ach verdammt!
Das ist eine AMD E-350 CPU, 2 logische Kerne. Ueberraschend niedrige CPU-Last fuer 12 MBit/s, wow!
Edit: Was ich vergessen hatte: x86_32 oder x64?
Im Moment habe ich keine Idee, wo die Bildfehler herkommen koennten. phi_mode 0 ist uebrigens auch eine sinnvolle Einstellung, entspricht etwa der bisherigen Treiber-/FPGA-Kombination (ist evt. ein klein wenig schneller).
Gruss,
S:oren
Ab phi_mode 3 habe ich Bildstörungen. phi_clk scheint keinen Einfluss zu haben. Die Umschaltung habe ich bei laufender Wiedergabe mittels echo x > /sys... ausgeführt.
Hm, schade. Was heisst "Bildstoerungen"? OSD kaputt, Video kaputt? Bloecke oder gar kein Bild? Mit und ohne OSD die gleichen Fehler?
phi_clk laesst sich _nicht_ mit der echo-Methode umschalten (siehe oben). Da sind hoehere Werte aber sowieso nur sinnvoll, wenn der entsprechende phi_mode mit phi_clk 0 funktioniert.
Wenn ich den Modulparameter in der modules.conf setzte kann der Treiber ab phi_mode 3 nicht sauber geladen werden. Mein Testsystem ist das System 2 aus meiner Signatur (ATOM D525 + NM10)
Was passiert, wenn der Treiber nicht richtig geladen wird? Irgendwas im Log?
Das ist ein Dual-Core-Atom ohne Hyperthreading? Laeuft der als x86_32 oder x64?
Gruss,
S:oren
Hat jemand einen Tipp für mich?
Der Patch ist gegen powarmans Repository, fuer UFOs build-System passt es nicht ganz direkt.
Probiers mal im media_build_experimental-Verzeichnis mit
patch -d linux/drivers/media/pci/ -p5 < path/to/patch/saa716x-phi-test2.diff
Gruss,
S:oren
Aufgefallen ist mir auch noch, das die neue Firmware/Treiberkombination recht sensibel auf Entladen und Neuladen der Treiber reagiert.
Das klappt manchmal nicht, obwohl vorher kein sichtbarer Fehler aufgetreten ist, die Wahrscheinlichkeit steigt dabei mit phi_clk.
Nochmal zur Klarstellung: der neue Treiberpatch sollte die Abhaengigkeit der Reset-Probleme von phi_clk beseitigen. Am generellen Verhalten habe ich nichts geaendert (ich nutze den Treiber ueblicherweise direkt im Kernel, nicht als Modul). Im Moment ist es also besser, neu zu booten als die saa716x-Module zu entladen und (ggf. mit anderen Parametern) ohne reboot neu zu laden.
Noch ein Trick: den phi_mode kann man online aendern, z.B.
echo 4 > /sys/module/saa716x_core/parameters/phi_modeMit phi_clk klappt das nicht, dieser Parameter wird nur beim Laden des Treibers ausgewertet!
Gruss,
S:oren
Vielen Dank erstmal fuer die bisherigen Tests.
Während der Wiedergabe und nach Ende wird das Menü verpixelt bis unleserlich oder gar nicht mehr angezeigt, außerdem wird es dann sehr langsam.
Aufgefallen ist mir auch noch, das die neue Firmware/Treiberkombination recht sensibel auf Entladen und Neuladen der Treiber reagiert.
Das klappt manchmal nicht, obwohl vorher kein sichtbarer Fehler aufgetreten ist, die Wahrscheinlichkeit steigt dabei mit phi_clk.
BTW: hatte ich ohne Angabe der Module Optionen ,mit der neuen Firmware, ein verzogenes OSD Menü
Hier habe ich neue Versionen von Treiberpatch und FPGA-Firmware, die diese Probleme hoffentlich beheben. Da diese Fehler bei mir nicht aufgetreten waren, weiss ich natuerlich auch nicht, ob es damit wirklich besser wird...
Gruss,
S:oren
Fuer mich ist die Spul-Geschwindigkeit auch eher schlecht erkennbar. Mir gefaellt die Variante von skinelchi besonders gut, da werden oben ueber dem Doppelpfeil in der selben Farbe kein/ein/zwei Striche eingeblendet, je nach Geschwindigkeit (statt des ueber den Doppelpfeil gedruckten Textes). Das finde ich sehr uebersichtlich, ist aber sicher Geschmackssache.
Ich wuerde mich jedenfalls freuen, wenn es diese Variante auch in skinnopacity gibt...
Gruss,
S:oren
