Beiträge von 12-monkeys

Ich hab's jetzt mit dem timer hinbekommen. War sogr einfacher als gedacht.

Meine Original-Datei /etc/systemd/system/vdr.service wollte ich behalten, daher habe ich eine zweite erstellt.

Vorgehensweise:

• Die Datei /etc/systemd/system/vdr.service nach /etc/systemd/system/vdr-timed.service kopieren
  (falls nicht vorhanden, /usr/lib/systemd/system/vdr.service kopieren)
• In der Kopie den Abschnitt [Install] löschen
• Neue Datei /etc/systemd/system/vdr-timed.timer erstellen (Inhalt siehe unten)
• systemctl daemon-reload
• systemctl disable vdr.service
• systemctl enable vdr-timed.timer (wichtig: den timer, nicht den service)
• rebooten

Wichtig: Es dürfen nie gleichzeitig vdr.service und vdr-timed.timer enabled sein !!!

Inhalt von /etc/systemd/system/vdr-timed.timer:

[Unit]
Description=Startup timer for Video Disk Recorder


[Timer]
OnBootSec=5min


[Install]
WantedBy=timers.target

Das ist die angelegte Datei:

[Unit]
Wants=dev-dvb-adapter0-demux0.device
After=dev-dvb-adapter0-demux0.device
Wants=dev-dvb-adapter0-dvr0.device
After=dev-dvb-adapter0-dvr0.device
Wants=dev-dvb-adapter0-frontend0.device
After=dev-dvb-adapter0-frontend0.device
Wants=dev-dvb-adapter0-net0.device
After=dev-dvb-adapter0-net0.device
Wants=dev-dvb-adapter1-demux0.device
After=dev-dvb-adapter1-demux0.device
Wants=dev-dvb-adapter1-dvr0.device
After=dev-dvb-adapter1-dvr0.device
Wants=dev-dvb-adapter1-frontend0.device
After=dev-dvb-adapter1-frontend0.device
Wants=dev-dvb-adapter1-net0.device
After=dev-dvb-adapter1-net0.device

Also wenn es nicht mit vertretbarem Aufwand zu lösen ist, werde ich halt als Notlösung doch den Weg über systemd-timer gehen und den VDR einfach immer 5 min. nach dem Booten starten.

Zitat von Copperhead

Das Skript einmal ausführen und fertig. Spätestens bei nächsten Reboot weiß systemd Bescheid.

Hm ... hat leider nicht funktioniert. Gerade noch mal neu gebootet, und wieder "No Signal".

Es hat auch nicht geholfen, das direkt in die Datei vdr.service einzutragen. Anscheinend braucht er noch etwas zum Starten.
D.h. ich muss da weiter forschen. Aber erst morgen, ich muss jetzt ins Bett.

Dir schon mal vielen Dank für die Hilfe bisher.

Zitat von Copperhead

Theoretisch: Ja. Praktisch: Nicht unbedingt. Also nur wenn die neuen Karten nicht langsamer sind als die vorhandenen.

OT: Ich bin teilweise echt verwundert, wie viele Tuner ihr braucht. So toll ist doch das deutsche Fernsehprogramm überhaupt nicht.

Naja, die Frage war mehr zum Verständnis der Sache.

Ah, Mist !

Das muss beim Umzug auf die neue Platte (schon ne Weile her) verlorengegangen sein !

Man muss dazu sagen, dass der Anlass für dem Umzug ein Plattencrash war und ich einfach alles, was noch zu retten war, rüberkopiert und mit einem (nicht mehr ganz aktuellen) Backup ergänzt habe. Dann alle Pakete neu installiert und in den vielen Meldungen ist das dann untergegangen. Ich hätte mir also doch mehr Zeit nehmen sollen ...

Muss ich das noch irgendwo eintragen oder sollte systemd das automatisch über eine Namenskonvention finden ?
Nur die Datei allein hat leider nicht geholfen.

Und angenommen, ich würde mal noch mehr Geräte an die Octopus Bridge stecken, muss ich dann das vdr-gensddropin noch mal machen ?

Hallo,

