Beiträge von z421

    Habe kurz über deinen Link drübergelesen, und aufgefalle ist mir dabei die Treiberinstallation für die DVB Karte.
    Ich verwende eine ähnliche, und denke dass deine auch mit dem selben Treiber läuft. Diese sind seit Kernel version 3.19(?) integriert.


    Debian hat seit linux-image-4.0.0-2-amd64 die Treiber per default enthalten.
    Ich weiß nicht, obs von dem Kernel bereits Backports für Jessie gibt, jedoch ist ein backport auch sehr leicht selber zu erstellen:

    Zitat

    vim /etc/apt/sources.list.d/unstable.list


    Zitat

    deb-src http://debian.inode.at/debian/ unstable main contrib non-free


    Zitat

    apt-get update
    apt-get build-dep linux-image-4.0.0-2-amd64
    apt-get source -t unstable linux-image-4.0.0-2-amd64 -b


    Vielleicht gefällt dir diese Lösung zur Treiber-Installation. :)
    Damit baut man zwar einmal den ganzen Kernel, hat dafür aber alle Vorzüge des Debian Kernels, und alles sauber im Package Manager integriert.

    Interessantes Thema.


    Ich bin aktuell am überlegen ob ich eine Installation auf dem Nix package manager[1] basieren soll.
    Das ist ein anderer Ansatz als die Docker Container, allerdings auch sehr interessant.


    Vorallem rollbacks usw. sind damit gut in den Griff zu bekommen. Auch ein deployen wäre ziemlich einfach.
    Dabei gefällt dass die Packages aus dem Source gebaut werden (können) und es auch möglich ist diese über einen binary_cache auch ohne kompillieren zu verteilen.


    [1] https://nixos.org/nix/


    nach dem Wechsel des Netzteils startet die Karte nun zuverlässig... :D


    Hallo Jürgen,


    danke für den Tip. Da die Karte auch bei mir regelmäßig Schwierigkeiten beim Empfang hatte bin ich auf den Thread aufmerksam geworden.


    Dass es an der Spannung liegt habe ich schon vermutet, da die Karte immer dann gut lief, wenn wohl viele Leute im Mehrparteienhaus ferngesehen haben. Auch ein leises, hochfrequentes Summen der Karte ist aufgefallen, als der Empfang schlecht war. Als ob eine Spule im Grenzbereich laufen würde.


    Auf den Netzteil-Tipp hin habe ich die Verkabelung der DVB-Sky Stromversorgung überprüft und gesehen, dass ich die Karte damals mittels dem mitgelieferten Adapter an eine SATA Versorung angeklemmt hatte. Das gleiche Kabel versorgte vom Netzteil aus die SSD & das BluRay Laufwerk.


    Habe nun eine extra PCI-E Strippe vom Netzteil direkt an die Karte geklemmt, und seither läufts. :)



    Mit freundlichen Grüßen,
    z421

    Hallo Miteinander!


    z421: Die Zeile wird mit dsyslog ausgegeben. Es passiert also schon genau das was du dir wünscht. Du musst nur den Log-Level vom VDR runterdrehen.


    Das ist richtig, jedoch kann ich mir nicht vorstellen, dass es beim Debuggen sinnvoll ist eine Logdichte von ca. 1800 Einträgen pro Sekunde zu generieren. ;)


    Prima! Danke für's Feedback!


    Sehr gerne - danke für's Plugin! Ich mag das Feature sehr, und nutze es regelmäßig. :)
    Auch freut es mich, dass du aktiv auf das Feedback eingehst und das Problem in Version 1.0.1 behoben hast.



    Bitte weitermachen mit der hervorragend Entwicklung. :tup



    Mit freundlichen Grüßen,
    z421 :)


    @Ein Eike:


    Hallo, und erstmals vielen dank für das großartige Plugin. Ich nutze es jetzt seit Tagen auf meinem System, und es läuft prächtig!



    Jedoch ist mir aufgefallen, dass ich seit aktivieren des Plugins keinen guten Log mehr zur Verfügung habe. Das Plugin schreibt permanent eine Logzeile raus (overwritingringbuffer.c:43). Auf meinem System landet diese im Syslog und füllt ihn somit recht schnell. Es wäre hilfreich, wenn diese Ausgaben über eine Debug Flag, oder eine Plugin-Einstellung gesteuert werden könnte.


    Code
    void cOverwritingRingBuffer::WriteData(uchar* Data, uint64_t Length)
    {
        	if ((m_dataLength + Length) / (100 * 1024 * 1024) > m_dataLength / (100 * 1024 * 1024))
        	{
                	dsyslog("permashift: %d MB live video data in buffer \n", 100 * ((m_dataLength + Length) / (100 * 1024 * 1024)));
        	}


    Um ein Gefühl dafür zu bekommen wie das aussehen kann, ein kleiner Auszug aus dem Log:

    Code
    root@multi-player:/var/log# cat /var/log/syslog | grep "10:04:48" | tail -n 1
    Oct 26 10:04:48 multi-player vdr: [874] permashift: 100 MB live video data in buffer
    root@multi-player:/var/log# cat syslog | grep "10:04:48" | grep "permashift: 100 MB live video data in buffer" | wc -l
    1804
    root@multi-player:/var/log#


    Mit freundlichen Grüßen,
    z421 :)

    Code
    w_scan -f c -c AT -x >> at-Liwest



    Vielleicht kann auch jemand anderer damit etwas anfangen. :)



    Mit freundlichen Grüßen,
    z421


    Fein, hatte gerade das selbe Problem, wurde allerdings mit -C auch behoben.
    Könnte es sein, dass hier beim auslesen des $HOME aus dem env was schief geht? (eventuell ein Bug, da die Variable hier auch verfügbar ist.)


    Nettes Plugin, für den MusicPD wäre es allerdings noch ne spur feiner, da der kein KDE und kaum Ressourcen braucht. (in kombination mit dem VDR ist es ja fast ein "overkill" KDE und amaroK zu starten.)


    mfg z421 :)

    naja, dass es mit dem scalieren zu tun hat, glaub ich kaum, da ja an der auflösung nichts verändert wurde.
    im moment habe ich "scale osd" und "allow downscaling" aktiviert.


    das abschalten der composite extension des xservers brachte auch keine besserung.



    mfg z421 :)

    hallo!


    da ich letztens eine "neue" grafikkarte mit xvmc support bekommen habe, wollte ich dies natürlich gleich testen. da ich vdr immer mit xineliboutput verwende (vdr läuft im background, und wenn ich tv will, dann starte ich nur das vdr-sxfe/vdr-fbfe.)


    nun, nachdem ich xvmc konfiguriert habe, xine war mit xvmc support kompilliert, habe ich mal versucht das sxfe mit --video=xvmc zu starten, was auch funktionierte. die cpu-last von sxfe fiel im vergleich zu xv ca. auf die hälfte ab.


    so, allerdings besteht ein problem:
    mit vdr-sxfe --video=xvmc habe ich kein osd.
    mit vdr-sxfe --video=xv funktioniert das osd.
    die steuerung mittels tastatur funktioniert bei beiden varianten.


    nvidia-drivers-1.0.9755
    und in der XvMCConfig habe ich:
    libXvMCNVIDIA_dynamic.so.1
    eingetragen.



    wo könnte der fehler liegen?
    bzw. hat dazu jemand eine idee?



    mfg z421 :)

    da bin ich dabei!
    ich glaub den gasthof kenne ich sogar, ist recht gemütlich, soweit ich mich jetzt nicht an was falsches erinnere. :)


    beim termin, würde ich eher einen freitag vorschlagen.


    mfg z421 :)

    also, so wie ich das sehe, gibt's ja doch einige interessenten an einem treffen in österreich, allerdings scheint es als ob die meisten user quer verstreut durch österreich sind.


    nun wär es wichtig sich auf einen treffpunkt zu einigen, der für die meisten in ordnung geht.


    also, weil im beitrag vor mir postleitzahl als ansatz stand, hier mal meine möglichkeiten:
    1200 wien
    3911 rappottenstein (nähe zwettl)
    50XX (salzburg) da will ich in nächster zeit mal ein paar tage verbringen.


    mfg z421 :)

    ich wär für wien ;).


    aber wr. neustadt, wie lange fährt man da ca. von wien?
    bzw. wie siehts da mit verkehrsmitteln aus, die zu späterer stunde wieder nach wien fahren?



    ich bin, falls der weg nicht zu weit ist (~ >1 stunde fahrzeit/richtung) voraussichtlich dabei! :)


    mfg z421 :)

    hmm... das scheint bei mir im log nicht auf.
    epg ist kein externes, und patches sind folgende aktiv:


    laut debian/00list file.


    komischerweise, dürfte da aber was anderes nicht stimmen, da ich grade versuchte am server, wo die aufnahme stattinden sollte auf ORF zu schalten, und da bekam ich "Kanal nicht verfügbar!".
    sry, dürfte wie es scheint nicht am VPS gelegen haben.


    mfg z421 :)

    ich hab schon wieder mal ein problem mit vps, und ich versteh da wieder nicht, warum es nicht funktioniert hat.


    hier mal ein auszug aus dem log:


    im syslog stehen auch nur die selben zeilen.


    woran kann es liegen, dass zu dem zeitpunkt keine aufnahme getätigt wurde?
    wurde die sendung vielleicht per VPS komplett verschoben?
    oder ...?


    mfg z421 :)

    oder apt/dpkg zum überschreiben zwingen.


    aus der manpage von dpkg:

    Zitat

    Warnung. Diese Optionen sind hauptsächlich für den Einsatz durch Experten gedacht. Der Einsatz ohne komplettes
    Verständnis der Effekte kann Ihr gesamtes System zerstören.


    dpkg --force-overwrite -i dein.deb

    naja, ich kenn mich da auch nicht wirklich aus, aber soweit ich weiß sendet vps ein start und ein stop signal. (und dazwischen active signale)


    d.h. wenn bei dem timer nachträglich vps angeschaltet wird, sollte der time beim nächsten vps start signal erst loslegen und beim 2. vps stop signal dann beenden. (ist halt problematisch, wenn dazwischen eine sendung ist, die kürzer als der eingestellte vor/nachlauf ist.)


    ist auch nur eine laienhafte spekulation.

    wie es scheint, liegt das problem an "usevps=1".


    ohne der funktion, stimmt der vor-/nachlauf.


    das ist allerdings überdenkenswert, ob man dem timer die vor/nachlaufzeit erst beim speichern mitgeben soll.
    denn im moment, wird die zeit beim klick auf aufzeichnen genieriert.
    ich hätte gerne usevps=1, und wenn ich vps manuell deaktivere, dass dann die vor/nachlaufzeit trozdem eingehalten wird.


    mfg z421 :)

    bei den autotimern ist keine pufferzeit eingestellt.


    aber der tagesschau timer, den ich vorhin angelegt hatte, der war von hand angelegt.
    und VPS war bei dem timer deaktivert.


    hier mal die, in dem fall relevanten einstellungen vom xxv.

    Zitat

    [AUTOTIMER]
    active=y
    exclude=POS > 5000



    siehst da jemand den fehler, oder ist der hund wo anders begraben?