Beiträge von musv

  • Streams stoppen bei Inaktivität

    S.o. Screenshot im Startbeitrag. Wenn VDR gestartet wird, wird automatisch auf den ersten Sender/zuletzt gesehenen Sender geschaltet. VDR ruft den Stream vom Device (DVB-Tuner/SatIP-Tuner) ab. Ob der Stream dabei angezeigt wird, dürfte da keine Rolle spielen.

  • Streams stoppen bei Inaktivität

    Zitat von M-Reimer

    Was würde eigentlich passieren wenn man einfach ein nicht vorhandenes Sat-System einrichtet, nebst nicht tunbarem Kanal. Den dann als Startkanal festlegen. Dann müsste der VDR eigentlich mit "Kein Signal" dastehen...

    Ich hab die Octopus erst mal vom Stromnetz getrennt. Wenn ich den VDR da starte, erscheint folgendes im Log:

    Code
    Sep 24 12:07:04 nas systemd[1]: Starting Video Disk Recorder Daemon...
…
Sep 24 12:07:17 nas vdr[29720]: [29720] SATIP: Creating device CardIndex=0 DeviceNumber=0 [device 0]
Sep 24 12:07:17 nas vdr[29720]: [29744] SATIP poller thread started (pid=29720, tid=29744, prio=high)
…