Schon seit einiger Zeit (nicht von Anfang an) habe ich das Problem, dass der VDR immer nach dem Booten kein Signal hat. Auch nicht wenn ich eine Stunde warte - hab's gestern mal ausprobiert.
Wenn ich dann

systemctl restart vdr

aufrufe, klappt es dann.

Ich habe das auf die lange Bank geschoben, weil ich den VDR normalerweise monatelang durchlaufen lasse und da hat's mich nicht genug gestört, um es anzugehen.

In letzter Zeit habe ich aber öfter rebootet, unter anderem das Mainboard getauscht, und dann ein bisschen am Grundsystem getunt, bis wieder alles lief. Und da ich nun eh am Rumfummeln war, könnte man das doch auch mal fixen ...

So sieht mein unit file /etc/systemd/system/vdr.service aus:

[Unit]
Description=Video Disk Recorder
After=o*cam.service
After=sundtek.service
After=xlogin@vdr.service
After=dev-ddbridge-card0.device


[Service]
Type=notify
ExecStart=/usr/bin/vdr
Environment=TERM=xterm
Restart=on-failure
RestartPreventExitStatus=2


[Install]
WantedBy=multi-user.target

also eigentlich die Standard-Version, wie sie auch in /usr/lib/systemd/system/vdr.service steht. Ich habe lediglich das

After=dev-ddbridge-card0.device

hinzugefügt, um mal auszuprobieren, ob vielleicht die Karte zu lange braucht, um zu initialisieren.

Ich habe auch noch ausprobiert, den service zu disablen und den VDR immer manuell zu starten. Das hat auch geklappt.
-> Es ist also nicht so, dass immer der erste Start schiefgeht, sondern der Start muss nur spät genug sein.

Und bevor ich jetzt anfange, mich in systemd-timer einzulesen, dachte ich, ich frag mal hier nach, ob man es einfacher hinkriegt.

Noch etwas Info zu meinem System:

• Tuner von Digital Devices
• XFCE als Desktop
• LXDM als Login-Manager mit Auto-Login
• und eine kleine Besonderheit in der VDR-Konfig: Der läuft unter meinem user.

Ist solch ein Problem bekannt ? In der SuFu habe ich nichts gefunden.

Vielen Dank und noch mehr Grüße,
12-Monkeys

Copperhead

Ich wollte mich hier nochmal für Dene Zeit und Hilfe bedanken und einen Vorschlag machen:

Was meinst Du dazu, wenn ich an dem Wiki-Artikel http://vdr-wiki.de/wiki/index.php/VDR4Arch ein bisschen was dazu schreibe ?
Mir schwebt da zum Einen die Client/Server Geschichte vor (im Moment steht da ja nur: iss nich) und zum Anderen einen Hinweis zum Start des VDR als bestimmter User (das mit der Gruppenzugehörigkeit).

Ich hab ja bei der Sache auch was gelernt, und so kann ich es weitergeben.

Außerdem hab ich jetzt nochmal mit der remote=ip:port Angabe rumexperimentiert. Man kann die IP nämlich doch ganz weglassen, nur der Doppelpunkt darf nicht fehlen. Muss man auch erst mal drauf kommen ...

Danke und Gruß,
Markus

Ja, Timer klingt interessant. Werd ich mir mal zu Gemüte führen.

Meine vorige Nachricht war ja auch nur zur Erläuterung, warum das Ganze (manchmal) doch sinnvoll ist.

Gruß,
Markus

Zitat von seahawk1986

Ich bin der Meinung dass das keinen wirklichen Vorteil bringt, man kann doch einfach sinnvolle Abhängigkeiten zwischen den Diensten schaffen, die benötigten Delays können sich auch mit jeder Änderung an der Systemkonfiguration ändern.

