Posts by Urig

    Man könnte ihn sicher noch abmagern. Light ist er im Vergleich zum alten Patch, der das S2API mit Mitteln des alten DVBAPI nachbaut. Das ist zum Glück beerdigt.


    Alles was in der s2apiwrapper.h noch drin steckt, ergänzt nur die Definitionen, die in der frontend.h seit API 5.0 dazu gekommen sind, schön Version für Version, damit nichts doppelt deklariert wird. Ich hab sicherheitshalber einfach mal alle Änderungen gesammelt, falls irgendwann mal was davon nötig wird. (Ich hab auch eine komplette Sammlung aller frontend.h's, wer Interesse hat.)


    VDR braucht nur eine Handvoll davon, ohne Anspruch auf Vollständigkeit glaube ich FE_CAN_TURBO_FEC, DTV_DVBT2_PLP_ID, DTV_STREAM_ID, FE_CAN_MULTISTREAM. Bleibt es bei der Einschränkung auf API >= 5.3, ist die gesamte s2apiwrapper.h überflüssig, da VDR ja auch alles mitbringt. Das würde den Patch wohl auf die ersten 130 Zeilen eindampfen.


    Der Rest ist die Runtime-API-Versionsabfrage, und die paar Codeweichen. Bei den Delivery Systems gönne ich mir noch das Fallback-Verhalten von plain VDR bei API >= 5.5, wahrscheinlich würde hier aber auch eine einfache Codeweiche (DTV_ENUM_DELSYS ab >= 5.5, Legacy Mode bei < 5.5) genügen.


    Etwas unaufgeräumt ist auch, dass jedes Device das DVB-API ermittelt und speichert, ein mal zentral würde auch genügen. War halt so einfacher zu patchen.


    Gruß,


    Udo

    Wie schon gesagt, der HL-Cutter wurde von den Änderungen am Cutter ausgehebelt, wenn überhaupt könnte er nur als komplett alternative Schnittfunktion zurück kommen, zum Preis der nicht korrigierten Timestamps. Damit ist es aber ein weitgehender Rewrite, und dafür hab ich momentan nicht die Zeit.


    Fehlen tut er mir, es war jedenfalls ein Schock, als plötzlich HD-Aufnahmen von Filmen statt 10-20 Sekunden plötzlich eher 10 Minuten zum Schneiden brauchen. Auch dass man nicht während einer Timer-Aufnahme eine andere schneidet, hab ich schmerzlich wieder gelernt, der HL-Cutter war da immer so flink, dass sich gar kein Datenstau bilden konnte.


    Wenn es mal eine neue Version gibt, kommen vielleicht auch neue Features. BTRFS_IOC_CLONE_RANGE klingt einfach zu praktisch, dafür würde ich sogar das Dateisystem wechseln: Noch schnelleres Schneiden, selbst bei großen Dateien.


    Gruß,


    Udo

    Mal für die Akten, da man das sonst nirgends aufgeschlüsselt findet:


    Linux-3.8: DVBAPI 5.9 (Ubuntu 13.04 'Raring Ringtail')
    Linux-3.7: DVBAPI 5.9
    Linux-3.6: DVBAPI 5.6
    Linux-3.5: DVBAPI 5.6 (Ubuntu 12.10 'Quantal Quetzal')
    Linux-3.4: DVBAPI 5.5
    Linux-3.3: DVBAPI 5.5
    Linux-3.2: DVBAPI 5.4 (Debian 7.0 'Wheezy') (Ubuntu LTS 12.04 'Precise Pangolin')
    Linux-3.1: DVBAPI 5.3
    Linux-3.0: DVBAPI 5.3 (Ubuntu 11.10 'Oneiric Ocelot')
    Linux-2.6.39: DVBAPI 5.2
    Linux-2.6.38: DVBAPI 5.2 (Ubuntu 11.04 'Natty Narwhal')
    Linux-2.6.37: DVBAPI 5.2
    Linux-2.6.36: DVBAPI 5.2
    Linux-2.6.35: DVBAPI 5.1 (Ubuntu 10.10 'Maverick Meerkat')
    Linux-2.6.34: DVBAPI 5.1
    Linux-2.6.33: DVBAPI 5.1
    Linux-2.6.32: DVBAPI 5.1 (Debian 6.0 'Squeeze') (Ubuntu LTS 10.04 'Lucid Lynx')
    Linux-2.6.31: DVBAPI 5.0 (Ubuntu 9.10 'Karmic Koala')
    Linux-2.6.30: DVBAPI 5.0
    Linux-2.6.29: DVBAPI 5.0
    Linux-2.6.28: DVBAPI 5.0 (Ubuntu 9.04 'Jaunty Jackalope')
    Linux-2.6.27: DVBAPI 3.2 (Ubuntu 8.10 'Intrepid Ibex')
    Linux-2.6.26: DVBAPI 3.2 (Debian 5.0 'Lenny')


    Auf der sicheren Seite mit DTV_STREAM_ID (ab API 5.8) ist man also erst mit Kernel 3.7, und vor Kernel 3.0 (API 5.3) funktioniert EPG definitiv nicht. Dazwischen bin ich mir auch nicht sicher, da sendet plain VDR 2.0.0 noch sein DTV_DVBT2_PLP_ID an DVB-S2, was zwar schon definiert, aber für DVB-S2 natürlich unsinnig ist.



    Eine Logmeldung baue ich mal in die nächste Version ein, bis dahin kann sich das jeder aber auch selbst einbauen, cDevice holt sich die Runtime-Version im Konstruktor und speichert sie in dvbApiVersion, da könnte man sie auch loggen.



    Gruß,


    Udo


    Hm, es gibt doch DTV_API_VERSION. Damit kann man die "running API-Version" abfragen...


    Danke für den Hinweis, irgendwie hab ich die Funktion ewig gesucht und immer daran vorbei geschaut...


    Anyway, es gibt ein Update für den s2apiwrapper, der das Problem mit Laufzeitchecks endgültig löst.


    Das Problem mit EPG bei DVB-S2 ergab sich übrigens präzise so:
    - Seit 1.7.40 sendet VDR ein DTV_STREAM_ID auch an DVB-S2 Karten.
    - Wurden die Quellen gegen Header DVBAPI 5.7 oder älter übersetzt, wird statt dessen DTV_DVBT2_PLP_ID gesendet.
    - Das geht schon mal gar nicht, weil dieses Kommando exklusiv nur für DVB-T2 ist.
    - Vor DVBAPI 5.3 ist selbst DTV_DVBT2_PLP_ID für DVB-T2 unbekannt.
    - Durch das eine fehlerhafte Kommando wird die ganze Kommandokette abgebrochen, was zum fatalen Versager führt.


    Und obwohl ich von dem Problem wusste, bin ich natürlich prompt blind selbst hinein gerannt, denn ich verwende DVB-Treiber direkt aus Powarman's Zweig, und der ist auf DVBAPI 5.2 stehen geblieben.


    Jedenfalls verwendet der aktuelle Wrapper jetzt Laufzeit-Codeweichen für API 5.3 und API 5.8.



    Gruß,


    Udo

    S2API-Wrapper Light 0.10 für VDR-2.0.0.


    Die neueste Version des Wrappers behebt das Problem mit EPG-Daten auf DVB-S2 seit 1.7.40. Das Problem trat immer auf, wenn der Laufzeit-Kernel nicht mindestens DVB API 5.7 verstanden hat.


    Diese Version fragt die DVB API Version des Laufzeit-Kernels ab, und steuert die Funktionen entsprechend an, um Fehler durch noch nicht unterstützte Kommandos zu vermeiden. Gleichzeitig sind einige Code-Weichen im VDR-Quelltext, die auf der Version der DVB Header basierten, durch Laufzeit-Weichen ersetzt worden.


    Damit sollte VDR wieder auf allen DVB APIs von 5.0 aufwärts übersetzbar sein, und sämtliche Features stehen dann unter ausreichend aktuellen Laufzeit-Kerneln zur Verfügung.


    Download wie immer hier: http://www.udo-richter.de/vdr/patches.html#dvb-api-wrapper


    Gruß,


    Udo

    Kommt etwas spät, aber ich weise mal darauf hin, dass 3GB und GPT-Partition erst mal nix mit UEFI zu tun hat, man muss sich den UEFI-Kram also nicht antun.


    Ein paar Brotkrumen zum Thema:
    - Tauglichen Partitionierer verwenden. fdisk reicht nicht, gdisk oder parted geht. Bequemer gehts mit gparted, oder besser gleich Parted Magic auf einen alten USB-Stick installieren, braucht man sowieso immer wieder.
    - Darauf achten, dass eine GPT-Partitionstabelle erstellt wird, und keine MBR-Partitionstabelle.
    - Für Grub wird eine eigene Bootlader-Partition benötigt. Einfach eine 1Mb-Partition anlegen, und bei den Partitions-Flags das Flag bios_grub setzen.
    - Rest der Platte nach belieben partitionieren.
    - Linux installieren oder Partition zurück sichern. Installationen sollten von selbst klar kommen, beim zurücksichern muss Grub neu installiert werden, aber das ist ein eigenes Thema. (Typisch: von Rettungsmedium starten und Grub neu installieren, oder von Live-CD per chroot in installiertes System wechseln und Grub neu installieren.)


    Alle aktuellen Grub-Versionen erkennen das bios_grub Flag und installieren den Bootlader automatisch in den Kompatibilitäts-MBR und in diese Partition. Grub selbst hat keine Probleme, die GPT-Partitionstabelle zu lesen, und damit steht dem weiteren Bootvorgang nichts mehr im Wege. Möglicherweise kriegt man über den Umweg Grub sogar ein paar der GPT-Boot unfähigen Windows-Versionen zum starten, hab ich aber noch nie getestet.


    Gruß,


    Udo

    Nein, so oft baue ich sie nicht aus und ein, zum Glück. Nur ist mir beim letzten Einbau (wegen Tausch des Netzteils) schon mulmig geworden, bei dem Druck, mit dem ich den Stecker in die Buchse stecken muss, und so sehr, wie sie wackelt, reicht ein kurzes Abrutschen vermutlich aus, und man hat die Buchse in der Hand.


    An die Materialermüdung der Kontaktstifte und eventuelle Wackelkontakte möchte ich gar nicht erst denken. Das Fehlerbild bei instabiler Stromversorgung dürfte interessant sein.



    Gruß,


    Udo

    Zu meiner Schande muss ich zugeben, dass ich schon seit Oktober einen Patch dazu von Christopher Reimer herum liegen hab, der sich diesem Problem, genauer gesagt dem Problem von ps, das nicht mehr ohne Fehlermeldung eine geschlossene Standardausgabe akzeptiert, annimmt.


    Ich muss mich dringend mal wieder daran machen, alles für eine neue Version zusammen zu sammeln. Insbesondere jetzt, wo 2.0.0 vor der Tür steht.


    Zunächst mal, im Anhang, der komplette Pipe-Fix-Patch, full credits go to Christopher Reimer.



    Gruß,


    Udo

    Hab das Voltcraft IPC-1 (baugleich Technoline BC900), und bin sehr zufrieden. Die höheren Ladeströme (4x bis 1000mA, 2x bis 1800mA) habe ich in der Praxis allerdings noch nie genutzt, das IPC-1L / BC700 (max 4x 700mA) hätte es also auch getan.


    + Kapazitätsmessung, hilft, um gleich starke Akkus zusammen zu paaren, und alte Akkus auszusortieren
    + Auffrischen von ausgeleierten Akkus
    + 110V-kompatibel, 12V-Auto-Adapter
    + Gutes Preis/Leistungsverhältnis
    - Nur AA/AAA, keine 9V-Blocks


    Gruß,


    Udo

    dvbhddevice schaltet (wenn so konfiguriert) den Fernseher beim PluginStop und dem somit spaetest moeglichen Zeitpunkt aus - kein Bedarf fuer Rechnerei mit der Inactive-Time.


    Hab nachgeschaut, die Aktivitätsprüfung wird tatsächlich nur zum Einschalten verwendet. Es wäre aber technisch möglich, es auch zum Ausschalten zu verwenden: Drückt man dann Power, und VDR verweigert den Shutdown wegen Timer o.ä., würde sich der Fernseher nach 10s abschalten, während VDR weiter läuft. Drückt man dann eine andere Taste, würde er sich wieder einschalten.


    Ich verwende das sowieso nicht, da ich den VDR auch schon mal per wake-on-lan einschalte, und ich noch keinen Weg sehe, in dem Fall den Fernseher aus zu lassen. Außerdem zickt mein Samsung da glaube ich sowieso rum.


    Gruß,


    Udo

    Der Patch funktioniert bei mir unter 1.7.37 ohne Probleme, dein Fehler kommt wohl eher aus der Tatsache, dass die offiziellen Kernel-Includes deines System wohl noch älter als 5.0-API sind, denn der gepatchte Code wird ja compiliert, findet aber kein 5.0-API. VDR selbst findet zumindest 5.0-API, wenn wohl auch kein 5.3-API, sonst bräuchtest du ja keinen Patch.


    Wenn du sowieso keinen Distributions-Kernel, sondern einen eigenen Kernel verwendest, warum dann keinen aktuelleren mit 5.3-API?


    Eigentlich sollte DVBDIR via CFLAGS und CXXFLAGS und via vdr.pc an das Plugin übergeben worden sein, warum es trotzdem nicht in der g++ Zeile auftaucht, verstehe ich auch nicht. Hast du vielleicht mittels PLGCFG= eine globale Konfigurationsdatei eingebunden, die CFLAGS und CXXFLAGS überschreibt? Wenn ja, hast du damit DVBDIR wieder aus den Flags gelöscht.


    Gruß,


    Udo

    Bin ja schon wieder da... Hektiker...



    Nur gut, saß ich dieses Feature selber nicht brauche - verstehen würde ich es vermutlich auf Anhieb nicht... ;-)


    Ok, zur Erklärung:
    Das System merkt sich bei jeder User-Aktivität, dass es in Now+MinUserInactivity (default 3h) davon ausgehen kann, dass kein User mehr da ist. Das beinhaltet auch, dass zum Zeitpunkt activeTimeout-5min der Countdown startet.
    Die Funktion erlaubt nun zusätzlich, statt MinUserInactivity eine andere Zeitspanne anzugeben. Ist aber MinUserInactivity=0, hat der User ja kundgetan, dass er überhaupt nicht möchte, dass das System von selbst inaktiv wird, deswegen wird der Aufruf dann ignoriert. Aber selbst mit MinUserInactivity=0 kann der User noch auf den Powerbutton drücken, und so seine Abwesenheit kundtun (insbes. wenn kein Shutdown-Skript angegeben ist), deswegen ist es erforderlich, sich notfalls an MinUserInactivity=0 vorbei zu schummeln.



    Ehrlich gesagt greift mir "Urig"s Patch zum jetzigen Zeitpunkt zu tief ein. Ich wollte eigentlich für die Version 2.0 keine großartigen funktionellen Änderungen mehr machen, und da die Shutdown-Funktion bisher anscheinend problemlos funktioniert hat, möchte ich nicht riskieren, sie im letzten Moment noch "kaputtzuändern".


    "S:oren"s Änderung dagegen würde mir simpel genug erscheinen um sie noch mit reinzunehmen.


    Auch wenn mein Patch auf den ersten Blick komplexer scheint, greift er eher weniger tief ein, als S:oren's Patch. Beide führen den Sonderfall activeTimeout=1 ( = 1.1.1970 00:00:01 Uhr) für einen unbekannten, in der Vergangenheit liegenden Zeitpunkt ein. Der Unterschied ist, dass mein Patch diesen Sonderfall nur beim Programmstart verwendet, S:oren's auch bei bestimmten Fällen des Powerbuttons. Meine Version führt noch formal die Sonderparameter -2 und -3 ein, die vorher undefiniert waren, und wie -1 interpretiert wurden. Extrem unwahrscheinlich, dass diese Sonderfälle schon mal genutzt wurden. Der Rest sind Kommentare, die nur zur Klarstellung dienen.



    Nur mal interessehalber: Wo wird denn die Information benutzt, seit wann der User inaktiv ist? Habe nichts gefunden, habs aber vielleicht uebersehen.


    In VDR gar nicht, aber es ist direkt über GetUserInactiveTime und indirekt über IsUserInactive für Plugins abfragbar. Es würde z.B. dem hddevice erlauben, mit IsUserInactive(time(NULL)-10) gezielt 10 Sekunden später erst den Bildschirm abzuschalten, damit man noch Zeit hat, die letzte Meldung zu lesen.


    Gruß,


    Udo


    Dafür bräuchte ich ein OK von Udo Richter ("Urig"), denn der hat den Shutdown-Handler eingebaut und müsste beurteilen können, ob das so geht.


    Prinzipiell ok, ich würde den speziellen Wert activeTimeout = 1 aber auf den konkreten Fall des VDR-Starts beschränken, damit auch weiterhin die Information, seit wann kein User mehr aktiv ist, erhalten bleibt. Das kommt z.B. immer dann vor, wenn ein Shutdown abgebrochen wurde.


    Aufgehübschte Version des Patch ist im Anhang. Nicht wirklich getestet, aber überschaubar, sollte gehen.



    Probleme mit springenden Uhren dürfte es übrigens noch einige in VDR geben, so löst ein mehrminütiger Sprung während einer Aufnahme IMHO immer noch einen "Video Data Stream Broken" aus.



    Gruß,


    Udo

    Jupp, es genügt, Pid == pPatPmtParser->PmtPid() durch pPatPmtParser->IsPmtPid(Pid) zu ersetzen.


    Der Patch dazu liegt hier schon, werde ihn aber erst nach VDR-1.7.33 bringen, man muss ja nicht jeden Zwischenstand versorgen. Außerdem sollt ihr doch nicht alle Patches gleichzeitig ausprobieren! ;)

    Damit es wenigstens mal irgendwo nachzulesen ist:


    Der hard link cutter Patch wird vorerst nicht auf VDR-1.7.32 portiert, die neuen Schnittfunktionen greifen zu tief in das Videomaterial ein, um noch Dateien 1:1 zu klonen.


    Ich selbst trauere dem Patch bereits jetzt nach, die ewig langen Schnittzeiten bin ich schon lange nicht mehr gewohnt.


    Vielleicht wird es irgendwann mal eine komplett separat entwickelte Schnittfunktion nach dem 'alten' Prinzip geben, aber das wird viel Arbeit, und ich weiß nicht, wann ich das mal einschieben kann.


    Gruß,


    Udo