Beiträge von bronline

  • yavdr ansible

    Danke seahawk1986, das wars gewesen.

    Warum das Script am 20.12. sauber durchlief kann ich nicht nachvollziehen, aber was solls.


    Code
    Die folgenden Pakete werden ENTFERNT:
  python-is-python2
Die folgenden NEUEN Pakete werden installiert:
  python-is-python3

    Wäre es möglich, dieses Paket in die Liste der erforderlichen Pakete in "scripts/install-packages.sh" aufzunehmen?

  • yavdr ansible

    Hallo,


    der Auruf des ansible-playbooks (Gesamtdurchlauf oder nur Rescan) führt aktuell zu einem Fehler.

    Ein erneuter Aufruf mit "-vvv" bringt auch keine weiteren Erkenntnisse.

    Gemäß dem nachfolgendem Traceback, liegt der Fehler in "xrandr_facts.py".


    Das System wurde zuletzt am 20.12. mittels ansible-playbook auf den neuesten Stand gebracht.

    Dabei wurde auch das Display erfolgreich erkannt und konfiguriert.


    Was hat sich seitdem geändert?

    Wo muss ich ansetzen?


    Nutze ubuntu-focal und die Experimental Repositories für vdr und kodi

    VG
    Bernhard

  • yavdr ansible

    Zitat von seahawk1986

    Da wird der /dev/irman Link aber laut der Ausgabe angelegt..

    Beim manuellen Anstecken des atric USB-Empfängers funktioniert es.

    Bei der Erstinstallation mit dem Playbook war der Empfänger bereits eingebaut und hat sich auch als atric USB gemeldet.

    Nach meinem Verständnis, sollte eigentlich in beiden Fällen das gleiche heruauskommen, Der Link sollte angelegt werden.

    Ich kann mir nochmal die Logs von der Installation ansehen, ob mir irgendetwas auffällt.


    VG
    Bernhard

  • yavdr ansible

    Vielleicht hängt der fehlende Link auch mit dem angepassten Playbook zusammen:



    VG
    Bernhard

  • yavdr ansible

    Zitat von seahawk1986

    Kannst du mal den Empfänger abstecken, den udevadm monitor starten und dann den Empfänger wieder anstecken?


    Sorry, hat etwas länger gedauert, bevor ich mich wieder an den VDR setzen konnte.

    Hier die Meldungen zu udevadm monitor -u -p bei entfernen und erneuten anstecken des Empfängers:


    VG

    Bernhard

  • yavdr ansible

    Zitat von seahawk1986

    Dann zeig bitte noch was udev zu dem Empfänger sagt: udevadm info --query=all --name /dev/ttyACM0

    Sorry, die Frage hatte ich übersehen.

    Hier die Ausgabe:


    P: /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3/1-1.3:1.0/tty/ttyACM0

    N: ttyACM0

    S: irman

    S: serial/by-id/usb-Atric_Development_GbR_Atric_IR-Wakeup_USB-if00

    S: serial/by-path/pci-0000:00:1a.0-usb-0:1.3:1.0

    E: DEVLINKS=/dev/serial/by-path/pci-0000:00:1a.0-usb-0:1.3:1.0 /dev/irman /dev/serial/by-id/usb-Atric_Development_GbR_Atric_IR-Wakeup_USB-if00

    E: DEVNAME=/dev/ttyACM0

    E: DEVPATH=/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3/1-1.3:1.0/tty/ttyACM0

    E: ID_BUS=usb

    E: ID_MODEL=Atric_IR-Wakeup_USB

    E: ID_MODEL_ENC=Atric\x20IR-Wakeup\x20USB\x20\x20\x20\x20\x20\x20

    E: ID_MODEL_FROM_DATABASE=7 Series/C216 Chipset Family USB Enhanced Host Controller

    E: ID_MODEL_ID=f844

    E: ID_PATH=pci-0000:00:1a.0-usb-0:1.3:1.0

    E: ID_PATH_TAG=pci-0000_00_1a_0-usb-0_1_3_1_0

    E: ID_PCI_CLASS_FROM_DATABASE=Serial bus controller

    E: ID_PCI_INTERFACE_FROM_DATABASE=EHCI

    E: ID_PCI_SUBCLASS_FROM_DATABASE=USB controller

    E: ID_REVISION=0100

    E: ID_SERIAL=Atric_Development_GbR_Atric_IR-Wakeup_USB

    E: ID_TYPE=generic

    E: ID_USB_CLASS_FROM_DATABASE=Communications

    E: ID_USB_DRIVER=cdc_acm

    E: ID_USB_INTERFACES=:020201:0a0000:

    E: ID_USB_INTERFACE_NUM=00

    E: ID_VENDOR=Atric_Development_GbR

    E: ID_VENDOR_ENC=Atric\x20Development\x20GbR\x20\x20\x20\x20

    E: ID_VENDOR_FROM_DATABASE=Microchip Technology, Inc.

    E: ID_VENDOR_ID=04d8

    E: MAJOR=166

    E: MINOR=0

    E: SUBSYSTEM=tty

    E: TAGS=:systemd:

    E: USEC_INITIALIZED=3216371


    VG
    Bernhard

  • yavdr ansible

    Zitat von seahawk1986

    War das nach einem Reboot auch noch so?

    Ja, habe gerade noch einmal in die Logs geschaut.

    Erst nach dem manuellen Anlegen des Links waren der lircd und damit der vdr zufrieden.


    Zitat von seahawk1986

    Da ist mir noch nicht ganz klar, woher die verbogenen Rechte kommen (die Plugins legen die Verzeichnisse im CACHE_DIR normalerweise erst bei Bedarf an) - welche Plugins hast du neben robotv installieren lassen?

    Das robotv Plugin wollte beim ersten Start des vdr ein Verzeichnis im CACHE_DIR anlegen.

    Daher ist es mir aufgefallen.


    Im CACHE_DIR waren auch die Dateien commands.conf und reccmds.conf mit Besitzer root angelegt.


    VG
    Berrnhard

  • yavdr ansible

    Hallo,


    vorab möchte ich mich für yavdr-ansible bedanken, super Arbeit.

    Mit yavdr-ansible war das aktuelle System in wenigen Minuten aufgesetzt.


    Dabei sind mir die folgenden zwei Punkte aufgefallen:

    - irman: Link irman auf ttyACM0 wird nicht gesetzt -> manuelles Anlegen erforderlich (nutze atric USB device)

    - Plugin directory: vdr-User hat keine Schreibrechte für /var/cache/vdr/plugins/ (Verzeichnis gehört root) -> Besitzer der Dateien ab /var/cache/vdr auf vdr.vdr geändert (aufgefallen mit dem zusätzlich in host_vars/localhost aufgenommenen Plugin vdr-plugin-robotv)


    Danke

    Bernhard

  • [gelöst] yavdr 0.6.1 - SSD & NVIDIA Chipsätze (hier C51PV)

    Hi,


    nachstehend ein paar Informationen, falls noch jemand das Problem mit der Nachrüstung einer SSD und einem älteren NVIDIA Chipsatz (hier C51PV) hat.


    Ziel war der Einsatz einer SSD auf einem Fujitsu Esprimo E5615 (mit dem besagten/betagten NIVIDIA Chipsatz).
    Die Neu-Installation von yavdr 0.6.1 lief ohne Schwieigkeiten durch.
    Die spezifischen Einstellungen konnten alle über die Web-Oberfläche eingestellt werden. Bild und Ton waren sofort verfügbar.


    Schnell fiel auf, das die Schreibgeschwindigkeit auf das per NFS angeschlossene NAS-System nicht mehr ausreichte, eine HD Sendung aufzuzeichnen (FTA).
    Die Beobachtung der Netzwerklast mittels nload (nload -u M) ergab, dass mit der SSD keine gleichmäßige sondern eine eher unregelmäßige Last auf der per NFS angebundenen Neztwerkstrecke erzeugte wurde.
    Im syslog tauchten dann die folgenden Fehlermeldungen auf:


    Code
    ...