Naja, das mit den Abhängigkeiten ist aber nicht immer so einfach.
Beispiel:
Ich habe mein Laptop so eingestellt, dass ich beim Hochfahren direkt angemeldet werde. Die Kiste ist durch dm-crypt schon geschützt, da brauch ich nicht noch nen Login.
Dort ist unter anderem auch Dropbox installiert. Das synchronisiert sich beim Start erst mal und erzeugt so richtig viel I/O, man meint die Platte hebt gleich ab ...
Systemd weiß aber nix von Dropbox, weil es vom XFCE Session Manager gestartet wird. Daher kann ich da auch keine Abhängigkeiten eintragen.
Dann habe ich noch ein PostgreSQL, einen Apache, und ein paar weitere I/O-lastige experimentelle Dienste, die ich aber normalerweise nicht gleich nach dem Booten brauche (aber auch nicht alle manuell starten möchte). Da wären 5 oder 10 Minuten delay wirklich hilfreich, damit die nicht gleichzeitig mit Dropbox starten. Unter den systemd-Diensten könnte man zwar wieder Abhängigkeiten definieren (Apache ist bereits abhängig von PostgreSQL), aber die anderen haben technisch nichts miteinander zu tun, also sollten sie auch nicht künstlich abhängig gemacht werden. Und wenn ich einen davon mal entferne, müsste ich alle anderen wieder nachziehen.

Gruß,
Markus

Zitat von 12-monkeys

Nach dem Booten habe ich grundsätzlich erst mal kein Signal. Ich muss den vdr.service ein mal stoppen und wieder starten, dann ist es da.

OK, jetzt tut's. Ich hatte noch vergesen zu erwähnen, dass ich den VDR unter meinem login-user laufen lasse. Das ist mir auch recht wichtig, wegen der Berechtigungen der aufgenommenen Dateien. Mein VDR soll ja am Ende headless sein, und ich will die Aufnahmen dann über NFS mit VLC anschauen oder mit ProjectX / Cuttermaran weiterverarbeiten. Außerdem lasse ich da auch noch Skripte drüberlaufen, die das Zeugs umbenennen und aus dem Aufnahme-Verzeichnis raus verschieben. Das geht alles am einfachsten, wenn alle Dateien mir "gehören".

Jetzt hab ich den User in die Gruppen "video" und "audio" aufgenommen, daran lag's...

Allerdings wäre ich neugierig zu erfahren, warum die Gruppen-Zugehörigkeit nur beim automatischen Start nach dem Booten eine Rolle zu spielen scheint, aber es auch ohne geht wenn ich den VDR mit systemctl noch mal manuell stoppe und starte.

Zitat von Copperhead

Hast du den Server mal angepingt? Wähle mal einen höheren Port. Ich bin mich nicht sicher, inwieweit Ports für root reserviert sind. Ich nutze für sowas immer Port 65000

Beim --remote= parameter in /etc/vdr/conf.d/50-xineliboutput.conf hatte ich die IP nicht mit eingetragen ... jetzt tut's.

Aber auch hier noch zwei Fragen:

1.
Habe ich das in dem Kommentar falsch verstanden ? Da steht "--remote=<ip>:<port> (default is all interfaces)" daher dachte ich, ich kann den ip-Teil weglassen.

2.
In meiner Zeile steht jetzt also folgendes drin:

--remote=192.168.1.6:37890

Und die IP bleibet wohl auch recht lange die selbe, weil der Rechner ja durchläuft und daher sein DHCP-Lease vermutlich jedes mal neu zugeteilt kriegt.
Was aber, wenn sich die IP doch mal ändert ? Weil ohne das 192.168.1.6: geht's ja nicht.
Kann man das auch anders ausdrücken ?

Danke und Gruß,
Markus

Zitat von seahawk1986

Wenn der Rechner sowieso durchläuft genügt doch ein kontinuierlicher Abgleich über ntpd.

Eigentlich schon, aber ich hätte halt gerne sichergestellt, dass der vdr prozess beim Start eine korrekt gestellte Uhr vorfindet. Ich hab nämlich auch schon die Erfahrung gemacht, dass der vdr durcheinander kommt, wenn die Uhrzeit um mehr als nur wenige Sekunden geändert wird. Daher die Idee, den Start zu verzögern.

Zitat von seahawk1986

Man muss es nur richtig machen - man kann auch mit Systemd unsinniges Verhalten abbilden

