Posts by berndb

    Getestet:

    Bei mir hat jetzt wie vermutet "F5" die Funktion zurück.

    Wo die Ausdrücke wie "XINE_EVENT_INPUT_MENU6" definiert sind, ist mir tatsächlich völlig rätselhaft. Und der Rest eigentlich auch.


    Habe ein wenig in den Keymapsettings rumgespielt und schon war der F5-Zauber vorbei. In den keymaps settings in der xine-ui ein Reset gemacht und dann war gar kein vdr-menü mehr erreichbar.


    Backup der keymap -Datei ~.xine rausgeholt und ein erneutes make install im xineliboutput-Ordner und wir sind wieder da.


    Irgendwie hängen Quellcode und settings-Dateien aneinander, aber halt irgendwie ...

    Ich habe gerade xineliboutput im Rennen.


    In der README finde ich folgende Bemerkung:

    Quote

    With xine-ui:


    Keyboard shortcuts and remote events from xine menus are

    automatically forwarded to VDR and translated to VDR keys.

    Translation to VDR keys is static and defined in xine_input_vdr.c.



    Die entscheidende Stelle, soweit ich das als ein bisschen Shell-Coder überhaupt erkennen kann, scheint mir diese hier:


    Liegt hier der Hund begraben, warum die Backspace-Taste keine Funktion hat, wenn die xine-ui im Vordergrund mit dem vdr-Bild läuft? Bei vdr-sxfe hat sie wie gewünscht die "Zurück"-Funktion.

    Code
    1. git pull

    Brachte sowohl im live-Quellverzeichnis als auch in dem des vdr keine Änderungen. Also

    Code
    1. pacman -Syu

    und das System auf Stand gebracht.


    Immer noch keine Besserung, auch nach Neustart des Rechners.


    Code
    1. make clean

    im vdr-Verzeichnis und im live Verzeichnis ausgeführt und

    Code
    1. make LCLBLD=1 ONEDIR=1

    neu übersetzt/ kompiliert.


    Und nu läuft es auch mit live.


    Da waren wohl irgendwelche Gremlins aktiv, die hoffentlich jetzt verschwunden sind. Danke für Rat und Tat!

    Was genau soll ich liefern oder wie erstelle ich denn so einen Backtrace?


    Hilft das (nach gdb im vdr-wiki)


    Mein old-school selbst kompilierter vdr startete nicht mehr, also neu gebaut.


    Da der auf meinem arch läuft, habe ich mir die sourcen aus aur/vdr4arch geholt, bis auf den vdr selbst (den von http://git.tvdr.de). Der meldet sich als 2.6.1.


    Nach

    Code
    1. make LCLBLD=1 ONEDIR=1


    Das läuft alles nach schnellen erstem Test:

    Code
    1. ./vdr --user=bernd_b --log=3 -c /video -v /video -P epgsearch -P streamdev-server -P femon -P "xineliboutput --local=none --remote=37890 --video=opengl2"

    Also streamdev, xineliboutput, femon, epgsearch.


    Zum größten Problem (neben dem fehlenden zurück-Button in der xine-ui, bei vdrsxfe funktioniert die Backspace-Taste und keinem Bild bei softhddevice - Luxusprobleme):


    Füge ich live hinzu, erhalte ich:


    Code
    1. ./vdr --user=bernd_b --log=3 -c /video -v /video -P "live -p 8008 -i 192.168.178.100" -P epgsearch -P streamdev-server -P femon -P "xineliboutput --local=none --remote=37890 --video=opengl2"
    2. INFO: validating live server ip '192.168.178.100'
    3. Segmentation fault (core dumped)


    Habe ich da irgendeine Bananenschale liegen lassen?


    Code
    1. cxxtools 3.0-2
    2. tntnet 3.0-2

    Und wie fnu schon sagte, es geht hier um technische Lösungen, nicht um politische Diskussionen.

    Was ich ja unfair finde:

    Jemanden in die Eier treten und dann sagen: Aber ich mag da jetzt nicht drüber diskutieren.


    Also vielen Dank für den Hinweis zu dem zumindest technisch neuen Sender.


    Wenn Du Deinen hier zitierten Satz ernst meinst, dann gehe doch mit gutem Beispiel voran und editiere Deinen Eingangspost so, dass der restliche - Verzeihung - unausgewogene Quatsch da nicht mehr zu finden ist.

    Ja das Bild bei Intel ist bei den Farben etwas flauer
    ...
    Normalerweise wird die LUT vom Treiber gesetzt und ist linear. D.h. Eingang gleich Augang. Bei NVIDIA scheint mir das aber nicht der Fall und dort werden per default die Farben aufgebessert.

    Ich war mir eigentlich nie sicher, ob ich mir das einbilde oder wirklich ein Unterschied bei den Farben vorliegt. Tatsächlich habe ich mich aber deswegen für die im Prozessor mitgelieferte Intel HD Graphics entschieden. Bei NVIDIA kam mir alles immer einen Tick zu bunt vor und bei Intel fielen mir die Farben im positiven Sinne nie auf.

    Das Intel an den Farben nichts "verbessert", Nvidia aber quasi mit Fabrikeinstellungen schon, würde meinen Eindruck bestätigen. Ich habe die Intel-Farben aber nie als flau empfunden, sondern als richtig und natürlich.


    Bzgl. De-Interlacing hat man ja die Qual der Wahl bei all den Software-Deinterlacern, brauche ich aber bestenfalls für den Abspann bei BBC-Aufnahmen.

    Danke für die Glückwünsche. Wollte damit aber eigentlich zum Ausdruck bringen, dass die Arbeit jenseits von Binärpaketen, deren Downloadzugriffe wenn ich richtig lese den Aufwand nicht lohnen, nicht umsonst war.


    Aber wo geht die Reise jetzt hin:

    Im AUR wird man weiterhin die oben genannten fünf Plugins finden?

    Der Rest, bleibt oder fliegt raus? Oder wird eben aktualisiert, wenn jemand sich mit einem Patch etc meldet?


    Das wir alle vdr-Projekte top-gepflegt an einen Ort bekommen, scheint ja ein Wunsch zu bleiben. Aber irgendwie müssen wir ja die letzten Tage, wo man zwischen Mediatheken und Streaming-Diensten noch irgendeine Daseinsberechtigung für seinen vdr findet, in Würde gestalten.

    Hallo zusammen,


    bin zwar Arch-Nutzer, aber schon vor fast zwanzig Jahren, als ich auf den vdr gekommen bin, habe ich mich schnell von fertigen Binärlösungen verabschiedet und den vdr im Quellerzeichnis immer selbst gebaut.


    Nichtsdestotrotz war es meiner Erinnerung nach immer schwierig, für die gewünschten Plugins alle Patches von hier und dort zusammenzusammeln. Die PKGBUILDS auf AUR sind daher eine willkommende Quelle für mich, um diese Suche abzukürzen.


    Also:

    Ich würde es begrüßen wenn AUR eine Quelle bleibt, wo man transparent sieht, wie ein Paket noch baubar ist. Ein Binär-Repository für Archlinux wäre aus meiner Sicht verzichtbar.

    Habe gerade eine Aufnahme auf BBCOne HD mit vdr-2.4.4 abgeschlossen. Klappt bei mir wegen knapper schlecht-Wetter-Reserven nur in 95% der Fälle, bei stärkerem Regen verliere ich den Empfang. Aber gerade scheint alles in Ordnung zu sein.

    Denn ich will auch nach dem Schnitt und Löschen der ungeschnittenen Aufnahme noch wissen, dass es Fehler bei der Aufnahme gab (wohl wissend, dass es durch das Schneiden vielleicht weniger geworden sind)

    Mal als Laie dazwischen gefragt:

    Wenn es beim Schneiden dazu kommen kann, dass die Fehler weniger werden. Liegt das daran, das fehlerhafte Teile im Schnitt nicht mehr vorhanden sind oder kann der Schnitt ggf. Fehler auch reparieren? Dann wäre so eine Reparaturmöglichkeit doch eine spannende Sache?!

    Also vielleicht stehe ich ja auf dem Schlauch, aber unter /video/plugins/streamdev-server gibt es nur die streamdevhosts.conf und die meinst/ brauchst Du ja sicher nicht.


    In der setup.conf finde ich keine Settings zum Plugin, habe meine kpl setup.conf einfach mal angehängt.


    Und der Server startet ohne zusätzliche Optionen mit "-P streamdev-server". Als Client benutze ich vlc, also bin ich wahrscheinlich nicht wirklich nützlich.

    Files

    Das Plugin eepg scheint bei mir das Gewünschte zu tun.


    Das habe ich gemacht:


    In den source-Dateien des Plugins eepg findet sich im Unterordner "scripts" das script extract_vdr_chan_ids.pl. Das habe ich gestartet und den Pfad zu meiner channels.conf mit angegeben:



    Die Einträge von Channel 4 (der Sender mit EPG) und Channel 4 HD (der Sender ohne EPG) daraus wie folgt in die Datei /video/plugins/eepg/eepg.equiv dann wie folgt übernommen:

    Code
    1. #
    2. # Simply add a list of the channels in this file with the following format:
    3. #
    4. # <OriginalChannelId> <OtherChannelId> <ChannelName>
    5. #
    6. S28.2E-2-2041-9211 S28.2E-2-2068-21200 Channel 4 HD

    Der Ort der Konfigurationsdateien der Plugins ist natürlich distributions/ bzw. installationsabhängig. Wie auch immer, jetzt füllt sich das auch EPG von Channel 4 HD.

    In der README im Hauptverzeichnis es doch:


    Code
    1. One can define equivalent channels in the eepg.equiv file to "copy"
    2. EEPG data to other channels.
    3. E.g., CanaalDigitaalNL still sends Dorcel EEPG data on S19.2E, which can be used
    4. for Dorcel on S13.0E.
    5. Some sample eepg.equiv files are included.


    und

    Code
    1. Scripts
    2. The provided scripts in the package can also help generate the eepg.equiv file.
    3. For more information see README in scripts/


    Probiere ich baldmöglichst aus.

    Hhhm, es gibt in den Sourcen von eepg tatsächlich einen Unterordner "scripts" und dort findet man in der README:


    Aber so richtig schlau werde ich aus diesem Text noch nicht, versuche mal damit zu experimentieren.

    Sieht eigentlich genau nach dem aus, was ich suche.


    Leider kommt am Zielsender (Nummer 8 Channel 4 HD) nichts an, obwohl der Quellsender (Channel 4 mit der Nummer 14) gut gefüllt ist.


    Code
    1. bernd_b@ATHLON-XP:~$ cat /video/plugins/epgfixer/epgclone.conf
    2. # Copy EPG data from channel 1 to 3
    3. #1=3
    4. 14=8

    Finde leider nix zu diesem Problem, obwohl ich bestimmt nicht der erst bin, der darüber stolpert:

    Channel 4 HD liefert mir mit eepg nur die aktuelle und die nächste Sendung, der SD Kanal Channel 4 hat noch das kompette EPG.


    Im Moment versuche ich, beim Runterfahren des vdrs einfach die Kanäle in der timers.conf zu tauschen, ich programmiere also den SD Channel und beim automatischen Hochfahren sollte dann Channel 4 HD aufnehmen.


    Das gibt aber bestimmt Stress mit dem Suchtimer von epgsearch, der dann wahrscheinlich die SD-Aufnahme erneut einfügt und dann ..


    Mal sehen. Test läuft.


    Kennt aber jemand vielleicht einen eleganteren Weg, die EPG-Infos von dem einen Sender auf den anderen Sender zu übertragen?

    Zwei ältere Festplatten aus dem Schrank geholt und zwei vdrs kompiliert:


    a) aktuelles archlinux 32bit (Kernel 5.9.x); Treiber in Kernel vorhanden, nur Firmwaredatei noch in /lib/firmware kopiert

    b) altes 32 bit ubuntu (trusty 14.04) mit Kernel 3.13; diese Treiber hier verwendet


    Ergebnis:

    mit a) bekomme ich auf den ITV HD Kanälen nur grünen Bildmatsch im Player angezeigt, STV HD geht, aber offenbar störanfällig

    mit b) Empfang wie auf Windows mit der gleichen Karte, ITV HD geht auch


    Beim Integrieren des Treibers in den Kernel ist vielleicht was schief gelaufen. Da der in Version b) verwendete Treiber die Firmware offenbar direkt integriert hat, liegt es vielleicht auch an der Firmware? We'll will never know.


    Wer um der guten alten Zeiten willen die Karte unter Linux verwenden will, dem empfehle ich, sie nicht mit einem aktuellen Kernel zu verwenden, sondern sich die Mühe zu machen, den Vorgänger-Patch zu verwenden, wie der in Version b). Die Treiber (getestet die Version für Kernel 3.13) auch nochmal in Anhang.