Sep 24 12:07:19 nas vdr[29720]: [29720] switching to channel 1 S19.2E-1-1019-10301 (Das Erste HD)
Sep 24 12:07:19 nas vdr[29720]: [29720] info: Kanal nicht verfügbar!
…
Sep 24 12:07:21 nas systemd[1]: Started Video Disk Recorder Daemon.


    D.h. VDR startet, findet keine Karte/SatIP-Signal und meldet halt, dass der Kanal nicht verfügbar ist. Der VDR braucht in dem Fall fast keine CPU-Last. Ist also im Grunde genommen genau das, was ich will.


    Das generelle Problem ist aber damit nicht behoben. Nach dem Disconnect eines Frontendclients würde ja der Stream trotzdem weiterlaufen. D.h. nach der ersten Nutzung ist damit wieder der unerwünschte Zustand erreicht.


    Wünschenswert wäre eine Option:

    ReleaseDeviceWhenIdle = 1
    Und als Parameter dann halt, dass der Stream sofort gestoppt wird oder eine Art Timeout, wenn das irgendwie sinnvoll ist.

  • Streams stoppen bei Inaktivität

    Das hatte ich bereits gefunden und explizit deaktiviert. Das Ziel ist weder das NAS noch den VDR-Dienst runterzufahren. Ersteres wäre komplett falsch, zweiteres braucht dann ja bei einer langsameren Kiste durchaus einige Zeit, bis der Dienst wieder verfügbar ist.


    Socket Activation wäre natürlich ein Workaround - wenn auch ein eher schlechter.


    Mir geht's halt wirklich nur darum, dass der VDR bei Inaktivität keinen Stream vom Device anfordert. Bei epg-scan, Channelscan oder Client Connection darf er gern loslegen. Wird bei der Octopus kein Stream abgerufen, ist der Verbrauch bei der Hälfte.

  • Streams stoppen bei Inaktivität

    Zitat von SurfaceCleanerZ

    Hi,

    Ob Satip das kann weiß ich nicht. Ansonsten geht es mit dem dynamite-Plugin (bei lokalen Tunern).

    Müsstest du mal testen ob das geht.

    Aber wie soll erkannt werden, dass kein Tuner verwendet wird?

    Bei SatIP hab ich noch keine Einstellung gefunden. Bisher beobachte ich folgendes Verhalten:


    VDR-Start

    Wenn der VDR-Service gestartet wird und alle Plugins initialisiert sind, wird sofort auf einen Kanal geschaltet. In den Einstellungen kann man konfigurieren, ob das der erste Kanal sein soll oder der zuletzt genutzte (setup.conf: InitialChannel = S19.2E-1-1019-10301). In der Zeit ist auch noch kein Frontend-Client geladen (Xineliboutput, Kodi per VNSI).


    Das Dynamite-Plugin hatte ich noch nicht auf dem Schirm. Der Beschreibung nach zielt das aber eher auf das Hotplugging von Devices. Ich werd mich mal einlesen in das Plugin. Danke für den Tipp.


    Clientüberwachung

    Der VDR weiß, ob ein Client verbunden ist. Sowohl bei Xineliboutput als auch bei VNSI zeigt das Log an, ob ein Client verbunden ist.



    Zitat von iNOB

    Einfach die EPG Suche in den Einstellungen von Client/Server abschalten, dann ist Ruhe auf der Octopus.

    Die EPG-Suche ist bei mir so konfiguriert, dass alle 5 Stunden ein Scan stattfindet. Auch hab ich beobachtet, dass beim epg-Scan die CPU-Leistung (schwaches NAS) auf 30% hochgeht. Ist das Scan beendet, liegt die CPU-Last für den VDR-Prozess nur noch bei 6-10%. Man kann also den Zeitraum des epg-Scans durchaus bestimmen. Der Screenshot von oben war außerhalb des epg-Scans.



    Ideen

    Ich werd mal den EPG-Scan und evtl. auch den Channelscan (Namen + PIDs) testhalber komplett deaktivieren. Auch hab ich schon beobachtet, dass beim Start von Xineliboutput nicht direkt auf den ersten/zuletzt genutzten Kanal geschaltet wurde sondern eine Art Titelbild angezeigt wurde. Ich wühl mich auch mal durch die Optionen in der setup.conf.


    Falls ich nichts find, wär das wohl auch ein Fall für ein Feature Request, da ich wohl bestimmt nicht der Einzige mit dem Problem bin. :)

  • Streams stoppen bei Inaktivität

    Guten Abend,


    ich rüste derzeit meine Konfiguration um von HTPC mit TV-Karte auf Octopus NET + VDR auf ARM-NAS.


    Sowohl die Octopus als auch das NAS laufen permanent. Jetzt hätte ich das Ganze natürlich gerne so stromsparend wie möglich. D.h. wenn kein Client mehr auf den VDR zugreift und keine Aufnahme im Gange ist, dann wär's nicht schlecht, wenn der VDR auch sämtliche Streams beendet.


    Leider tut er das nicht, wie ich im Webfrontend der Octopus nachprüfen kann (siehe Screenshot).


    Kann man das irgendwie einstellen? Ich hab leider nichts dazu gefunden.

  • werden die Gentoo ebuilds noch gepflegt?

    Guten Abend,


    Eigentlich hab ich andere Sachen zu tun, bin dann aber auf diesen Thread hier gestoßen. Wer's nicht anklicken will:


    FernetMenta ist umgestiegen auf TV-Headend und pflegt das vnsi-Plugin für Kodi nicht mehr. Hier wurde das Thema schon mal angesprochen. Eigentlich würde ich nur sehr ungern weg von VDR. Es läuft halt ziemlich stabil bei mir. Allerdings ist die Integration in Kodi für mich zumindest zwingende Voraussetzung.


    Und zu den Ebuilds:

    Ich hab das vdr-overlay eingebunden. Da ist aber die 2.3.1 als maskierte Version die aktuellste. Gibt's da noch immer Pläne, das mal auf die 2.4.x zu aktualisieren? Welche Ebuilds nutzt gen2vdr?

  • werden die Gentoo ebuilds noch gepflegt?

    Würde mich auch interessieren. vdr-2.4.0 ist jetzt schon eine ganze Weile raus. Im vdr-devel ist aber sogar noch die 2.3.1 maskiert. Ein Ebuild für die 2.4.0 konnte ich in den großen weiten Welten des Internets überhaupt nicht finden. Der Status der meisten Plugins ist wenig positiv.

    Ich würde gern mal die 2.4.0 ausprobieren. Das Problem an der Sache ist, dass ich die 2.3.2 auch nur mit irgendwelchen Patches zum Laufen bekommen hab. Und bei mir muss zwingend vdr-sc und vdr-vnsi laufen. Die 2.3.2 funktioniert momentan ziemlich problemlos. Wenn ich mit der 2.4.0 meine aktuelle Config versau, streikt die Familie. :)

  • [solved] VDR - Wait for devices (alt: Plugin-Reihenfolge)

    So, jetzt hab ich's endgültig geschafft. Schaltet man das Debug-Log ein, dann wird das Problem sichtbar.


    Code
    [general.error] socket: name lookup error for …


    Oder mit anderen Worten, das Netzwerk war noch nicht da. Jetzt gibt's als mögliche Dependencies network-target, network-online.target. Das gewünschte Ergebnis brachte allerdings nur systemd-networkd-wait-online.


    /etc/systemd/system/vdr.service.d/02_wait_for_network.conf

    Code
    [Unit]
