Posts by fnu

  • [erledigt] HWE Stack: Wie mit alten Kernels umgehen?

    Hatte weder bei Trusty, noch Xenial oder aktuell Bionic Probleme, linux-libc-dev blieb bei allen über die HWE Einschübe gleich. Selbst Kernelmodule machten IIRC wenig Probleme.


    Das betrifft auch mehr die Pakete in der Distro, denn den Kernel. Nur durch die Beibehaltung über die Laufzeit kann man überhaupt Neueres zu vorhandenem Älteren hinzufügen, wie bei z.B. den HWE Stacks.


    Das embedded Ubuntu in Windows 10 ist z.B. Bionic mit genannter linux-libc-dev Version, der Kernel eine spezifische 4.4.0er Version ... gibt viele weitere Beispiele wo linux-libc-dev und kernel noch weiter auseinander liegen, z.B. alter Ubuntu LSB Release und recht aktueller Mainline Kernel ... etc.

  • Zusammenfassung Intel VAAPI & edid.bin

    447377


    Ja, da ist kein Unterschied, bleibt beim definierten HDMI Anschluß ... kein Konverter.


    Da habe ich dann leider nun auch erstmal keine Idee mehr, vmtl. wirst Du nicht drum rum kommen den VDR mal ohne HDMI Kabel zu starten, das Kabel einzustecken und danach mal alle Log Files auf verdächtiges zu prüfen ... :(


    Gruß

    Frank

  • [erledigt] HWE Stack: Wie mit alten Kernels umgehen?

    So grundsätzlich ist Kernel 4.15.0 nicht mehr an dieses HWE gebunden, sondern nun 4.18.0. Daher sollten sich die alten 4.15.0er Paket eigentlich problemlos deinstallieren lassen.


    Wenn ich das HWE Paket installiert habe, deinstalliere ich "linux-generic" und dann auch die "alten" Kernel Pakete ...


    Mit dem entsprechenden HWE edge Paket ist nun seit einiger Zeit auch Kernel 5.0.0 verfügbar. Ich behalte immer beide "linux-generic-hwe-18.04" && "linux-generic-hwe-18.04-edge", weil irgendwann der edge Kernel in das "normale" HWE findet und nach 6 Monaten wieder was neues in edge kommt ...


    Regards

    fnu

  • Wie "teilen" andere Distributionen das VDR-Paket?

    M-Reimer wrote:

    Bei Debian werden die Plugins wohl als ein separates Paket "abgespalten".

    Bei den Debian Paketen, worauf IIRC auch alle Pakete anderer Ubuntu/Debian basierter Distros basieren, wird eigentlich nur "vdr-plugin-examples" abgespalten. An den historischen Hintergrund dazu kann ich mich aber nicht mehr erinnern. "vdr-plugin-[dvbhddevice|dvbsddevice]" werden inzwischen ja so oder so getrennt gepflegt ...


    Nach meinem Verständnis sind die im VDR beinhalteten Plugins alles als Anschaungsbeispiele primär für den Code gedacht, auch wenn alle praktisch als sehr einfaches Plugin funktionieren.


    Mir ist keine Basis bekannt, wo sich jemand die Mühen gemacht hat, diese als eigenständige Pakete für ein Repository zu extrudieren. Weiß auch nicht ob ein Entwickler auf Pakete aus einem Repo zurückgreift oder eher direkt mit Quellcode arbeitet ...


    Regards

    fnu

  • xmltv2vdr lädt keine Daten

    Klar ist Kritik erlaubt, aber an Stellen wo es Sinn macht ... und nicht in einem Thread wo man versucht jemandem bei einem Problem zu helfen ... :rolleyes:


    Und ob Du das Plugin magst oder nicht, zumindest ich werde es weiterbenutzen solange es geht.

  • Zusammenfassung Intel VAAPI & edid.bin

    447377 wrote:

    Asus H310i-plus + i3-8100 + alsa

    Interessant, lt. Specs macht das Board auch "nur" HDMI1.4, wie die Kaby/Coffee Lake Intel Graphics, d.h. eigentlich sollte kein Konverter Chip von z.B. LSPCon dazwischen sein.


    Kannst Du dennoch mal prüfen was Dein VDR da macht, mit und ohne gesteckten HDMI Kabel, im entsprechenden Xorg Log?


    Gruß

    Frank

  • xmltv2vdr lädt keine Daten

    Wie utiltiy schon schrieb, speichert xmtltv2vdr die Zuordung in der setup.conf. Wenn diese also nicht verändert wurde, sollte diese Zuordnung immer noch der bisherigen entsprechen.


    Sieht etwa so aus:

    Code
    1. xmltv2vdr.channel.3sat.de = 0;3146767;S19.2E-1-1010-11150;S19.2E-1-1079-28007
    2. xmltv2vdr.channel.ard.de = 0;3146767;S19.2E-1-1019-10301;S19.2E-1-1101-28106
    3. xmltv2vdr.channel.arte.de = 0;3146767;S19.2E-1-1019-10302;S19.2E-1-1051-28724
    4. xmltv2vdr.channel.bayern3.de = 0;3146767;S19.2E-1-1025-10325;S19.2E-1-1025-10326;S19.2E-1-1101-28110;S19.2E-1-1101-28107
    5. xmltv2vdr.channel.br-alpha.de = 0;3146767;S19.2E-1-1093-28487
    6. ..

    Gibt aber noch eine Datei zum Grabber unter /var/lib/vdr/plugins/xmltv2vdr/, die normalerwiese alle definierten Sender enthält. Vmtl. wurde die durch die Neuinstallation überschrieben ... das meinte ich weiter oben mit:

    fnu wrote:

    [EDIT] Etwaige persönlich angepasste Konfigurationsdateien bzgl. des Grabbers vorher eben sichern ...


    Für die Neudefinition den VDR stoppen, die xmltv2vdr Mappings aus der setup.conf nehmen, VDR starten und neu definieren ...


    Regards

    fnu

  • Zusammenfassung Intel VAAPI & edid.bin

    Nein, bei mir ist das nicht nötig, funktioniert immer noch wie oben beschrieben. Bei meinen neueren Intel NUCs ist nur der Abzweig nötig, HDMI1 im Kernel beim Boot, in Xorg dann DP1, aufgrund des LSPCon HDMI 2.x Konverters.


    Erzähl mal was zur Hardware?


    Wie gibst Du den Ton aus, alsa oder pulseaudio?


    Regards

    fnu

  • xmltv2vdr lädt keine Daten

    Gerdchen03 wrote:

    soweit ich mich erinnere, ein HowTo von VDR-Wiki verwendet.

    Ok, d.h. Du hast den VDR vmtl. direkt aus Source-tgz gebaut, könnte evtl. das HowTo von sewn4 sein ... das basierte auf Ubuntu.


    Dann bringt der lokale Paket-Eigenbau eigentlich wenig. Das einfachste wäre Du passt in Deinen vmtl. noch lokal vorhandenen Quellen einfach die beiden URLs beim Grabber an und lässt es neu mit make bauen ...


    Regards

    fnu

  • xmltv2vdr lädt keine Daten

    Hmm, diese Abhängigkeit gibt aber nicht das verwendete Paket vor, die sind eigentlich eher generischer Natur .... :P


    Build-Depends: debhelper (>= 9), pkg-config, libxml2-dev, libcurl4-openssl-dev, libxslt1-dev, zlib1g-dev


    Ergibt sich aber offensichtlich leider als Folgeabhängigkeit aufgrund Deiner überholten Ubuntu Basis ...


    Dann eben kurz lokal neu bauen, so in groben Schritten:

    Code
    1. #/> cd /usr/src
    2. #/> mkdir grabber-tvm2xmltv
    3. #/> cd grabber-tvm2xmltv
    4. #/> dget -xuq https://launchpad.net/~fnu/+archive/ubuntu/stable-vdr-fnu/+sourcefiles/vdr-plugin-xmltv2vdr-grabber-tvm2xmltv/0.2.3-0fnu0~xenial/vdr-plugin-xmltv2vdr-grabber-tvm2xmltv_0.2.3-0fnu0~xenial.dsc
    5. #/> rm *xenial*
    6. #/> cd vdr-plugin-xmltv2vdr-grabber-tvm2xmltv-0.2.3/
    7. #/> debuild -i -us -uc -b
    8. #/> cd ..
    9. #/> dpkg -i vdr-plugin-xmltv2vdr-grabber-tvm2xmltv_0.2.3-0fnu0~xenial_i386.deb

    Wenn Du die Version und/oder Appendix ändern möchtest vor dem debuild debian/changelog mit dch -i -D precise anpassen, oberste Zeile ... das DEB Paket heißt dann eben so, wie von Dir definiert.


    Die o.a. Abhängigkeiten müssen vor dem debuild natürlich auch installiert sein.

  • xmltv2vdr lädt keine Daten

    Also m.E. musst Du den Grabber nicht neu bauen (lassen) ... der ist eigentlich unabhängig von der Plugin Version, es wird nur geprüft ob ein Paket vdr-plugin-xmltv2vdr installiert ist.


    Einfach eines der aktuellen DEBs (...0.2.3) runterladen und installieren, egal ob das xenial oder bionic heisst, sollten die sich auch auf älteren LSB Releases installieren lassen ...


    [EDIT] Etwaige persönlich angepasste Konfigurationsdateien bzgl. des Grabbers vorher eben sichern ...

  • Ärger mit "neuem" iphone 8 von ebay-Händler

    Die 1-jährige Garantie von Apple hat nichts mit der gesetzlichen Gewährleistung zu tun, die der Händler erbringen muss.


    Eigentlich schießt sich dieser Händler selbst ins Knie, da er das Gerät als Neuware verkauft und damit 24 Monate den Betrieb gewährleisten muss. Würde er es als gebrauchtes Geräte verkaufen, was es ja eigentlich ist, müsste er von Gesetzes wegen nur 12 Monate erbringen. Wäre es wirklich ein neues Gerät müsstest Du bei Apple auch Apple Care+ abschliessen können, kannst Du aber nicht, zertifizierte Händler passen die Garantiestartzeit bei echten neuen Geräten an das Verkaufsdatum an ....


    Die Seriennummer bzw. IMEI ist Apple egal, sie darf nur nicht als gestohlen gemeldet sein. Gegenüber diesem Händler würde ich allerdings auf die Rechnung mit korrekter Seriennummer bestehen, da Du gegenüber ihm die Gewährleistung für die nächsten 24 Monate einfordern müsstest. Ich würde das Gerät aber immer noch rückabwickeln, der Händler ist mir schon von hier aus schon suspekt ... glaube kaum das Du in einiger Zeit Dein Recht bei dem ohne juristische Unterstützung einfordern kannst. Und wäre das ein echt cooler Händler, würdest Du m.E. die Sachlage hier nicht darstellen ... ;)


    Ansonsten kannst Du für Dich auch entscheiden, das Gerät ist gut für Dich wie es ist, die Bedingungen ignorieren und es als gebraucht Kauf ohne weitere Gewährleistung behandeln. Dann wäre auch die Seriennummer auch egal.


    Regards

    fnu