Ich stelle folgende Frage in den Raum:
.. warum MUSS der vdr ( Core ) immer laufen ?
Schau jemand ununterbrochen fern ?
Ich stelle folgende Frage in den Raum:
.. warum MUSS der vdr ( Core ) immer laufen ?
Schau jemand ununterbrochen fern ?
Ich habe es gerade bauen lassen: https://launchpad.net/~yavdr/+archiv….series_filter=
Funktioniert - besten Dank für die wie immer perfekte Unterstützung.
Hallo,
.. wie immer ist das mit yaVDR ansible einfach nur ein Genuss.
Noch nie hatte ich ein derart smoothes VDR Ergebnis mit den Beeren.
Ich möchte der Einfachheit halber meine überbezahlten Intel PC's in Rente schicken - dazu fehlt mir nur eine Kleinigkeit:
für den Schnitt am Server würde es das remoteOSD Plugin brauchen, kann man das bitte ins PPA noch aufnehmen ?
Besten Dank
Moi,
..Server mit WakeUp oder always on ?
Also nach den Änderungen von kamel5 (besten Danke dafür) funktioniert das bei mir problemlos ([yavdr ansible] und zeigt natürlich den Timer am Server mit dem richtigen Hiostnamen an).
Danke für den Tipp!
Frage: glaubst oder weisst du, ob das friktionsfrei für alle meine NVidia PC-Clients einsetzbar ist (auch ION2)?
Ich möchte in der Lage sein setup.conf files im einfachsten Fall zu kopieren und keine Sondergeschichten für jeden Client zu fahren.
Ehrlich gesagt fehlt mir einfach die Zeit dazu
Ich bin jetzt schon sehr glücklich mit yavdr ansible (das ist echt ein toller Ansatz mit Ausbaumöglichkeiten) eine moderne Umgebung am Laufen zu haben mit nur einem stromsparenden Server - ich habe tatsächlich einige Anläufe genommen um dahin zu kommen (und dass Alexander so schnell die fehlenden Plugins nachgeliefert hat, hat eigentlich bestätigt, dass das der richtige und endgültige Ansatz für mich ist => es funktioniert produktiv sehr, sehr gut und auch meine bessere Hälfte kommt mit den kleinen Unstimmigkeiten, die jetzt nicht yavdr ansible geschuldet sind, klar).
Standard yavdr-ansible client: softhddevice bei jedem PC Client
Ich bin soweit produktiv mit allen Clients und dem Server auf yaVDR ansible.
Folgende Beobachtungen habe ich gemacht:
Client mit Asrock 3150 / Zotac GT730 aus Signatur: ich musste auf den 340er Treiber ausweichen, der 390er hat im OSD jede Menge Fehler (Doppeleinblendungen / Verschiebungen) verursacht.
EPGSync: in alter Manier hatte ich Jetzt/nächste zuerst und kanalweise Synchronisation eingestellt - Ergebnis war, dass nur jetzt/nächste synchronisiert wurde -> alles auf default (aber ich hatte zuvor auch die EPG-Daten auf Server und Client gelöscht) -> funktioniert jetzt.
TVGuideNG: das Peering der Timer scheint in mehrfacher Hinsicht nicht korrekt zu funktionieren:
1.) Anlage Timer: Timer wird ohne Fehler angelegt, aber im Gegensatz zum VDR-Peering Standard nicht korrekt am Server (obgleich der Servername beim Timer drinnen steht) - versucht man den Timer über TVGuide zu bearbeiten kommt der Fehler (hab's nicht im Kopf "Timer_0@.." konnte nicht bearbeitet werden?) - Workaround: im VDR Timer Menü den Timer editieren: deaktivieren - Ok drücken, aktivieren - OK drücken - wird dann korrekt am Server angelegt und aktiviert (funktioniert problemlos mit den Standard VDR-Möglichkeiten).
2.) Timer, die in TVGuideNG oder direkt gelöscht werden sind noch sehr lange Zeit dort sichtbar (10 Minuten ?)
Was ich noch machen muss ist ein "Wait for CAM" in den VDR Start einzubauen.
Der Server läuft bei mir immer, die DVB Treiber und VDR Dienste werden per WoL Paket von den Clients gestartet - einer von den Clients ist dabei schneller als der Server mit Start der Dienste / Treiber laden / CAM Initialisierung (der langsamste Teil) und dann hagelt es halt viele Fehlermeldungen (initialer Kanal ist auf einen freien Kanal eingestellt -> Kanal nicht verfügbar -> VDR am Client springt automatisch auf Kanal 1 [ist bei mir als Ösi natürlich ORF] - da ist das CAM noch nicht bereit -> sehr sehr viele Fehlermeldungen im Log (invalid MTD number (7) in PID 1920 (0780) z.B.).
Beide Plugins funktionieren aus meiner Sicht einwandfrei - Weltklasse.
Einer Produktivsetzung meiner erneuerten VDR-Landschaft auf Basis yavdr ansible steht nun nichts mehr im Weg (ausser fehlender Zeit).
Vielen Dank für diese tolle Arbeit.
Also damit hätte ich nicht gerechnet
Und das an einem solchen Tag !
Sobald es ein bißchen ruhiger wird (in ein paar Tagen), werde ich das sofort testen und Bescheid geben.
Genieß die Feiertage und besten Dank.
Bei mir steht eine Kompletterneuerung an (ich bin noch auf einer gut funktionierenden yaVDR 0.5) Umgebung unterwegs und habe mir deshalb yavdr ansible angesehen - einfach, weil es ein tolles Konzept ist und auch schon sehr, sehr gut funktioniert - einfach Spitze.
Was habe ich bisher versucht: Server auf Basis J3160 Basis, Digital-Devices Cine S2 6.5 + DuoFlex + Single CI + Mascom alphacrypt classic + ORF Karte) - diverse Serverdienste laufen permanent - VDR Service + Treiber für DD-Karten (Stromverbrauch) werden per WoL Paket gestartet - funktioniert.
Test-Client auf Basis Asus AT5IONT-I (Nvidia ION -legacy!) - Einrichtung hat perfekt funktioniert (inkl. Nachinstallation IRMPLircd, weil das zuerst verwendete Kabel offensichtlich nur ein Ladekabel war).
Jetzt zu meinen Fragen:
Am Server installiert: Plugin SVDRPOSD
Was ich jetzt so nicht verstehe (sorry, wenn ich da was überlesen habe): das Gegenstück remoteOSD gibt es nicht im Repository ? - und zu meinem Pech auch kein EPGSync ? Wenn ich das richtig verstehe, kann ich ja nicht den EPG des Servers (ohne Internetabrufe, also nur die VDR Stream EPGDaten) in den EPGD verpflanzen und mit EPG2VDR distributieren ?.
Ich habe auch das OSD2Web als temporären Ersatz für das RemoteOSD versucht - aber das entspricht nicht meinem Ansatz.
Kann mir wer den Schubs in die richtige Richtung verpassen ?
Schöne Feiertage
Hi,
.. ich habe nichts zusätzlich installiert.
Treiber runtergeladen, entpackt, Firmware kopiert.
Wenn Kernel gewechselt: make distclean -> make all -> make install (mit entsprechenden Berechtigungen) -> reboot
dmesg Output sollte sein:
[ 2.475534] WARNING: You are using an experimental version of the media stack.
[ 2.475536] As the driver is backported to an older kernel, it doesn't offer
[ 2.475536] enough quality for its usage in production.
[ 2.475537] Use it with care.
[ 2.475538] Latest git patches (needed if you report a bug to linux-media@vger.kernel.org):
[ 2.475539] 296da3cd14db9eb5606924962b2956c9c656dbb0 [media] pwc: poll(): Check that the device has not beem claimed for streaming already
[ 2.475540] 0bf0f713d6e6b9f1c510d598c29ac17812a4eea5 [media] vivi: let vb2_poll handle events
[ 2.475541] 95213ceb1b527b8102c589bd41fcb7c9163fdd79 [media] videobuf2-core: also test for pending events
[ 2.509161] cx23885 driver version 0.0.3 loaded
[ 2.509216] cx23885 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 2.510023] CORE cx23885[0]: subsystem: 4254:0952, board: DVBSKY S952 [card=36,autodetected]
Display More
D.h. bei Dir ist der Treiber nicht gelandet ...
Remote OSD vom Server ist auch im real headless Betrieb möglich.
Plugin am Server: svdrposd
Plugins am Client: svdrpservice und remoteosd (das erzeugt am Client einen bezeichnenden Eintrag mit Namen: "Server Menü")
Dazu dann noch femon am Client korrekt konfigurieren, plugin remotetimers..
Nach Anleitung geflasht, Flash Programm nicht beendet -> USB Kabel abgezogen-> Reset, Test - schwarzes Display -> Neustart Display und über Menü ausschalten (kurzer Druck auf M-Taste, Ausschalten wählen) -> anstecken an USB Port -> Reset, Menü in gewohnter Reihenfolge drücken -> Channel 1 wird grün -> Execute und bei Auswahl Baustein <ESC> gedrückt -> nimmt automatisch 25P16 -> flashen -> an USB angestöpselt lassen -> Reset durchgeführt -> 2 Sekunden M-Taste -> Bingo: BSOH
Gleicher Zustand bei mir (Einfrieren nach Flashen Landscape und Versuch in den BSOH zu gelangen).
Aber mit 2 mal hintereinander Flashen hats dann funktioniert.
Ich konnte das nach Zurückflashen auf die Originalfirmware nochmals verifizieren.
Hi,
.. der Unterschied ist möglicherweise, dass ATV+ kein ORF Service ist und damit unter Umständen nicht die gleichen Gültigkeitsdaten haben muss.
Hast Du eine Chance deine Karte mal in einen Satreceiver zu stecken und die Gültigkeitsdaten zu überprüfen oder updaten zu lassen um diese Fehlerquelle auszuschließen ?
Nur so ins Blaue geraten: hast Du mal versucht die Gültigkeitsdaten auf der ORF-Karte zu überprüfen?
Das würde die langen Wartezeiten erklären, bis ATV dann mal geht...
Hallo,
.. sollte eigentlich funktionieren.
.. evt. spielen die Berechtigungen beim eingehängten Dateisystem nicht mit ?
Möglicherweise könnte man sich ramlog näher ansehen. Ich habe es noch nicht selbst ausprobiert, wäre aber bei einer CF evt. brauchbar.
Hast Du Dir /etc/init/vdr-net.conf mal angesehen (aber mein Stand ist schon ca. 2 Wochen alt)?
Achtung: etherwake ist im Standard so nicht vorhanden !
Bei mir sieht es in etwa so aus - und da lese ich sleep 20
start on started autofs and started vdr
task
script
/usr/bin/etherwake 1c:6f:65:2b:c6:f1
sleep 20
if [ -e /etc/auto.net.yavdr ]; then
mountpoints=`cat /etc/auto.net.yavdr | awk '!/^#/ && /fstype/ {print $1}'`
if [ -n "$mountpoints" ]; then
until status autofs | grep -q process ; do sleep 1 ; done
for mountpoint in $mountpoints; do
touch /net.yavdr/$mountpoint/. &> /dev/null || /bin/true
done
touch /srv/vdr/video.00/.update
fi
fi
end script
Display More