Posts by kls

    Nevermind, hab eine Lösung gefunden:


    https://www.qtcentre.org/threa…bject?p=287675#post287675


    Mache ich in meinem Testbeispiel

    dann klappt's! :-)

    Mal was ganz Anderes ;-).

    Kennt sich hier vielleicht jemand mit Qt aus?

    Ich versuche gerade in einem Widget-basierten Programm eine Landkarte darzustellen. Das Widget soll in einem QSplitter eingefügt werden, daher kann ich nicht QQuickView verwenden, sondern brauche QQuickWidget.

    Zum Ausprobieren habe ich das mit Qt gelieferte Beispiel "places_map" genommen und auf QQuickWidget umgestellt:

    Mit "#if 1" in der ersten Zeile verhält sich das Programm normal und zeigt eine Karte an.

    Setze ich "#if 0" erscheint zwar ein Fenster, aber es bleibt leer. Einziger Unterschied zwischen beiden Varianten ist, dass bei "#if 0" die Meldung


    serialnmea: No known GPS device found. Specify the COM port via QT_NMEA_SERIAL_PORT.


    ausgegeben wird, was im anderen Fall nicht erfolgt.


    Ich muss zugeben, dass meine Erfahrungen mit Qt schon eine Weile zurückliegen, und ich mit QQuick noch nie etwas gemacht habe. Vielleicht übersehe ich also irgend etwas Offensichtliches...

    Während ein VDR läuft bleiben die IDs für Timer und Recordings konstant. Ein Client, der eine SVDRP-Verbindung aufrecht erhält, kann sich sicher sein, dass eine einmal erhaltene ID so lange gültig ist, wie die Verbindung steht. Bricht die Verbindung ab (z.B. weil der VDR neu startet), so "weiß" der Client, dass die IDs nicht mehr gültig sind. Er muss die Verbindung eh neu aufbauen und sich die Listen neu holen.

    Erstmal meinen Web-Server updaten (läuft immer noch mit openSUSE 13.2), einen GIT-Server aufsetzen (nein, ich werde nicht Github o.ä. benutzen) und die VDR-Source dort einspielen (das Script, welches RCS in GIT konvertiert, ist inzwischen fertig und funktioniert sehr gut).

    Danach die ganzen Patches, die inzwischen hier gepostet wurden, anschauen und ggf. einbauen.

    Und dann sehen wir weiter...


    Ich bin die erste Oktoberhälfte unterwegs, also bitte nicht wundern, wenn ich da nichts von mir hören lasse ;-).

    Als ich vor nunmehr zwanzig Jahren angefangen habe, VDR zu entwickeln, war es mein Ziel, ein System zu haben, mit dem DVB angeschaut, aufgezeichnet und wiedergegeben werden kann. Genau das macht VDR, das ist seine Aufgabe. Freilich nutze ich inzwischen auch andere Quellen, wie etwa Netflix, iTunes oder Mediatheken. Hierfür gibt es verschiedene Möglichkeiten, bei mir ist es ein Apple-TV. Ich sehe keinen Grund, das alles mit in den VDR hineinzustopfen. Für "himmlische" Sachen führt ja seit einiger Zeit leider wieder kein Weg an dem entsprechenden Receiver vorbei, bei dessen Benutzung ich immer wieder schreien könnte. Diese Funktion hätte ich schon gerne (wieder) direkt im VDR ;-).

    Ich bin gerade dabei, ein Script zu schreiben, welches mein RCS in ein GIT verwandelt. Das Ergebnis möchte ich dann auf meinem Server (tvdr.de) mit einem eigenen GIT-Server zur Verfügung stellen, damit es künftig keine "Beschwerden" mehr wegen eines fehlenden "offiziellen" GIT-Archivs oder "Patch-Orgien" gibt ;-).


    Ich selber werde weiterhin mit meinem guten alten RCS arbeiten und meine Änderungen fallweise automatisiert ins GIT übertragen. Das GIT wird als quasi ein read-only Abbild meines RCS sein.

    Welche Software eignet sich denn am besten, um einen GIT-Server zu betreiben?

    Er sollte ein Web-Interface haben, mit dem man alle Tags und Branches anzeigen lassen und Versionsstände auschecken kann (auch als Archiv).

    Was es nicht braucht sind Pull-Requests oder Issue-Tracker (sollte, falls vorhanden, abschaltbar sein).

    Das Problem hatte ich auch, auf drei verschiedenen RasPis. Damals hatte ich 8GB SD-Karten von Kingston in Verwendung, die regelmäßig kaputtgingen. Seit ich auf 4GB-Karten von Transcend umgestiegen bin, laufen sie problemlos und stabil. Wobei ich nicht sagen kann, ob es am Hersteller liegt oder daran, dass die neuen Karten 4 statt 8GB haben.

    Naja, die CorrErr+ hatte die DD-Karte auf dem Board doch auch?

    Aber nur auf der "Gegenseite":

    Sorry, hat etwas gedauert, weil ich erst die Freigabe von DD für die angehängten Bilder erfragen musste.

    Die aktuelle Aussage von DD ist, dass es sicher am HW-Design des ASRock J3455M Motherboards liegt, wie die angehängten Screenshots ihres PCIe-Analyzers zeigen sollen.

    Die Erklärung von DD dazu:

    "Asrock_Crash zeigt ein "Nak" bei dem zuvor keine Datenpakete unterwegs waren. Danach werden Pakete nicht mehr acknowledged " ak" was dann nach kurzer Zeit zum crash führt. Das Zweite Bild Zeit weiter "Naks" die nicht zum Crash führten aber nicht vorkommen dürften. Dem Hersteller muß das Problem bekannt sein, da er das Problem von der 1.4 Firmware bis zur 1.6er Firmware deutlich verbessert hat, aber offensichtlich geht die Lösung nicht weit genug. Wir versuchen gerade herauszufinden was der Hersteller hier geändert hat. Wir nutzen mit der gleiche CPU ein Board von Faytech ( FAY003 gefertigt von ASUS) das ein solches Verhalten nicht aufzeigt."


    Man ist wohl mit ASRock in Kontakt, aber ob sich von deren Seite was tut, ist ungewiss.


    Mit dem J4105M läuft die DD-Hardware dagegen soweit stabil.

    Kann ich bestätigen :-(.

    Mit der skincurses.c aus Version 2.4.0 funktioniert es.

    Ulrich Eckhardt : kannst du dazu was sagen? Von dir stammt ja der Patch, den ich (bis auf eingefügte Blanks, wobei ich jetzt sehe, dass ich noch zwei Stellen übersehen hatte) 1:1 übernommen habe. Allerdings habe ich es wohl aus Zeitgründen nicht selber getestet, sondern mich darauf verlassen, dass es bei dir funktioniert hat...