Requires=systemd-networkd.socket
After=systemd-networkd.socket


[Service]
ExecStartPre=/usr/lib/systemd/systemd-networkd-wait-online --interface=wlan0

  • [solved] VDR - Wait for devices (alt: Plugin-Reihenfolge)

    Ich bin einen halben Schritt weiter.


    Ich hab die setup.conf mal verschoben, d.h. mit einer Vanilla-Config für den VDR wieder begonnen.


    Als nächstes hab ich nur die Plugins aktiviert:

    Code
    eselect vdr-plugin list
Available VDR plugins:
  [1]   sc *
  [2]   streamdev-client
  [3]   streamdev-server
  [4]   svdrpservice
  [5]   vdrmanager
  [6]   vnsiserver *
  [7]   xineliboutput *


    D.h. Streamdev, SVRDP, VDRManager sind deaktiviert. Bis jetzt funktioniert es damit schon den 2. Tag in Folge. Ich werd jeden Tag mal etwas an der Config ändern und dann beobeachten, wer der eigentliche Übeltäter ist.


    Viele Grüße

  • uam-mount: USB-Stick wird nicht gemounted

    Da du ja unter Gentoo sowieso Systemd benutzt, kannst du das auch gleich für das Automount hernehmen:
    https://ddumont.wordpress.com/…usb-devices-with-systemd/


    Alternativ sollte es auch mit Udev problemlos gehen:
    https://www.axllent.org/docs/view/auto-mounting-usb-storage/


    Sinnvoll ist es vermutlich in beiden Fällen, für die einzelnen Partitionen Labels zu verwenden, die du dann entweder in Udev oder mit Systemd in der fstab adressieren kannst.

  • [solved] VDR - Wait for devices (alt: Plugin-Reihenfolge)

    Leider muss ich den Thread wieder öffnen. Hab mich wohl zu früh gefreut. Das Problem trat in den letzten Tagen dann doch wieder auf. Tut mir leid, wenn in einigen vorherigen Beiträgen ein bisschen Frust mit durchkam.


    Ich hab gestern abend mal vor dem Ausschalten das VNSI-Plugin deaktiviert, einfach um VNSI als Blockierquelle auszuschließen. Und heut früh beim einschalten:
    ARD: klappt
    ZDF: klappt
    Pro7 HD: Sender nicht verfügbar …


    Langsam bin ich echt am Verzweifeln. Mir gehen die Ideen aus, wo ich noch ansetzen kann. Die Holzhammermethode wäre, nach dem Abschluss des Startvorgangs des VDR noch mal einen VDR-Restart durchführen zu lassen.


    Meine bisherigen Erkenntnisse:

    • Start des Rechners (inkl. VDR) nach mehreren (mind. 10?) Stunden: PayTV geht nicht. Sender nicht verfügbar.
    • Start des Rechners nach wenigen Stunden Pause: PayTV geht (Karte noch irgendwie warm?)
    • Restart von VDR nach dem ersten Start: PayTV geht. Wobei ich noch nicht getestet hab, ob es funktioniert, wenn ich VDR restarte, ohne einen Sender aufzurufen.
    • VNSI ist nicht der Übeltäter, was ich eigentlich lange Zeit vermutet hatte.


    Randinfomationen:

    • Das Problem trat zum ersten Mal vor ca. 2 Jahren auf. Damals lief XVDR relativ instabil. Also bin ich auf VNSI umgestiegen.
    • TV-Karte ist eine Digital CIne S2, V6.5. Hab ich jahrelang nur mit einem Tuner betrieben (nur 1 Kabel). Mittlerweile hab ich über einen Unicable-Splitter beide Tuner angeschlossen. Funktioniert soweit auch klasse. Das PayTV-Problem tritt aber unabhängig davon auf.


    Was ist jetzt noch testen werde:

    • EPG abschalten
    • Bis auf VNSI und SC sämtliche andere Plugins (sind ja nur 5) deaktivieren
    • Neustart des VDR gleich nach dem ersten Start, ohne einen Sender aufzurufen
    • Loglevel hochdrehen
    • Wenn alles nichts hilft, eventuell noch mal mit Dynamite rumspielen.


    Btw. der Dynamite-Patch

  • [solved] VDR - Wait for devices (alt: Plugin-Reihenfolge)

    Hab mein Problem lösen können.


    Nicht die Ladereihenfolge der Plugins war das Problem. Vielmehr startete der VDR bevor die TV-Karte initialisiert war. Darauf gestoßen bin ich über den Umweg des Dynamite-Plugins.


    Also hab ich mich hingesetzt, den VDR, SC und Dynamite gepatcht und alles compiliert. VDR startete inklusive aller Plugins. Dummerweise kann ich weder über Kodi (VNSI) noch über xineliboutput auf den VDR zugreifen. Entsprechend hab ich das Dynamite-Plugin inkl. sämtlicher Patches wieder runtergeschmissen.


    Tante Google brachte mich nach langer Recherche (leider wird überall abgeblockt, wenn die bösen Plugins im Thread erscheinen) auf eine Systemd-Lösung. Und die funktioniert ausgesprochen gut. Ich geb mal hier 'ne Anleitung:


    1. Die Devices ermitteln
    Meine TV-Karte ist eine Cine S2.

    Code
    ls /dev/dvb/adapter*
