Beiträge von M-Reimer

    Zitat

    ChanSort is a PC/Windows application


    Multiplattform hätte mir geholfen aber Windows habe ich schon lange nirgends mehr. Trotzdem danke für den Tipp.


    Favoritenlisten und Kanalnummern schließen sich nicht aus. Ggf legst du halt nur eine einzige Liste an.

    Das ist deutlich zu viel. Du darfst nicht vergessen, dass das dann alles statisch mit drangelinkt wird.


    Eventuell hilft es folgendes ans "configure" mit dranzubauen:


    --enable-decoder=ac3 \

    --enable-decoder=eac3


    Die Fehlermeldung von dir deutet auf einen fehlenden MP3-Decoder hin. Wird über Sat tatsächlich MP3-Codierter Ton gesendet? Ich dachte da gibt es nur Mpeg2-Ton


    Das wäre natürlich alles deutlich einfacher zu debuggen wenn jemand mithelfen würde, der tatsächlich noch die VDR-Ausgabe nutzt. Gesucht ist die minimale ffmpeg-Konfiguration die für softhddevice gerade so noch geht.

    Ich habe das für vdr4arch jetzt mal zurückgemerged. Ich werde das Paket in Zukunft auf jeden Fall so bauen und wenn es nicht funktionieren sollte, dann bitte Issues anlegen.


    "softhddevice" ist für mich "Legacy". Für modernere Nvidia-Grafik gibt es ein neues Plugin das auch noch gepflegt wird und direkt gegen ein aktuelles ffmpeg gebaut werden kann. Das alte "softhddevice" statisch gegen eine bekannt passende ffmpeg-Version bauen spart da dann viel Ärger.


    Eventuell müssen die ffmpeg-Build-Parameter noch angepasst werden. Eventuell könnte man sogar noch weiter einschränken. VAAPI wird doch mittlerweile von einem dedizierten Plugin gemacht, oder? Könnte also komplett raus. Auch alle Codecs außer MPEG2 und H264 dürften raus können.

    Hallo,


    Eventuell findet sich ja ein Arch Linux Nutzer, der das softhddevice-PKGBUILD hier mal testen kann:


    https://github.com/VDR4Arch/vd…/plugins/vdr-softhddevice


    Die Idee ist, endlich das alte ffmpeg2.8 Paket loszuwerden. Deshalb wird das Plugin gegen ein stark zusammengekürztes ffmpeg statisch gebaut.


    Ich habe allerdings keinen Plan ob dieses ffmpeg-build nicht zu minimalistisch ist und dann letztlich garnichts mehr geht.

    Jetzt habe ich zu "softhdcuvid" auch nochmal eine Frage:

    Ich habe in einem Pull-Request (unter anderem sollte softhddevice angefasst werden) die Rückmeldung bekommen, dass softhddevice für ältere Nvidias noch gebraucht wird (Legacy-Treiber).

    Stimmt das oder kann softhdcuvid (wenn man es so braucht) auch noch vdpau?

    Wenn ersteres, dann würde ich mal versuchen ein paar Zeilen von softhdcuvid in einem softhddevice-Patch zu bauen um softhddevice mit aktuellem ffmpeg zum Bauen zu bewegen.

    Das mit der nfo-Datei besser lassen. Der Dateiname muss passen. Das ist alles. Kodi holt dann bessere Metadaten aus dem Internet. Ich lasse die info-Datei vom VDR ohne sie anzufassen neben der TS-Datei liegen.

    Ja, mach das. Scheinbar ist VLC auch "out of date" geflagt. Ich gehe davon aus, dass die beiden Pakete dann zusammen aktualisiert werden.


    Wichtig ist für mich nur, dass alles ohne große Verrenkungen baut, denn ich kenne mich in dem Thema nicht aus. Ich werde dann auch nur einen Test machen ob die Pakete bauen. Wenn das geht, schicke ich die PKGBUILDs ins AUR.

    Hallo,

    denke mal, dass er das schon selber kann. Ihm geht es um "libplacebo", da die bei Arch nicht aktuell ist.

    Einfach z. B. über das AUR auf die aktuelle Version updaten, geht nicht, da dann die Funktionen im VLC

    nicht mehr zur Verfügung stehen. Einfach erstmal weglassen würde gehen, läuft auch ohne.

    Können schon, aber ich kenne hier weder die Hintergründe noch werde ich das Plugin selber testen können.

    Wenn das jemand in vdr4arch (und damit indirekt auch direkt im AUR) haben will, dann bitte einen Pull-Request. An der Stelle ist einfach mal etwas Teamwork gefragt. Ich werde mich in der Zukunft selber hauptsächlich um das Thema "VDR mit Kodi" kümmern, denn genau dafür nutze ich VDR noch: Als reines Backend hinter Kodi.


    Wenn möglich bitte alle PKGBUILDs in den Pull-Request die für erfolgreiches Bauen nötig sind. Mit kurzem Hinweis welche vom AUR importiert sind. Was schon im AUR ist kann ich nicht hochsynchronisieren. Und wenn möglich, dann so, dass es sofort komplett mit repo-make baut.


    Ich lese dann kurz drüber, starte einen Auto-Build für mein privates lokales Repo und wenn das sauber durchläuft trage ich die im AUR fehlenden Pakete in den Sync-Prozess mit ein.

    Was libplacebo angeht: Ist ja schon "out of date" geflagt. Hoffentlich nimmt sich irgendwann jemand dem Problem an.

    Ansonsten werden bei vdr4arch immer gerne Pull-Requests gesehen. Diesen kann ich dann halt erst annehmen wenn libplacebo "upstream" up-to-date ist.

    Vorteil ist, dass wir von vdr4arch aus einen Auto-Sync zum AUR betreiben. Damit ist das PKGBUILD automatisch im AUR und wird automatisch mit den anderen VDR-Paketen aktuell gehalten.


    Edit: Braucht es denn unbedingt die aktuelle libplacebo? So lange gibt es die ja noch nicht. Wenn die alte auch geht könnte ich einen entsprechenden Pull-Request sofort annehmen.

    Dein Vorschlag ist mir durchaus aufgefallen. Ich habe das Plugin aber bewusst so umgesetzt.


    Das große Problem vom VDR ist (dank fehlender Favoritenlisten), dass die einzige verfügbare Kanalliste eine einzige Müllkippe ist. Wenn man mehr als einen Satelliten empfängt, dann bekommt man schnell über 1000 Einträge. Davon mehr als 90% für die Tonne.


    Meine Idee war deshalb wenigstens für das EPG etwas Platz und Zeit sparen zu können indem ich die "Müll-Liste" an einer definierten Kanalnummer trenne.


    Ab dieser Kanalnummer juckt mich kein Kanal mehr. Ich will also auch nichtmal das kleinste Bisschen EPG sehen.


    Wenn ich darunter einen neuen Kanal finde, den ich nutzen will, dann muss dieser nur "vor die Grenze" verschoben werden. Der VDR holt dann umgehend das EPG ab.