Kannst Du mir nen Tipp geben, wie ich mit dem systemd einen Dienst verzögert starte ?

So unsinnig ist das Verzögern von Diensten übrigens gar nicht. Wenn man nach systemd delay (oder ähnlichem) sucht, findet man einige Anfragen dazu. Dabei geht es dann auch um Dinge wie "Dienst erst starten, wenn das System (nahezu) idle ist".

Noch eine allgemeine Anmerkung zur nachgehenden Uhr ... Dieses Mainboard ist da sicherlich ein besonders krasser Fall, aber ich bin seit meinem ersten PC daran gewöhnt (und das ist schon ne ganze Weile her), dass immer der PC die mit Abstand ungenaueste Uhr im Haushalt ist. Sogar der billigste Radiowecker läuft genauer. Vor DSL und den Internet-Flatrates habe ich mir mit einem DCF-Empfänger am Druckerport beholfen.

Gruß,
Markus

Hallöchen,

Danke für die schnelle Antwort. Bei mir wird's mit dem Ausprobieren nicht so schnell gehen
Die Konfig Dateien in /etc/vdr/conf.d habe ich schon gesehen, aber ich war nicht sicher, ob die ausreichen. Dann werd ich da noch mal genauer reinschauen.

Mein VDR-Rechner ist ne Dualboot-Kiste, und momentan habe ich wieder Ubuntu gebootet. Da da noch weitere Dienste drauf laufen (mit z.T. schlecht unterbrechbaren, lang laufenden Jobs), muss ich wieder auf einen passenden Moment warten und dann auch gerade zuhause sein ... gut möglich, dass es wieder erst an einem Sonntagnachmittag klappt.

Auf ubuntu gab es ja noch das runvdr skript. Da war es natürlich ganz einfch, ein sleep 5m einzubauen. Ich hab nur bei einem anderen Dienst schon gemerkt, dass systemd solche Spielchen nicht mag. :-/

Meine Mainboard-Batterie ist übrigens fast neu (an die dachte ich auch als erstes). Und ntpdate setzt die Zeit ja nur einmalig. Ich habe aber auch mal ermittelt, dass die Uhr auf dem Mainboard deutlich nach geht, so ca. 17 Sekunden pro Tag. Daher brauche ich etwas, das die Uhr immer wieder korrigiert. Die Kiste läuft nämlich 24/7 durch. Ich könnte natürlich mal ausprobieren, ob ich ntpdate und ntpd nehmen kann.

Noch eine kleine Erfolgsmeldung:
Ich habe es auch geschafft, den vdradmin-am vom ubuntu-System rüberzuziehen. Momentan gefällt mir der noch besser als das live-Plugin.

Danke und Gruß,
Markus

So, ich bin jetzt endlich dazu gekommen, auch den VDR-Server auf Arch-Basis zu installieren. Grundsätzlich läuft es, nur ein paar kleine Schwierigkeiten habe ich noch:

1)
Nach dem Booten habe ich grundsätzlich erst mal kein Signal. Ich muss den vdr.service ein mal stoppen und wieder starten, dann ist es da.
Könnte das vielleicht mit meinem Tuner von Digital Devices (DVB-C) zu tun haben ? Wartet der vdr.service nicht auf das Tuner-Device ?

In meinem Fall wäre es sowieso vorteilhaft, wenn ich den Start des vdr.service nach dem Booten noch so 2-3 Minuten rauszögern könnte. Das Mainboard hat ein bisschen Probleme mit der Uhrzeit, d.h. es wäre gut wenn der vdr.service erst startet, wenn der ntpd.service die Zeit mal aktualisiert hat.
Die Zeit nach dem Tuner zu stellen ist auch keine Lösung, das hab ich früher mal probiert. Denn immer wenn es mal eine Störung beim Empfang gibt, wird die Uhrzeit auf "irgendwas beliebiges" gestellt, was den vdr.service dann dazu veranlasst, alle EPG-Daten und Timer zu verwerfen.