/dev/dvb/adapter0:
demux0  dvr0  frontend0


/dev/dvb/adapter1:
demux0  dvr0  frontend0


    2. Udev-Regeln



    Daraus bastel ich mir die Datei:


    /etc/udev/rules.d/98-dvb.rules

    Code
    KERNEL=="dvb0.demux0", TAG+="systemd"
KERNEL=="dvb0.dvr0", TAG+="systemd"
KERNEL=="dvb0.frontend0", TAG+="systemd"
KERNEL=="dvb1.demux0", TAG+="systemd"
KERNEL=="dvb1.dvr0", TAG+="systemd"
KERNEL=="dvb1.frontend0", TAG+="systemd"


    Das Taggen ist wichtig, damit Systemd die Devices mit systemctl auflistet und diese in den Units verwendet werden können.


    3. Systemd+VDR
    Die mitgelieferte VDR-Unit zu ändern, ist schlecht, da man bei Systemupdates die Änderungen verpasst. Also erweitern wir einfach die Unit:


    /etc/systemd/system/vdr.service.d/01_wait_for_devices.conf


    Abschließender Tralala
    Entweder man startet das System neu, oder man tippt halt folgende Befehle noch ein:

    Code
    udevadm control --reload
udevadm trigger
systemctl daemon-reload


    Fazit
    Der Aufwand und das Ergebnis von vdr-dynamite waren irgendwie ernüchternd. Zuviel Patcherei (einen musste ich manuell anpassen). Und hinterher funktionierte es trotzdem nicht.


    Die Identifikation des Problems selbst war auch ein Stochern im Heuhaufen. XVDR+SC lief damals problemlos. Mit Umstieg auf VNSI musste ich dann VDR immer bei der ersten Nutzung 2x starten. VNSI lag da irgendwie als Fehlerquelle nahe. Irgendwelche Ausflüge zum anderen bösen Plugin brachten irgendwie außer einigem Lernerfolg keine brauchbaren Erfolge.


    Jetzt funktioniert alles, wie es soll. Ich hoffe, es hilft anderen, die Suche zu verkürzen.

  • [solved] VDR - Wait for devices (alt: Plugin-Reihenfolge)

    Zitat von seahawk1986

    Ich würde mal … nachsehen, … was in /var/vdr/tmp/systemd_env landet.


    Code
    VDR_OPTS=" '--chartab=ISO8859-9' '--watchdog=60' '--device=0' '--device=1' '--cachedir=/var/cache/vdr' '--log=0' '--video=/home/sm/Daten/vdr/video' '--record=/usr/share/vdr/bin/vdrrecord-gate.sh' '--plugin=svdrpservice ' '--plugin=vdrmanager -p6420 -Pxbmc -k /etc/vdr/plugins/vdrmanager/vdrmanager.pem -c  ' '--plugin=vnsiserver ' '--plugin=xineliboutput --local=none --remote=37890' '--plugin=streamdev-server -r /usr/share/vdr/streamdev/externremux.sh ' '--plugin=sc '"
