Posts by kls

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.

SHF wrote:

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.

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...

In der endgültigen Version 2.4.1, die ich soeben freigegeben habe, ist in recording.c noch eine Änderung mit drin, die das .update-File auch nach dem Entfernen gelöschter Aufnahmen getoucht wird, so dass andere VDRs, die das selbe Video-Directory verwenden, nicht zu viel freien Plattenplatz anzeigen.

In vdr.c wurde an einer Stelle die Einrückung korrigiert. Also nicht wundern, wenn es einen Unterschied zu den hier geposteten Patches gibt.

Halte ich mal fest.

Das Problem ist inzwischen geklärt. Es liegt an einem Fehler in der DrawText() Funktion von rpihddevice für den Fall, dass der String leer ist. In VDRs DrawDeviceData() (skinlcars.c) ist DeviceType wegen des mit vdr-2.4.0-06-fix-channel-switch.diff eingeführten cControl::Shutdown() leer, was den Fehler triggert.

Thomas weiß Bescheid und hat vor, das am Wochenende zu fixen.

Der Patch http://ftp.tvdr.de/Developer/P…s-compatibility-mode.diff korrigiert die Behandlung des S2SatelliteDeliverySystemDescriptors für Transponders die im "backwards compatibility mode" senden.