2)
Mit dem vdr-sxfe komme ich vom Client aus nicht auf den Arch-basierten VDR. Ich kriege immer "Can't connect to tcp://vdr:37890" (mein VDR-Rechner heisst "vdr"). Gestarted von der Kommandozeilt mit

vdr-sxfe xvdr://vdr:37890

Lokal vom VDR-Rechner aus klappt es, und vom Client-Rechner aus auf den Ubuntu-VDR hat es ja auch geklappt. D.h. die einzelnen Komponenten sind jeweils funktionstauglich, nur wollen sie nicht zusammen arbeiten.
Die Dateien /var/lib/vdr/plugins/plugin.xineliboutput.conf und /var/lib/vdr/plugins/xineliboutput/allowed_hosts.conf habe ich (wie fast alle .conf Dateien in /var/lib/vdr/) von der Ubuntu-Version übernommen. Dabei habe ich alles, was bei ubuntu in /etc/vdr stand und von /var/lib/vdr nur dorthin gesymlinked war auch gleich nach /var/lib/vdr rübergenommen.
Aber irgend eine Kleinigkeit muss ich wohl vergessen oder verwürfelt haben.

Kommt Dir auf Anhieb ein Verdacht, was das typischerweise sein könnte ?

Danke und Gruß,
Markus

So, ich hab gleich mal das Frontend ausprobiert und es läuft prima zusammen mit dem Ubuntu-basierten VDR.
Zumindest wenn man es ohne -width und -height Parameter aufruft. Mit diesen Parametern (stimmen mit der Größe auf dem VDR überein) stürzt es sofort ab.

Jetzt kann ich natürlich nicht sagen, ob es an der Version oder dem Zusammenspiel mit der Version auf dem VDR oder an Deinem Paket liegt (wobei ich letzteres für unwahrscheinlich halte). Ich würde vorschlagen, da erst mal keine Zeit rein zu stecken. Zumal ich es auch ohne die Parameter starten und dann größer ziehen kann.

Bis ich den VDR umstelle dauert noch ein bisschen, ich gebe dann Rückmeldung.
Für den Moment ist mir mit dem funktionierenden Client auf Arch schon sehr weit geholfen: Wieder eine Anwendung weniger, für die ich noch Ubuntu booten muss. Bleibt nur noch eine einzige, die ich wirklich nur ganz selten brauche.

Vielen Dank nochmal dafür.

EDIT:
Doch noch ne Kleinigkeit:
Vorhin hatte ich vdr-sxfe direkt aus der shell gestartet, daher ist es mir nicht gleich aufgefallen:
Das Icon, das in der .desktop Datei eingetragen ist, fehlt.
/usr/share/icons/xineliboutput-sxfe.svg

Eilt aber nicht, ich hab's mir erst mal vom VDR geklaut

Danke und Gruß,
Markus

Zitat von Copperhead

Nein. Das ist durchkompiliert. Ich bin kein Freund von DKMS.
Ich finde auf einem VDR sollte keine komplette Buildumgebung installiert sein, nur weil man einen Treiber nutzen möchte, der nicht im Kernel integriert ist.

Ist mir auch recht

Muss ich dann bei Kernel-Updates was beachten ?

Ach so ... das xineliboutput Paket enthält das sxfe ?
An die Möglichkeit hatte ich nicht gedacht.

Bei pacman -Sl vdr4arch kam halt kein sxfe, daher war ich etwas verwirrt ...
Man muss dazu noch sagen, dass ich bisher das Arch nur auf dem Client installiert habe, und das auch vorerst nur dual-boot mäßig (also Teilzeit) nutze. Auf dem VDR ist noch kein Arch drauf. Daher habe ich noch keines der Pakete installiert. Planungs-Phase halt ...

Wenn Du die Pakete aufteilst (und dafür schon mal vielen Dank!), wäre es hilfreich, wenn das standalone sxfe keine Abhängigkeiten zu den anderen VDR-Paketen hat. Ich will ja auf dem Client keinen vollständigen VDR installieren.

Bei der Gelegenheit noch ne andere Frage:
Mein Tuner ist von digital devices. Bei pacman -Sl vdr4arch wird dafür ein Treiber aufgelistet. Ist das dann ein DKMS Paket ?