LANG=de_DE.utf8
LC_COLLATE=


    Allerdings muss ich dazu sagen, dass ich vorm letzten Update die VDR-Start-Unit selbst geschrieben hatte. Die sah in etwa so aus wie die Ausgabe hier. Und obwohl --plugin=sc an erster Stelle stand, hatte ich dasselbe Problem. Ich nehme daher stark an, dass die angegebene Reihenfolge der Plugins keine Rolle für das Ladeverhalten der Plugins durch vdr spielt.


    Zitat von jsffm

    Kann es sein, dass Du das alte und das neuere böse plugin parallel lädst? Du brauchst nur eins von denen.


    Nein, da hab ich schon drauf geachtet.


    Mit dem neueren "bösen" Plugin hab ich allerdings auch so meine Probleme. Da krieg ich permanent den Fehler:


    Das Problem wurde hier und hier schon mal adressiert. Das Problem wurde damit als gelöst gekennzeichnet, in dem der Socketmodus deaktiviert wurde. Leider tritt das Problem bei mir im Netzwerkmodus auf.

  • [solved] VDR - Wait for devices (alt: Plugin-Reihenfolge)

    Zitat von seahawk1986

    Wie startest du denn den VDR?


    Danke, systemctl. cat ... kannte ich noch nicht. Man lernt doch nie aus.



    Die Plugins werden aktiviert über:

    Code
    eselect vdr-plugin list
