Beiträge von Rubi

    Ja, das ist ein Problem. Keine Ahnung, wie du das mischen kannst. Das solltest du zuerst bereinigen.

    Das "Mischen" war gar nicht schwer. Wie gesagt, ich hatte einfach ein Ubuntu-Dist-Upgrade von 14.04 auf 16.04 gemacht. Die vorher eingebundenen PPAs von yavdr wurden dabei automatisch deaktiviert aber die daraus installierten Pakete (vdr aus yavdr trusty sowie diverse plugins) blieben erhalten und funktionierten auch bis auf 1-2 Plugins (z.B. live), die Konflikte mit Bibliothekversionen hatten und automatisch deinstalliert wurden. Daraufhin habe ich euer unstable xenial als PPA eingebunden, da dort ja das live Plugin vorhanden ist. Danach wurden dann auch einige der yavdr-Pakete auf die Xenial-Version aktualisiert aber natürlich nur die im PPA vorhandenen wie z.B. der vdr selbst.



    Wenn ich bei 16.04 bleiben will (der Rechner wird primär als PC genutzt und spielt halt nur nebenbei noch Videorekorder), würde "bereinigen" wohl bedeuten: Die yavdr ganz rausschmeißen und auf die originalen Ubuntu VDR-Version wechseln, wo halt viele Plugins fehlen. Hmm, ich glaube, ich lasse erst mal alles so, wie es ist. Bis auf die Suche im Web klappt ja alles.


    Gruß, Andreas

    Beim Paket für das Live-Plugin bin ich damals vom Paket für Debian ausgegangen (weil da Patches für GCC6 drin waren und es auf einem neueren Upstream-Snapshot basiert) und habe dann die Patches aus dem alten yaVDR-Paket übernommen - eventuell hat sich dadurch ein neues Problem ergeben. Ich setze es mal auf meine TODO-Liste, aber es kann etwas dauern - in den letzten Monaten ist leider einiges aufgelaufen, was erst mal wichtiger ist.


    Du könntest mal versuchen das originale Debian-Paket zu bauen und ausprobieren, ob es damit auch crasht:

    Code
    sudo apt-get install devscripts build-essential fakeroot
    sudo apt-get install build-dep vdr-plugin-live
    dget -xu --build http://http.debian.net/debian/pool/main/v/vdr-plugin-live/vdr-plugin-live_0.3.0+git20160123-1.dsc
    sudo dpkg -i vdr-plugin-live*.deb

    Hat leider nichts gebracht, crasht ebenfalls.

    Ist der vdr und alle Plugins auch wirklich aus der gleichen Quelle?
    Am besten mal mit "apt-cache policy vdr" usw. nachsehen.
    Und noch besser per apt-pinning die (eine) vdr-Quelle priorisieren.


    Lars.

    Naja, der vdr ist aus yavdr-Xenial aber es sind etliche plugins aus dem yavdr-Trusty-Zweig verblieben, z.B.



    Im Xenial-Zweig gibt es ja noch kaum etwas, was die Trusty-Plugins ersetzen könnte. Wenn diese Mischung aus Trusty und Xenial das Problem ist, habe ich wohl Glück, dass es nicht noch viel mehr Probleme gibt.


    Wenn ihr noch Ideen habt, her damit. Ansonsten erstmal danke.
    - Andreas

    Hi.


    Ich hatte die yaVADR-Pakete (deutlich mehr Plugins als in den Original-Ubuntu-Repositories) ursprünglich auf meinem Ubuntu 14.04 PC am Laufen und alles funktionierte super.
    Vor einigen Tagen habe ich dann ein Upgrade auf 16.04 probiert, obwohl ich wußte, dass eure PPAs den Xenial nur rudimentär unterstützen. Grund: Die Treiber meiner DVB-Karte waren im 14.04-Kernel noch nicht drin und ein dauerndes Neucompilieren nach jedem Update war auf Dauer etwas nervig.


    Alles sah zunächst auch ganz gut aus. Der VDR mit den installierten Plugins aus euren Paketen lief zunächst weiter, nur die Plugins "osdteletext" und "live" waren inkompatibel und wurden im Rahmen des Upgrades deinstalliert.
    Das "osdteletext" habe ich nun selbst kompiliert und zum Laufen bekommen.
    Das "live" habe ich aus eurer Paketquelle "unstable-vdr" neu installiert, dieses ist ja auch für xenial schon verfügbar und zunächst sah auch alles ganz gut aus.
    Allerdings stürzt der VDR nun reproduzierbar mit einem "segfault at 7f14a60a9000 ip 00007f14a54e8986 sp 00007f1475ff5f78 error 4 in libc-2.23.so" ab, sobald ich im "Live-Web" eine Suche ausführe oder nur auf den Menüpunkt "Suchtimer" gehe. Ein Selbst-Compilieren habe ich ebenfalls nicht hinbekommen.


    Falls euch das irgendwie interessiert und ihr an dem Problem arbeiten wollt oder ihr mir sonst irgendwie helfen könnt: Welche Infos soll ich liefern?
    Falls ihr sagt: "Diese Konfi ist nicht unterstützt.": Schade aber auch okay. Ich muss mir halt verkneifen, die Suchfunktion im Web zu nutzen.


    Grüße, Andreas

    Hi.


    Ich habe jetzt schon tagelang nach einer Lösung gesucht und sehr vieles ausprobiert und kriege es einfach nicht hin, deshalb frage ich einfach mal direkt hier.


    Also...
    - nagelneuer PC mit Asus H97 Mainboard und integrierter Intel HD Grafik, den ich sowohl als normalen PC als auch als "Fernseher/Videorekorder" nutzen will
    - Xubuntu 14.04 mit "yavdr/testing" Paketquellen
    - vdr läuft gut und mit vdr-sxfe kriege ich auch ein Bild, allerdings kriege ich keine Kombination von EInstellungen und Parametern hin, mit der die Darstellung wikrlich komplett gut funktioniert


    Was ich ausprobiert habe...
    1. vdr-sxfe --video=vaapi --audio=pulseaudio --reconnect --buffers=500
    Damit funktioniert es relativ gut, allerdings habe ich scheinbar keine Chance, ein Deinterlacing hinzubekommen. Alle Einstellungen im xineliboutplugin sowie in der Kommandozeile --post:tvtime... werden scheinbar komplett ignoriert (den buffers Parameter verwende ich, da ich ansonsten immer wieder stotternden Ton auf den HD-Sendern bekommen habe).


    2. vdr-sxfe --video=xv --audio=pulseaudio --reconnect --buffers=500 --verbose --post tvtime:Linear,cheap_mode=1,pulldown=0,use_progressive_frame_flag=1
    Mit dem xv-Treiber klappt Deinterlacing, allerdings läuft das nicht wirklih stabil. Beim Umschalten von einem HD- auf einen SD-Sender hängt sich der vdr-sxfe immer mal wieder komplett auf oder stürzt ab.


    Außerdem ist mir aufgefallen, dass ich je nach Variante mit den OSD-Einstellungen ziemlich rumtricksen muss, um ein Bild zu bekommen. Häufig ist das OSD entweder viel zu groß oder es ist komplett zerstört (Zeilenlänge bzw. Zeilendelta passen dann irgendwie nicht)


    Auch mit einigen EInstellungen in der config_xineliboutput habe ich schon rumprobiert, da ging es aber wohl eher um den Ton und das Buffer-Problem, wenn ich mich richtig erinnere.


    Deshalb die Frage: Wie bekomme ich es mit meiner ja eigentlich nicht so wahnsinnig ungewöhnlichen Hardware hin, einen VDR darzustellen, wo sowohl Fenster- als auch Vollbilddarstellung, das Deinterlacing, das OSD funktionieren und sich das dann noch stabil beim Programmumschalten verhält.


    Was braucht ihr an sonstigen Daten/Dateien/Infos?
    Hoffe, ihr könnt mir helfen.


    Rubi


    PS. Wenn wir mit dem vdr-sxfe durch sind, hätte ich noch ein bis zwei weitere Fragen :D

    Zitat

    Original von Keine_Ahnung
    War das bei dir anders dann kommt das von denjenigen der deine Distribution zusammengestellt hat. Aber da bastelt jede Distribution ihre eigenen Standards.


    Genau deswegen schreibe ich im ct'vdr Bereich.
    Diese Distribution sieht den Ordner ../video/film/dvd zur Ablage für das burn plugin vor.
    Also: Welche Datei erzeugt der ct'vdr in diesem Ordner, um dessen Löschung durch den vdr zu verhindern?

    Naja, "fremd" ist der vdr-eigene (bzw. burn-plugin-eigene) Ordner film/dvd ja nicht gerade. Vermutlich habe ich irgendwann beim Aufräumen der iso-Images auch den "nicht löschen"-Marker des VDR weggeräumt.


    Kann mal jemand nachschauen, welche Datei der VDR dort standardmäßig anlegt? Ich würde gerne genau diesen Standard bei mir wiederherstellen.


    Ansonsten schon mal danke für die Infos.

    Hallo Leute.


    Als ich heute nach längerer Zeit mal wieder mit dem burn Plugin eine DVD erstellen wollte, konnte ich die Vorauswahl 'Nur Brennen' nicht ändern. Nach einigen Recherchen fand ich die Ursache im fehlenden Ordner .../video/film
    Kurzerhand erstellte ich die Ordner film und film/dvd, übergab sie per chwon -R vdr:vdr film/ dem vdr user und dann sahs auch erstmal gut aus mit dem iso-Erstellen des burn-plugin. Doch plötzlich (noch während der Konvertierung der Aufnahmen für die DVD-Erstellung) war der Ordner wieder weg und im SYSLOG fand ich, dass der VDR-Aufräum-Thread neben einigen von mir bewußt gelöschten Aufnahmen auch den film Ordner löscht.


    Oct 31 17:31:53 noname vdr: [4542] remove deleted recordings thread started (pid=3726, tid=4542)
    ...
    Oct 31 17:33:16 noname vdr: [4542] removing /var/lib/video.00/film/dvd
    Oct 31 17:33:16 noname vdr: [4542] removing /var/lib/video.00/film


    Kann sich das jemand erklären? Muss dieser Ordner von den Berechtigungen/dem Besitzer vielleicht anders konfiguriert sein als die übrigen Aufnahmeordner?


    Jeder Hinweis ist willkommen.

    Zitat

    Original von heinzelrumpel
    die remote.conf bei einem entferneten rechner muss dem client liegen, auch lirc muss zwingend dort installiert sein. danach startet man vdr-sxfe mit "--lirc" als parameter.


    Die remote.conf liegt ja auch schon auf dem client. Muss ich denn wirklich lirc installieren und nutzen, wenn ich gar keine echte Fernbedienung sondern nur die Tastatur des Clients nutzen möchte?


    Okay, werd's mal ausprobieren...

    Ich klinke mich hier mal ein, da mein Problem dieselbe Ursache haben könnte:


    Auch ich möchte von Ubuntu-9.04 aus meinen ctVDR 7 (mit eTobi-Kernel 2.6.28) über's Netz per vdr-sxfe "fernbedienen". Ein Bild bekomme ich inzwischen auch, weiß aber nicht, wie das mit der remote.conf funktioniert. Ich habe auf dem Ubuntu-Rechner eine remote.conf mit den XKeySym.* Einträgen in das entsprechende Verzeichnis gepackt. Wenn ich jetzt aber z.B. per 'm' versuche, ins Menü zu kommen, kriege ich in der Konsole, aus der ich das vdr-sxfe gestartet habe, nur wilde Sonderzeichen und "unknown control" (oder ähnlich) Meldungen. Lokal am VDR-Rechner habe ich den Fernseher dann aber tatsächlich mit aktiviertem OSD-Menü vorgefunden.


    Erst dachte ich, es könnte an der falschen remote.conf am falschen Ort liegen. Jetzt, wo ich auf diese Anfrage von Holyjoe gestoßen bin, könnte ich mir aber auch vorstellen, dass es an der falschen (alten) Version des vdr-sxfe liegt, die mit der Übertragung des OSD vielleicht nicht klar kommt.


    Schließe mich also der Frage an: Wie kriegt man ein aktuelles/kompatibles vdr-sxfe auf einen Ububtu-Rechner?

    Nachdem gestern meine erste Aufnahme per ACPI kläglich gescheitert ist, muss ich diesen Thread nochmal aufmachen. Das acpiwakeup Skript scheint mit localtime nicht richtig klarzukommen. Hier der AUszug aus dem Log, der zeigt, dass der Alarm eigentlich korrekt für 13:40 Ortszeit eingetragen wird, der Rechner dann aber schon um 11:40 aufwacht (und dann nach 30 Minuten wieder herunterfährt, da der Timer noch zu weit weg ist)


    ...
    Jul 10 07:48:56 noname vdr-shutdown: executing /usr/share/vdr/shutdown-hooks/S90.acpiwakeup as shell script
    Jul 10 07:48:56 noname vdr-addon-acpiwakeup: Setting ACPI alarm time to: 2009-07-10 13:40:00
    Jul 10 07:48:56 noname vdr-addon-acpiwakeup: Writing to /sys/class/rtc/rtc0/wakealarm
    Jul 10 07:48:56 noname vdr-addon-acpiwakeup: Writing to /sys/class/rtc/rtc0/wakealarm
    Jul 10 07:48:56 noname vdr-shutdown: executing /usr/share/vdr/shutdown-hooks/S90.custom as shell script
    Jul 10 07:48:56 noname shutdown[3531]: shutting down for system halt
    Jul 10 07:48:58 noname vdr: [3008] [xine..put] Closing connection 0
    Jul 10 07:49:02 noname vdr: [2857] [xine..put] cXinelibOsdProvider: shutting down !
    Jul 10 11:40:49 noname kernel: imklog 3.18.6, log source = /proc/kmsg started.
    Jul 10 11:40:49 noname kernel: [ 0.000000] BIOS EBDA/lowmem at: 0009fc00/0009b000
    Jul 10 11:40:49 noname kernel: [ 0.000000] Initializing cgroup subsys cpu
    Jul 10 11:40:49 noname kernel: [ 0.000000] Linux version 2.6.28-etobi.3-486 (Debian 2.6.28-1+etobi.3) (etobi@debian.org) (gcc version 4.3.2 (Debian 4.3.2-1.1) ) #1 Sat May 16 23:03:43 UTC 2009
    Jul 10 11:40:49 noname kernel: [ 0.000000] KERNEL supported cpus:
    ...
    Ich habe mal manuell getestet, die Aufwachzeit nach /sys/class/rts/rtc0/wakealarm zu schreiben und es scheint, dass ich "date + 2 Stunden + 5 Minuten" reinschreiben muss, damit der Rechner 5 Minuten später wieder aufwacht. Das scheint das acpiwakeup Skript aber nicht zu machen.


    Was läuft da schief??


    Danke schon mal.
    - Andreas

    Zitat

    Original von Rubi
    Werde mal UTC=no in der /etc/default/rcS probieren.


    Das scheint zu funktionieren.


    Warum das unter Gen2vdr nicht auftrat, hat Halbfertiger ja schon erklärt.


    Für Debian sollte die Installation eigentlich wohl einen Dual-Boot erkennen und UTC dann entsprechend deaktivieren, so habe ich es zumindest gelesen. Vielleicht lag's daran, dass ich die gesamte Platte dem vdr zur Verfügung stelle und mein Windows auf einer anderen Platte liegt. Andererseits... in grub ist der Windows Boot sauber eingetragen worden.


    Egal. Läuft ja jetzt. Vielen Dank für eure Hilfe. Komme bestimmt nochmal auf euch zurück...

    Zitat

    Original von wilderigel
    entferne windows vom vdr.


    oder schlimmstenfalls stells in /etc/default/rcS um.


    Windows kann ich hier nicht runterschmeißen.


    Das Komische ist, dass ich eine frühere Version des ctvdr und in letzter Zeit Gen2vdr parallel mit WIndows betrieben habe, ohne dieses Problem jemals beobachtet zu haben. Hat sich da in Debian/Lenny was geändert?


    Werde mal UTC=no in der /etc/default/rcS probieren.


    Habe gesehen, dass man auch im VDR einen Zeitabgleich per DVB-Transponder aktivieren kann. Ist das empfehlenswert?


    - Rubi

    Ich nochmal.


    Nächstes Problem betrifft die Uhrzeit.


    Ich habe einen Dual-Boot Rechner und Windows erwartet, dass die System/BIOS-Zeit in lokaler Zeit (also mitteleur. Sommerzeit) eingestellt ist. Debian scheint aber beim Starten die Systemzeit immer als UTC zu setzen, so dass ich nach einem VDR-Lauf mit dort korrekt eingestellter Zeit und Zone immer die BIOS-Uhr um 2 Stunden zurück gestellt hat und beim nächsten Windows-Start die Zeit dort falsch geht (und leider auch erstmal falsch bleibt, da mein Netzkartentreiber sehr spät startet und der Zeitabgleich deshalb zunächst scheitert). Und ein Synchronisieren unter WIndows per NTP würde dann beim nächsten VDR-Start wieder eine falsche Zeit ergeben.


    Als Lösung habe ich bei Tante Google einen Vorschlag gefunden, Linux generell mit UTC laufen zu lassen und in /etc/timezone einfach UTC reinzuschreiben.


    Jetzt meldet sich aber der VDR mit "falschen" Zeiten. Der Film um 20:15 wird mit Startzeit 18:15 angezeigt und entsprechend läuft auch die Aufnahme 2 STunden zu früh.


    Wie konfiguriere ich denn jetzt die Zeit am besten?
    - Rubi

    Zitat

    Original von wilderigel
    nuja, ev brauchts noch mal das debian paket vom m-a um xinelibout und quatsch zum laufen zu bewegen.
    :jb


    Wenn vdr-sxfe sauber läuft (und so sieht's aus), kann ich doch davon ausgehen, dass ich mit xinelibout keine Probleme habe, oder??

    Zitat

    Original von Rubi


    Okay, ich habe jetzt mal sie sources.list.online aktiviert und ein update und upgrade gestartet...


    Melde mich wieder. Danke schon mal.


    kernel-headers geholt, NVIDIA Treiber ließ sich installieren, X-Server startet, alles gut!.


    Danke!!!


    Jetzt muss nur noch der ACPI wakeup funktionieren...

    Zitat

    Original von wilderigel
    ansonsten gibts die /etc/apt/sources.list.online die auf /etc/apt/sources.list umbenannt werden kann.
    dann die ueblichen schritte mit apt-get update und so.


    Okay, ich habe jetzt mal sie sources.list.online aktiviert und ein update und upgrade gestartet...


    Melde mich wieder. Danke schon mal.