Danke und Gruß,
Markus

Hallo zusammen,

Ich plane gerade den Umstieg von einem Ubuntu basierten System auf ArchLinux. Jetzt habe ich im Archiv den längeren Thread mit der Ankündigung von vdr4arch durchgelesen.

Dabei bleibt für mich noch ein offener Punkt:

Bei meinem jetzigen System benutze ich das xineliboutput plugin und auf dem anderen Rechner dann vdr-sxfe als Client. Laut dem Issue-Tracker auf github ist der Autor von vdr4arch nicht an xineliboutput interessiert und er bevorzugt softhddevice.
Die Frage ist jetzt, kann ich mit dem softhddevice auch so eine Client/Server Lösung haben wie mit xineliboutput / vdr-sxfe ?
Oder gibt's ne andere Alternative ?

Danke und Gruß,
Markus

Es ist ein Elitegroup ECS A785GM-M7, Sockel AM3.

3PO
Also eine PCI-Riser hatte ich noch nie in der Hand
Hab gerade mal in der Bucht gecheckt. Zumindest preislich vertretbare 1-auf-2-Riser gibt es leider nur so herum, dass die PCI-Karten dann in Richtung der CPU liegen. Und das dürfte auf dem mATX Board in PCI-Slot 1 Platzmäßig nicht mehr reichen (PCI-1 ist der nähere bei der CPU). Abgesehen davon müsse ich dann das Board aus dem Gehäuse ausbauen, da fehlen ja die Aussparungen.

Und flexible 1-auf-2-Riser habe ich gerade keine gesehen. Nur PCIe auf 2xPCI, die aber für 48 €.

Also bevor ich damit anfange, versuche ich lieber gleich ein anderes Board zu organisieren, wenn's geht erst mal leihweise.

gda
Bei mir war's genau umgekeht: Mit einem T-Stück war der Empfang immer auf beiden Karten schlecht, durchgeschleift war er (vor dem unfreiwilligen Board-Wechsel) soweit OK. Da war auch egal, welche der Karten direkt an der Antennendose und welche am Ausgang der anderen hing. Auf die Signalstärken hatte das nahezu keine Auswirkung (also bei der MK3 war er immer ein gutes Stück besser als bei der anderen).

Ja.

Ging auch gar nicht anders ... die Antennendose ist hinterm Schrank.
Zur Erinnerung: Ich habe ja DVB-C. Beim Betrieb mit mehr als einer Karte wird das Kabel dann durchgeschleift. Bei nur einer Karte ist die dann immer direkt mit der Antennendose verkabelt.

Aaalso ... ich habe jetzt einige Kombinationen ausprobiert. Am interessantesten dürften aber die Varianten mit nur einer Karte sein.

Karte 1 in PCI-Slot 1: Signalstärke 95%
Karte 1 in PCI-Slot 2: Signalstärke 51%

Karte 2 in PCI-Slot 1: Signalstärke 73%
Karte 2 in PCI-Slot 2: Signalstärke 46%

Wobei die Karte 1 die neuere Revision der "Terratec Cinergy DVB-C" ist, nämlich eine MK3.

Also irgendwas stimmt mit PCI-Slot 2 nicht. Ich habe auch den Zusatzlüfter mal weggelassen, da der Motor auf Höhe des PCI-Slots 2 lag. Hätten ja auch Einstrahlungen sein können. Hat aber keinen Unterschied gemacht.
Die Elkos habe ich mir auch angeschaut. Sehen gut aus. Es scheinen auch diese "Solid Capacitors" zu sein, sie sehen zumindest genau so aus wie die auf den entsprechend bezeichneten Mainboards.

Ich probiere mal, ob ich irgendwo ein Board zum Testen ausleihen kann. Bis dahin betreibe ich den VDR mit nur einer Karte. Lieber weniger aufnehmen können, dafür das dann ohne Störungen. Zum Glück liegen seit der letzten Frequenzumstellung fast alle wichtigen Spielfilm-Sender auf einem Transponder.