Available VDR plugins:
  [1]   dvb**zensiert**
  [2]   zensiert *
  [3]   streamdev-client
  [4]   streamdev-server *
  [5]   svdrpservice *
  [6]   vdrmanager *
  [7]   vnsiserver *
  [8]   xineliboutput *


    Wenn ich über vdr-sxfe (xineliboutput) in die Plugin-Einstellungen reingeh, steht das XX-Plugin an der letzten Stelle. Aber die Reihenfolge ist irgendwie immer unterschiedlich.

  • [solved] VDR - Wait for devices (alt: Plugin-Reihenfolge)

    Guten Abend,


    ich kann mich dunkel daran erinnern, dass Fragen zu einem gewissen Plugin nicht erwünscht waren. Ich probier's trotzdem mal. Falls unerwünscht, dann bitte den Thread einfach löschen (und mir evtl. 'ne PN schreiben).


    Ich nutze vdr als Backend in Kodi. Die Verbindung zwischen vdr und Kodi stelle ich mit dem VNSI-Server her. Dabei nutze ich auch PayTV-Sender.


    Starte ich jetzt den HTPC, dann funktionieren nur die FreeTV-Sender. Sämtliche verschlüsselte Kanäle werden beim Aufruf als nicht verfügbar angezeigt. D.h. nicht die Entschlüsselung schlägt fehl, sondern die Kanäle sind einfach blockiert und nicht verfügbar. Starte ich vdr neu, funktioniert's (systemctl restart vdr). Ab dem 2. VDR-Start funktionieren alle Sender auch, wenn der HTPC für ein paar Stunden ausgeschaltet wird. Nur wenn ich am nächsten Tag (keine Ahnung, wieviel Stunden Pause notwendig sind) den HTPC wieder hochfahr, dann hab ich wieder das o.g. Problem.


    Jetzt könnte man dahinter die Ladereihenfolge der Plugins vermuten. Regeln konnte man das mit der order.conf. Aber so, wie ich aus Tante Google rausquetschen konnte, war die order.conf yavdr-spezifisch (ich nutze ein reines Gentoo) und ist mittlerweile obsolet. Den Quelltext von VDR hab ich ebenfalls mal durchgegrept, ohne jedoch den Suchbegriff "order.conf" überhaupt zu finden. Von daher gehe ich aus, dass es die order.conf im Vanilla-VDR nicht gibt.


    Daher die Frage:
    Wie kann ich den VNSI-Server dazu bewegen, dass er erst startet, wenn das sc-Plugin geladen und initialisiert ist?


    Version VDR: 2.3.2 (das Problem bestand aber auch schon mit VDR-2.2.x)
    VNSI: Git-Version
    Kodi: 17.0_rc3-r2

  • VDR 2.3.2 - Compilieren unter Gentoo

    Hab ebenfalls das USE-Flag "vanilla" gesetzt und die 2.3.2 erfolgreich compilieren könnnen - mit Systemd-Unterstützung.


    Mit der 2.2.x hatte ich mein eigenes Startscript. Die 2.3.2 mit der mitgelieferten Systemd-Unit funktioniert klasse. Vielen Dank für die ganze Arbeit.


    Den zusätzlichen Gentoo-Patch hab ich im Übrigen nicht vermisst. Aber ich verwende VDR sowieso ausschließlich als Backend für Kodi.

  • VDR 2.3.2 - Compilieren unter Gentoo

    Zitat von fnu

    Sowas gehört bitte nicht in einen Announce/News Thread, bekommt sowieso schwerlich jemand mit, sondern in einen passenden bzw. am Besten in einen eigenen Thread.


    Sorry, hast natürlich Recht. Danke fürs Verschieben.


    Zitat von 3PO

    Verwendest Du wirklich diesen Scheißdreck?


    Ja, und ich hatte Gentoo schon vor vielen Jahren umgestellt, als Systemd noch gar nicht richtig unter Gentoo unterstützt wurde.


    Aber die Diskussion würde wohl eher in einen Flamewar ausarten. Lassen wir's einfach dabei, dass ich Poetterings Produkten sicherlich sehr kritisch gegenüber steh, aber nach sehr ausgiebiger Überlegung für mich viele Vorteile von Systemd gefunden hab.

  • VDR 2.3.2 - Compilieren unter Gentoo

    Guten Abend,


    hab grad versucht, die 2.3.1 zu compilieren und bin daran gescheitert. Der Grund könnte u.a. Systemd-232 sein, denn die Fehlermeldung lautete:


    Code
    Package libsystemd-daemon was not found in the pkg-config search path.
Perhaps you should add the directory containing `libsystemd-daemon.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libsystemd-daemon' found


    Jetzt hab ich im Changelog auf der ersten Seite gesehen, dass das in der 2.3.1 gefixt wurde.


    Leider hab ich bisher kein Ebuild für die 2.3.2 entdecken können. Die Umversionierung hat nicht funktioniert, da in der 2.3.1 noch diverse Patches enthalten sind.


    • vdr-2.3.1_gentoo.patch


    • extpng-vdr-2.3.1-gentoo-edition-v3.patch.bz2


    Brauch ich die Patches noch, oder sind die in der 2.3.2 schon integriert? Gibt's vielleicht schon irgendwo ein Ebuild?