Posts by kls
-
-
Nevermind, hab eine Lösung gefunden:
https://www.qtcentre.org/threa…bject?p=287675#post287675
Mache ich in meinem Testbeispiel
Display MoreC- #include <QApplication>
- #include <QMainWindow>
- #include <QQuickView>
- int main(int argc, char **argv)
- {
- QApplication app(argc,argv);
- QMainWindow *w = new QMainWindow;
- QQuickView *view = new QQuickView;
- view->setSource(QUrl(QStringLiteral("qrc:///places_map.qml")));
- QWidget *container =QWidget::createWindowContainer(view);
- w->setCentralWidget(container);
- w->show();
- return app.exec();
- }
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:
Display MoreC- #if 0
- #include <QApplication>
- #include <QQuickView>
- int main(int argc, char **argv)
- {
- QApplication app(argc,argv);
- QQuickView view;
- view.setSource(QUrl(QStringLiteral("qrc:///places_map.qml")));
- view.setWidth(360);
- view.setHeight(640);
- view.show();
- return app.exec();
- }
- #else
- #include <QApplication>
- #include <QMainWindow>
- #include <QQuickWidget>
- int main(int argc, char **argv)
- {
- QApplication app(argc,argv);
- QMainWindow *w = new QMainWindow;
- QQuickWidget *view = new QQuickWidget;
- view->setSource(QUrl(QStringLiteral("qrc:///places_map.qml")));
- w->setCentralWidget(view);
- w->show();
- return app.exec();
- }
- #endif
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.
-
Du kannst auch ein cStatus implementieren und bekommst es über SetVolume() mit.
-
An die Tasten direkt nicht, aber kVolUp etc. werden in der Hauptschleife (vdr.c) verarbeitet und münden in cDevice::PrimaryDevice()->SetVolume() bzw. cDevice::PrimaryDevice()->ToggleMute().
-
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 ;-).
-
Passiert das nur bei bestimmten Sendern oder generell?
Sind irgendwelche EPG-Plugins installiert oder ist das "plain vanilla"?
-
Hab leider noch nichts weiter gehört.
-
Ist das die einzige Log-Meldung?
Was kommt denn im Client Log?
Sind die Rechte in der svdrphosts.conf richtig gesetzt?
-
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.
-
Was ist schlecht an der MicroSD?
-
Ich weiß nicht, ob sie auch die DVBSky S952 v3 getestet haben.
-
Naja, die CorrErr+ hatte die DD-Karte auf dem Board doch auch?
Aber nur auf der "Gegenseite":
Display MoreCode- vdr4:~ # lspci -vvv 2>/dev/null | grep -e CorrErr -e ^0
- 00:00.0 Host bridge: Intel Corporation Device 31f0 (rev 03)
- 00:00.1 Signal processing controller: Intel Corporation Device 318c (rev 03)
- 00:02.0 VGA compatible controller: Intel Corporation Device 3185 (rev 03) (prog-if 00 [VGA controller])
- DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
- 00:0e.0 Audio device: Intel Corporation Device 3198 (rev 03)
- DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
- 00:0f.0 Communication controller: Intel Corporation Device 319a (rev 03)
- 00:12.0 SATA controller: Intel Corporation Device 31e3 (rev 03) (prog-if 01 [AHCI 1.0])
- 00:13.0 PCI bridge: Intel Corporation Device 31d8 (rev f3) (prog-if 00 [Normal decode])
- DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
- 00:13.1 PCI bridge: Intel Corporation Device 31d9 (rev f3) (prog-if 00 [Normal decode])
- DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
- 00:13.2 PCI bridge: Intel Corporation Device 31da (rev f3) (prog-if 00 [Normal decode])
- DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
- 00:13.3 PCI bridge: Intel Corporation Device 31db (rev f3) (prog-if 00 [Normal decode])
- DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
- 00:15.0 USB controller: Intel Corporation Device 31a8 (rev 03) (prog-if 30 [XHCI])
- 00:1f.0 ISA bridge: Intel Corporation Device 31e8 (rev 03)
- 00:1f.1 SMBus: Intel Corporation Device 31d4 (rev 03)
- 01:00.0 Multimedia controller: Digital Devices GmbH Cine V7
- DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
- 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)
- DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
- 04:00.0 Multimedia controller: Digital Devices GmbH Cine V7
- DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
-
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.
-
Da hast du wohl recht.
-
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...
