Posts by M-Reimer

Das wurde damals, wie der Counter erstmals veröffentlicht wurde, schon vorgeschlagen. War da aus "optischen Gründen" nicht erwünscht.

Post

RE: VDR User Counter: jetzt mit Karte!

@atl:

Gute Idee. Gleich löschen erscheint mir auch etwas heftig.

@M-Reimer, @Copperhead:

Ich hab da jetzt eine Nacht drüber geschlafen und mir auch die verschiedenen Kartenstile angeschaut. Aber irgendwie sieht für mich einfach keine der OpenStreetMap-Karten so gut aus wie die von Google-Maps. Sicher ist das Geschmackssache und womöglich bin ich da auch ein Opfer des "Baby Duck Symdroms". Mir geht es da vielleicht wie so manchem VDR-User, der findet, daß die Default-Skin nicht gut…

kls

Mar 4th 2015

War das nicht so das Google mittlerweile Geld sehen will?

Bei dem kleinen fehlt sogar die Schottky direkt am USB. Man sieht das 5V direkt verbunden ist.

Ja, da auf jeden Fall Leiterbahn unterbrechen und dann separat über den 5V Pin versorgen.

Die größte Gefahr ist da die 5V in den USB Port zurückfließen. Und dagegen müsste die Diode doch am USB Stecker sitzen.

Ich würde wohl ein USB Kabel modifizieren damit in dem die rote Leitung gar nicht mehr verbunden ist.

Falls in Zukunft jemand einen einfachen Gesamtüberblick über die API-Version braucht:

Das wird im Rahmen der Erzeugung des Mirrors vollautomatisch erzeugt.

Ja. Sorry. Zu spät editiert 😂

Quote from wirbel

Eine Frage noch am Rande von mir, sind die Paketbauer mit der Namensgebung der Plugins einverstanden?

libvdr-foo.so.5 -> vdr plugin foo mit VDR API = 30005

Der Unterschied ist eigentlich nur ein Problem für Plugin Entwickler. Die 30000 Offset sind nötig damit die Nummer steigend bleibt.

Für die Paketbauer ist die API Version die "5". Ich werde mit dem nächsten VDR Update auch bei Arch nur die eigentliche Version ohne das rein interne Offset hinterlegen.

Etwas ähnliches liegt auch schon als Issue beim Projekt. md_berlin nutzt du das Plugin noch? Andernfalls würde ich das vorerst auf vdr-projects parken und den Fix da einbauen.

Oder man macht ein Plugin draus das die tvscraper Schnittstelle bereitstellt.

Sehe jetzt gerade erst das ich mich verlesen hab. Da steht ja auch PCIe.

Er schreibt PCI. Ich hoffe wirklich es war PCI-Express gemeint.

Ich weiß ja nicht was das werden soll. Eine Herausforderung was man aus uralter Hardware noch machen kann?

Die S2-6400 war genau dafür gedacht schwächeren PCs zu Full-HD Wiedergabe zu verhelfen. Ich würde das System genau in der Konfiguration lassen und nur VDR auf der S2-6400 fahren. Dann einen Raspberry Pi statt der Grafikkarte an den AVR hängen und da drauf mit LibreElec ohne viel Verrenkungen Kodi laufen lassen.

Kodi wird da schon rein technisch nicht drauf ausgeben können. Du brauchst eine Grafikkarte die das gewünschte Videoformat auch darstellen kann. Eine 23 Jahre alte Grafikkarte ist dafür "minimal" zu alt.

Matrox Millennium G550 Specs

Matrox Condor, 125 MHz, 2 Pixel Shaders, 1 Vertex Shaders, 2 TMUs, 2 ROPs, 32 MB DDR, 166 MHz, 64 bit

www.techpowerup.com

Quote

The Millennium G550 was a performance-segment graphics card by Matrox, launched on November 26th, 2001.

Ich will dir ja nicht den Spaß verderben aber ein Raspberry Pi eignet sich besser um mit Kodi halbwegs gut Video wiederzugeben.

