Posts by FireFly

... ein klein wenig Produktpflege ...

Änderungen:

- changed deprecated '%a' to the POSIX compliant '%m' in all scanf() calls (thanks to hd.brummy@VDR-portal)

Hier geht es zur Homepage

und hier direkt zum Download 0.1.5

Happy compiling

FireFly

Ok, Aber dann die offizielle Nummerierung von kls zu verwenden wenn er nicht auf dessen FTP Server zu finden ist, halte ich trotzdem für fraglich und verwirrend ....

Was soll das?!?!? Den Patch 43 gibt's auch nicht bei kls auf dem FTP Server, sondern ist nur an den Post angehängt, ist also kein offizieller Patch von kls !!!!

Das hier ist der korrekte Link:

http://ftp.tvdr.de/Developer/P…dex-vs-device-number.diff

Warum lässt Du naludump nachträglich drüber laufen? Es gibt auch nen Patch, der das direkt bei der Aufnahme macht

Ist auf dem Board(s) ein ASmedia 1083 als PCIe to PCI Bridge?

Der hat nämlich Probleme mit Interrupts und es gibt keinen sinnvollen Workaround
https://www.spinics.net/lists/linux-btrfs/msg28010.html

Wurde auch schon mal hier diskutiert

Ok, das kann sein. ARD alpha HD wird ja auch bis auf weiteres hochskaliert

pbg4 wrote:

seit gestern ist Radio Bremen HD auf Sendung,

seit gestern? Ich habe die schon seit einigen Wochen in meiner channels.conf .... IIRC sind die Anfang des Jahres live gegangen

kls wrote:

Das würde dann aber heißen, dass der Fehler im lircd passiert, was aber wiederum heißen müsste, dass LIRC (zumindest in der Version, die bei openSUSE Leap 15.0 dabei ist) nirgendwo funktionieren kann - was ich mir aber eigentlich auch nicht vorstellen kann...

Ich nutze das Original LIRC von Leap 15.0 zusammen mit einem selbstkompilierten yausbIR Modul für LIRC. Das ist zwar noch nicht im produktiven Einsatz, funktioniert aber einwandfrei. Das Problem müsste sich dann auf das serial_ir-Modul beschränken.

Hast Du mal den Quellcode des Moduls zwischen Raspi und Leap verglichen?

Oder ein anderes LIRC RPM probieren? https://software.opensuse.org/package/lirc

Na, was macht der Läufer? Er läuft, genau wie die Sendung vor der er steht, äh, läuft

Wenn ich bei Aufnahmen mit den Tasten 4 und 6 die Schnittmarken justieren will, zittert das Standbild bei 720p Aufnahmen, d.h. es wird erst ein Bild davor/dahinter angezeigt und dann bleibt das Richtige stehen. Der folgende Patch behebt das bei mir für alle Auflösungen (inkl. 2160p), ausgeliehen vom softhdcuvid Plugin

Kannst Du nicht wie ein Skin ein neues OSD aufmachen?

Problem könnte nur sein, dass bereits ein OSD von einem Skin auf ist ....

Für openSuse hatte ich schon mal hier was gepostet. Evtl. kannst Du Dir von dem spec-File im Source-RPM was abschauen, das make etc. müsste ja ähnlich sein ....

TEN wrote:

Gab es mal eine VDR-Version, die (beim Schneiden?) .vdr (PES) in .ts umwandeln konnte?

Nein. Da der VDR auch PES abspielen kann bestand auch nie die Notwendigkeit. Ansonsten wie oben schon geschrieben wurde mit Project X oder ffmpeg umwandeln, das geht bei beiden mit den richtigen Einstellungen ohne Neukodierung.

von https://www.heise.de/newsticke…sselt-in-UHD-4111534.html

Quote

Am Sonntag strahlt ProSiebenSat.1 eine Folge Galileo Spezial in UHD-Auflösung aus. Die Sendung ist unverschlüsselt über Satellit empfangbar.

Am Sonntag, den 22.07.18, zeigt ProSiebenSat.1 eine Folge Galileo Spezial in UHD. Zusätzlich zur höheren Auflösung wird der Inhalt unter Einsatz des HDR-Verfahrens Hybrid Log-Gamma (HLG) ausgestrahlt, das bessere Farben verspricht. Laut Pressemitteilung der Sendergruppe ist "Galileo Spezial: Pauschal gegen Freestyle - der beste Urlaub auf den letzten Drücker" über Astra-Satellit auf dem Sender UHD1 by HD+ unverschlüsselt empfangbar.

Über die digitalen Kanäle von ProSiebenSat.1 kann man die UHD-Folge von Galileo ab Montag "für kurze Zeit" auch auf Abruf in hoher Auflösung ansehen. Parallel zur UHD-Ausstrahlung wird die Folge wie gewohnt in SD und HD auf den entsprechenden Sendern gezeigt. .....

xcb_connect .... ist das der Connect zum X-Server? Läuft der X-Server?

wla wrote:

Wäre es vielleicht möglich, dass Du die Treiber bereits compiliert bereitstellst für Leap 15.0?

Dann müsste ich bei neuen Kernelversionen immer neue Pakete erzeugen und wäre ständig am hinterherlaufen. Und wenn ich mal keine Zeit habe könnte keiner den Kernel upgraden (oder schlimmer: man macht einen Upgrade und es gibt keinen Treiber - was dann?). Deshalb denke ich Hilfe zur Selbsthilfe als source RPM ist da besser. Um den suse build service zu nutzen habe ich momentan weder Zeit noch Muße....

Ich habe die Tage schon mal mit der Beta experimentiert und mein Treiber-RPM angepasst. Es kompiliert und die Treiber werden geladen, der Testrechner hat aber keine S2-6400.

Download des Source-RPM hier, dann das Source-RPM installieren und mit rpmbuild -bb <spec-file> die RPM Pakete für Treiber und Firmware erstellen und anschließend installieren

aus gegebenen Anlass (zypper will Updates einspielen):

als Repo habe ich unter 42.3 eingebunden:

und er will folgendes updaten:

ich habe bei mir folgende Buildrequires drin (compiliert unter 42.3 und 15.0 Beta):

wobei die libav* alle von Packman kommen. Damit compiliert es erfolgreich. Ob es auch läuft kann ich mangels geeigneter CPU noch nicht testen.