vdr: [9133] i/o throttle activate
...
vdr: [9133] buffer usage: 70% (tid=9132)
vdr: [9133] buffer usage: 80% (tid=9132)
vdr: [9133] buffer usage: 90% (tid=9132)
vdr: [9134] buffer usage: 100% (tid=9133)
vdr: [9133] ERROR: 1 ring buffer overflow (177 bytes dropped)
...


    Ein Wechsel zurück auf die alte HDD zeigte, dass mit der HDD locker 4 HD Sendungen parallel aufgezeichnet werden konnten.
    Die Netzwerklast (nload) zeigte eine durchgehende konstante Last, die mit jeder zusätzlichen Aufnahme entsprechend stieg.


    Recherchen ergaben, dass der NVIDIA Chipsatz bei Anschluss von SATA III (6Gbps) Laufwerken auf SATA I (1.5Gbps) zurückschaltete.
    Allerdings sollten auch 1.5 Gbps ausreichen, um den Datenstrom auf dem NAS-LW abzulegen.
    Laut 'dmesg'und dem syslog wurde die SSD auch automatisch mit 1.5 Gbps angesteuert.


    Die Lösung war, den Linux Kernel explizit dazu aufzufordern, die SSD nur mit 1.5 Gbps anzubinden.
    Der Kernel Bootparameter hierzu lautet "libata.force=1.5G, noncq".
    Der Zusatz 'NONCQ' ist bei unserem System erforderlich, um sporadische Bootverzögerungen der SSD auf grund vermeintlicher Lesefehler (err=0) abzustellen.


    Interessant war, dass der Fehler erst bei den ersten Aufnahmen auf das per NFS angeschlossenen NAS-System sichtbar wurde.
    Einzelne Aufnahmen auf der SSD selbst, zeigten dieses Verhalten nicht (vielleicht auch Zufall).
    Zuerst vermutete ich einen Defekt (Kabelbruch, etc.) auf der Netzwerkseite oder einen NFS Konfigurationsfehler.
    Erst der Vergleich mit zwischen SSD und HDD führte dazu, den vermeintlichen NFS Fehler auf die Systemanbindung der SSD und damit den NVIDIA Chipsatz zurückzuführen.


    Viele Grüße
    Bernhard

  • [Announce] Aktuelle Version des vdr-epg-daemon und der dazugehörigen Plugins für yaVDR 0.6 (zunächst für testing-vdr)

    Umstellung bedurfte ebenfalls der Neuerstellung der Datenbank sowie des DB-Benutzers.
    Ansonsten bin ich der Anleitung gefolgt.


    Das epgd-Webif gefällt mir. :]
    VIelen Dank an alle Beteiligten dafür. :tup


    Aufgefallen ist mir noch, dass ein ";" im mysql-Passwort zu Fehlern beim Aufruf von mysql durch epgd-tool führt.
    Beim Aufruf von mysql durch epgd-tool wird der Passwortanteil nach dem ";" als Kommando interpretiert.
    Auch ein Setzen von Single- oder Double-Quotes in ~/.ssh/mysqlpasswd hat nicht geholfen.
    Erst die Änderung des Passworts, nun ohne ";", brachte den Erfolg.


    Die direkte EIngabe via mysql unter Verwendung des Passworts mit dem ";" funktioniert.


    VG
    Bernhard

  • [0.6.0] epgd - Kein Download bei epgdata.com [gelöst]

    Der Downgrade zu einer älteren Version des epg-daemon und curl, in Verbindung mit einem späteren Update auf die aktuellen Varianten scheint das Problem gelöst zu haben.
    Der Download von epgdata.com funktioniert nun nach mindestens 4 Wochen Ausfall wieder.


    Da weder die Logmeldungen noch die Netzwerkanalyse (http.request) einen direkten Hinweis auf die Ursache lieferten, hatte ich mich an dem folgenden Beitrag orientiert:
    http://www.vdr-portal.de/board16-video-disk-recorder/board99-distributionen/board96-yavdr/p1258000-gel%C3%B6st-kein-epg-nach-12-12-2015/?highlight=epgd#post1258000


    VG
    Bernhard

  • [0.6.0] epgd - Kein Download bei epgdata.com [gelöst]

    Hallo Freunde des vdr,


    aktuell schlägt der Download von Daten von epgdata.com bei mir fehl.


    Eine Analyse hat soweit ergeben, dass:
    - der Account bei epgdata.com noch gültig und die PIN valide ist
    - ein Download von epgdata.com bei korrekter URL (inklusive PIN) problemlos funktioniert
    - die URL in epgd.conf korrekt ist
    - die PIN in epgd.conf aktuell und gültig ist


    Anscheinend wird die PIN nicht aus epgd.conf gelesen.
    Die Logmeldung sieht wie folgt aus:

    Code
    Download of day (0) from 'http://www.epgdata.com/index.php?action=sendPackage&iOEM=VDR&pin=insert-your-pin-here&dayOffset=3&dataType=xml


    edit:
    Laut Sourcecode wird in den Logmeldungen keine PIN ausgegeben.
    Es muss also direkt der Netzwerktraffic mitgeschnitten werden, um daas Verhalten zu validieren.


    Bisher ausprobiert wurden die curl-Version aus Ubuntu Trusty sowie der vdr-epg-daemon vom 27.10.2015.
    Auch mit diesen Änderungn konnte kein Download von epgdata.com erreicht werden.


    Wer hat einen Tipp für mich, was ich noch versuchen könnte?



    Nachstehend Details zum System und der Software:


    System:
    - yavdr 0.6.0 (stable, regelmäßige Aktualisierung)
    - vdr-epg-daemon

    Code
    vdr-epg-daemon:
  Installiert:       	1:0.3.2.git20160215.0725-0yavdr0~trusty
  Installationskandidat: 1:0.3.2.git20160215.0725-0yavdr0~trusty
  Versionstabelle:
 *** 1:0.3.2.git20160215.0725-0yavdr0~trusty 0
    	500 http://ppa.launchpad.net/yavdr/main/ubuntu/ trusty/main amd64 Packages
    	100 /var/lib/dpkg/status


    - curl

    Code
    ii  curl                              	7.36.0-1fnu0~trusty                      	amd64