Auch wenn das hart klingt aber ich würde versuchen den ganzen Kram halbwegs gewinnbringend zu "entsorgen" und von Null anfangen.

Zu Kodi ein definitives Nein. Kodi gibt auf einer Grafikkarte aus aber nicht auf der Full Featured Karte.

Tuxedo hat den Charme das die aus Deutschland sind. Und wenn was tatsächlich nicht läuft hätte man auch jemanden der angesprochen werden kann.

Wenn man "auf Nummer sicher" gehen will würde ich nicht nochmal irgendwas kaufen. Ich hab hier ein Lenovo Laptop bei dem ich ums verrecken nicht hinbekommen hab das das eingebaute Bluetooth funktioniert. Seit ich das besitze steckt da so ein keiner USB-Stick drin für Bluetooth.

Ich kann die Argumentation von shofmann aber schon nachvollziehen.

Irgendwann nach X weiteren Jahren will der eine oder andere Entwickler vielleicht Support für VDR Versionen vor dieser Änderung aufgeben. Diese führende "3" bleibt trotzdem auf ewig.

Quote from shofmann

Ehrlich gesagt, verliere ich so langsam das bisschen Überblick, den ich mir mühsam erarbeitet habe, über welche Git-Plattformen sich die Repositories der einzelnen Plugins verteilen und welcher Fork gerade "en vogue" ist.

Welcome to VDR-Projects

Hier wird aufgelistet wo jedes Plugin liegt. Das kann jeder hosten wo er mag, aber es wäre für alle hilfreich wenn irgendwie die Info ankommt wenn ein Plugin umziehen sollte. Auch hier bitte im Idealfall als Pull-Request. Repo wo das liegt ist auf der Seite oben verlinkt.

Quote from shofmann

In diesem Fall würde ich aber eher dafür plädieren, die Makefiles alten Plugins endlich auf den aktuellen Stand zu bringen als eine Evolution daran scheitern zu lassen.

Das setzt aber voraus das jemand die Arbeit macht. Ich unterstütze ja gerne und mittlerweile ist das zumindest in der Theorie einfacher denn je, weil man eigentlich für jedes Plugin auch ein Repo hätte. Aber dafür müsste auch jemand Pull-Requests auf https://github.com/vdr-projects anlegen, denn so gerne ich auch wollen würde: Die Zeit, hier Patches einzusammeln und in die verschiedenen Repos zu committen habe ich einfach nicht mehr.

Edit: Wobei ich absolut keinen Überblick habe ob es tatsächlich noch relevante Plugins mit altem Makefile gibt. Ich hatte selber mal ein paar angepasst die bei vdr4arch mitgebaut werden. Aber z.B. bei yaVDR sind ja viel mehr Plugins dabei. Vielleicht kann man sowas mit ein paar kreativen "greps" auswerten um zu wissen wie viele alte Makefiles noch im Umlauf sind?

Quote from MarkusE

Klaus hat diesen Vorschlag abgelehnt, und dafür 5 likes bekommen, unter anderem einen von Dir. Siehe

Das Like galt der Tatsache das zum damaligen Zeitpunkt eine Lösung gefunden wurde wie eine API-Versionierung möglich bleibt.

Quote from kls

APIVERSNUM muss auch in der neuen Variante gößer als 20609 sein.

Macht Sinn falls Plugins gezielt auf APIVERSNUM Preprozessor-Instruktionen hängen wollen.

Quote from kls

Die bisherige Möglichkeit, an einer solchen Stelle sofort sehen zu können, bei welcher VDR-Version sich das geändert hat, geht allerdings für künftige Werte von APIVERSNUM verloren.

Geht mit "git blame" recht einfach das auf ein Commit und so auch auf einen Zeitrahmen einzugrenzen.

Für mich klingt das nach einem verdammt guten Vorschlag. Passt damit auch besser zu anderen Libraries die nach interner Struktur versioniert werden und nicht nach der Version der Software, die die Library nutzt.