ii  libcurl3:amd64                    	7.36.0-1fnu0~trusty                      	amd64
ii  libcurl3-gnutls:amd64             	7.36.0-1fnu0~trusty                      	amd64
ii  libcurl3-nss:amd64                	7.36.0-1fnu0~trusty                      	amd64
ii  python3-pycurl                    	7.19.3-0ubuntu3                          	amd64


    - epgd-showmerge liefert:


    Die Datei epgd-conf ist lesbar und das Verzeichnis /var/cache/epgd/epgdata/ schreibbar.


    [edit: Titel erweitert]


    Danke und viele Grüße
    Bernhard

  • Blueray kein UDF 2.5 und kein demux tool unter Linux

    Hi,


    laut einem Beitrag auf DIskussion zu Blueray Support Write unter Linux (siehe Seite 2 - vorletzter Beitrag) ist folgendes möglich:


    To summarize the process:


    Use x264 through ffmpeg or directly to convert the video to H.264 per the recommendations on www.x264bluray.com. Add the -fps flag if you need it. Unless you have a REALLY fast machine or an eternity to wait, use the slow preset instead of veryslow.
    Extract the audio, I used ffmpeg to extract the existing AC3 audio.
    Use tsMuxeR to create the proper blu-ray folder structure and mux'ed stream (unfortunately not FOSS, but free)
    Use ImgBurn under WINE to create the image for burning, which supports UDF 2.50 for blu-ray (and 2.60, but that's not needed).


    A couple of side notes:


    My ASUS BW-12B1ST blu-ray burner has worked great without issue, can't recommend it enough.
    Using cdrskin which is a frontend to libburn has also worked great.
    No need for the official cdrtools. Not that there's anything functionally wrong with cdrtools, but it keeps me out of the whole cdrtools vs cdrkit debacle.


    Gruß
    Bernhard

  • Fujitzu Siemens Esprimo E5600 Hardware Tuning

    Nachdem die Quadro 410 nun im Fujitsu Esprimo 5600 funktioniert, nachstehend einige Angaben zur Leistungsaufnahme.


    Standby: 11W
    Rechner fährt hoch: max. 110W
    HD (1080i) - Servus TV: mittel 70W
    HD (720p) - ARD: mittel 70W
    SD (576i) - RTL2: mittel 78W


    Ausgabe erfolgte in 1080p auf einen LG 46LM620S.


    Werte wurden mit einem einfachen Leistungsmesser von TCM bestimmt (Schätzeisen).
    System gemäß Signatur.

  • Fujitzu Siemens Esprimo E5600 Hardware Tuning

    Die Quadro 410 läuft nun.
    Es musste das IRQ-Handling auf IRQPOLL (Kernelparameter) umgestellt werden.


    Anbei die Werte gemäß qvdpautest (gleiches Niveau wie bereits im Wiki für VDPAU Grafikkarten für die Quadro 410 angegeben).
    Lediglich die Surface Get/Put Operationen haben einen geringeren Durchsatz.



    Und ja, das Standard-Netzteil des Esprimo 5600 schafft alles locker. :P


    Gruß
    Bernhard

  • Fujitzu Siemens Esprimo E5600 Hardware Tuning

    Hat einer der Esprimo 5600 Besitzer schon einmal eine PCIe Gen.2 Grafikkarte getestet?
    Wenn ja, welche haben funktioniert?


    Hintergrund meiner Frage ist, dass eine nvidia Quadro 410 zwar erkannt wird und auch eine Ausgabe am TV liefert,
    die Transferraten aber extrem einbrechen (z.B. MPEG Decoding (1920x1080) 10 Frames/s) .
    Die Ausgabe stottert. Ein Verhalten wie bei einer Fehlkonfiguration bei der Wiedergabefrequenz (also 24 statt 50Hz).
    SoftHDDevice liefert im Syslog erwartungsgemäß dann - Renderer too slow.
    Der Karte ist ein individueller IRQ zugeordnet, welcher nicht mit einer anderen Einheit geteilt werden muss.


    In einem PC mit PCIe x16 Gen.2 Steckplatz bringt die Karte die gemäß VDPAU Wiki zu erwartenden Frameraten, ist also technisch in Ordnung.


    Der PCIe x16 Steckplatzdes Esprimo 5600 ist laut Datenblatt konform zu PCIe Gen.1.
    Eine Club3D GS 8400 sowie eine GeForce 210 (GT218) funktionieren.


    Gruß
    Bernhard

  • [yavdr 0.5] GELÖST - ngene Treiber Probleme

    Problem erstmal gelöst, Treiber konnte geladen werden und Signal ist nun vorhanden.


    Die von mir verwendete Hardware (siehe Sig) benötigt unter yavdr 0.5 (Ubuntu 12.04) die Bootoption pci=nomsi
    um den ngene Treiber fehlerfrei laden zu können.


    Es wird dann anstelle des PCI-MSI-Interrupts 41 der IO-APIC-fasteoi IRQ 20 zugewiesen.
    Diesen teilt er sich nun mit dem zweiten USB-OHCI Kontroller.


    Die geladenen Module sind dann:
    - dvb_core
    - cxd2099 (Treiber für CI-Module)
    - ngene (SaTIX Kartentreiber)
    - stv6110x
    - stv090x (Multistandard Frontend)


    Es muss nun noch die Langzeitstabilität beobachtet werden.


    Grüße
    bronline

  • [yavdr 0.5] GELÖST - ngene Treiber Probleme

    Hi,


    ich brauche mal eure Unterstützung.


    Der ngene Treiber aus der yavdr 0.5 Standardinstallation wie auch der ngene Treiber aus dem linux-media-dkms Paket führen zu einem Kernel Oops.
    Beide nutzen per Default die Firmware ngene_18.fw und das Frontend cxd2099 aus dem Staging Bereich des Kernels.
    Dem syslog (siehe Anhang) ist zu entnehmen, dass das Frontend cxd2099 nicht vorhanden ist (nicht gefunden wird).


    Karte ist eine Mystique_SaTiX-S2_Dual (http://linuxtv.org/wiki/index.php/Mystique_SaTiX-S2_Dual) mit der ID [18c3:db01].


    Bisher lief yavdr 0.4 unter Verwendung der identischen Hardware.
    Unter yavdr 0.4 wurde der ngene Treiber aus dem s2-liplianin-dkms Paket mit der ngene_15.fw Firmware und dem Frontend stv0900 verwendet.


    Wie kann das Frontend gewechselt werden (von cxd2099 auf stv0900)?
    Bei fehlendem cxd2099 kann ngene aufgrund "Unknown symbol" nicht geladen werden.


    bronline