FireFly Ich kann auch nicht erkennen, warum diese zwei Mutexe sich blockieren sollten. Es handelt sich ja offensichtlich um zwei verschiedene,
(this=0x61bde0 <RecordingsHandler+96>) und
(this=0x61bc00 <cControl::mutex>).
Die Gleichheit der Namen dürfte eigentlich auch keine Rolle spielen, denn sie sind ja in völlig verschiedenen Klassen. Um das auszuschließen könntest du ja mal einen der beiden umbenennen und das Ganze nochmal nachstellen.
Schau ich mir an, werde aber erst kommende Woche dazu kommen.
Welchen Vorteil es bringen soll, statt der an die VDRVERSION angelehnten APIVERSION eine andere laufende Nummer zu nehmen, erschließt sich mir nicht. Ich hatte vergessen, in der Freigabenotiz darauf hinzuweisen, dass Plugins nicht neu übersetzt werden müssen. Das werde ich künftig automatisieren. Vorerst lasse ich es mal so, wie es ist.
Der Sinn der separaten APIVERSION ist, dass bei Änderungen, die keine externen Schnittstellen betreffen, Plugins nicht neu übersetzt werden müssen. Nachdem aber jedes Mal, wenn ich diese nicht parallel zu VDRVERSION hochzähle, jemand sich beschwert, ist es vielleicht an der Zeit für
--- ./config.h 2023/02/17 12:04:45 5.12
+++ ./config.h 2023/02/21 20:38:32
@@ -26,9 +26,10 @@
#define VDRVERSNUM 20604 // Version * 10000 + Major * 100 + Minor
// The plugin API's version number:
+// Seemed like a good idea at the time, but causes nothing but irritation...
-#define APIVERSION "2.6.3"
-#define APIVERSNUM 20603 // Version * 10000 + Major * 100 + Minor
+#define APIVERSION VDRVERSION
+#define APIVERSNUM VDRVERSNUM
// When loading plugins, VDR searches them by their APIVERSION, which
// may be smaller than VDRVERSION in case there have been no changes toDas Device ist an dieser Stelle nicht unbedingt das, welches tatsächlich verwendet würde, das wird ja erst in SetChannel() über GetDevice() ermittelt. Wenn es nur *ein* Device gibt würde es zwar stimmen, aber im allgemeinen Fall nicht.
MarkusE Sorry, war einfach mein erster Gedanke, da sich in der Ecke was geändert hatte. Aber du hast natürlich Recht, bei nur einem Device spielt das keine Rolle.
Probier bitte mal das hier:
--- device.c 2023/02/16 14:53:38 5.7
+++ device.c 2023/02/20 10:54:49
@@ -807,6 +807,10 @@
bool cDevice::SwitchChannel(const cChannel *Channel, bool LiveView)
{
if (LiveView) {
+ if (!PrimaryDevice()->CanReplay()) {
+ isyslog("can't switch to live channel %d %s (%s)", Channel->Number(), *Channel->GetChannelID().ToString(), Channel->Name());
+ return false;
+ }
isyslog("switching to channel %d %s (%s)", Channel->Number(), *Channel->GetChannelID().ToString(), Channel->Name());
cControl::Shutdown(); // prevents old channel from being shown too long if GetDevice() takes longer
// and, if decrypted, this removes the now superfluous PIDs from the CAM, tooVersuch bitte mal, das hier rückgängig zu machen:
VDR version 2.6.4 is now available at the official VDR GIT archive
git://git.tvdr.de
You can also get the latest stable version with
git clone --branch stable/2.6 git://git.tvdr.de/vdr.git
or as a tar archive with
http://git.tvdr.de/?p=vdr.git;a=snapshot;h=refs/tags/2.6.4;sf=tbz2
This version fixes a few bugs that came up after the release of version 2.6.3.
The changes since version 2.6.3:
- Updated the Italian OSD texts (thanks to Diego Pierotto).
- Fixed restoring the volume at program start (thanks to Matthias Senzel).
- Fixed symmetry of Begin/EndSegmentTransfer() calls in cEIT::cEIT() (thanks to
Jörg Wendel).
- Added a note to epg.h about not messing with event ids (suggested by Winfried Köhler).
- Added a note to vdr.5 about event ids possibly changing when an event moves from
one table to another.
- Fixed initializing cDvbPlayerControl (was broken in version 2.6.3).
- Reverted 'Fixed a possible crash if an editing process is canceled while the edited
recording is being replayed' (introduced in version 2.6.2), because it caused a
deadlock when moving recordings between volumes.
- Fixed a possible crash if an editing process is canceled while the edited recording
is being replayed (new solution).
- Fixed unnecessary interruption of ongoing recordings if timers avoided the transfer
mode receiver device (thanks to Markus Ehrnsperger).
- Revised support for kernel based LIRC driver (thanks to Marko Mäkelä).
Homepage: http://www.tvdr.de
Facebook: https://www.facebook.com/VideoDiskRecorder
Have fun!
KlausIch kann das Verhalten nachvollziehen und auch die Verbesserung durch deinen Patch.
Werde ich übernehmen.
Ich habe jetzt mal die Änderung
Klaus Schmidinger's git trees - vdr.git/commitdiff
rückgängig gemacht und dafür beiliegenden Patch vdr-2.6.3-fix-deadlock.diff gemacht. Damit sollten die aktuellen Deadlocks behoben sein (weil das Verhalten wieder so ist wie vorher) und der Absturz beim Abbrechen eines Schnittvorgangs, während die geschnittene Aufnahme abgespielt wird, auch gefixt sein (letzteres hab ich selber verifiziert).
In vdr-2.6.3-fix-deadlock-full.diff ist auch das Rückgängigmachen der ursprünglichen Änderung mit drin.
MarkusE Nachdem der Fehler anscheinend nicht (mehr) auftritt gehe ich mal davon aus, dass es nicht daran gelegen hat. Wäre auch unwahrscheinlich, denn wenn es einen Event gibt, dann *muss* es auch einen Channel dafür geben.
Das dvbsddevice-Plugin wird von mir nicht mehr gepflegt.
Gibt es tatsächlich noch Leute, die diese Uralt-Devices verwenden? 
Ich habe voraussichtlich kommende Woche wieder etwas Zeit für VDR, da werde ich das machen.
Letztendlich war die Lösung eine ganz andere ;-).
Die Motoren werden mittels eines MD13S gesteuert. Wie ich mir das Datenblatt davon so durchgelesen habe, fiel mir das Feature "Regenerative Braking" auf. Das bedeutet ja, dass, wenn der Motor durch externe Kraft angetrieben wird, dieser als Generator fungiert und Spannung zurück zur Quelle liefert. Um das zu verifizieren habe ich dann eine Schottky-Diode (30A 50V) in die Plus-Leitung vom Netzteil eingefügt und siehe da, das Problem war weg! Das Oszilloskop über die Diode angelegt und:
Über der Diode fallen in dem Moment, wo der Motor am unteren Umkehrpunkt ist, Gegenspannungen von bis zu 30V ab! Das hat das Netzteil wohl nicht so gerne und schaltet kurz ab. Überbrücke ich die Diode, ist das Problem sofort wieder da.
Also Entwarnung, das Problem ist gelöst und ich brauche gar kein stärkeres Netzteil :-).
Danke für eure Hinweise und Tipps, die mich zum Nachdenken angeregt haben.
Mit der Aussage wäre ich vorsichtig. Ein Netzteil kann durchaus auch gezielt so ausgewählt werden das es auch eine Schutzfunktion erfüllt.
Da hast du natürlich auch wieder recht.
...würde ich zu allererst mal beim Hersteller ein Ticket aufmachen.
Hab ich schon. Aber von denen kommt leider diesbezüglich keine wirkliche Hilfe.
Ich habe mir jetzt mal ein 480W-Netzteil besorgt und werde das morgen gegen das für den hinteren Motor tauschen. Mal sehen, wie es sich damit verhält. Das passt zwar wegen seiner 50mm Höhe nicht ins Gehäuse (Länge und Breite schon), aber falls das die Lösung sein sollte, könnte ich durch Versetzen anderer Komponenten Platz dafür schaffen.
Delta Electronics MEB-1K2A24T AA, 127 x 204 x 40.5 mm
Das dürfte sehr teuer sein
Eventuell lässt sich die dynamische Anforderung an das NT verringern, indem eine Capbank parallel zu den 24V die Stromspitzen übernimmt.
Ich fürchte, da würde das Netzteil bereits beim Einschalten in die Knie gehen, wenn die Kondensatoren leer sind.
Könnten 2 Meanwell HRPG-600 218x105x63,5 rein gehen?
Die kann man parallel schalten. Wird dann aber kein billiger Spass...
Könnte vielleicht gehen, dürfte aber eng werden (und teuer ;-).
Immer am gleichen Motor?
Das betrifft alle sechs Motore, je nach Lastverteilung. Bei den beiden hinteren tritt es am deutlichsten auf.
Das hat schon Sinn, um die Motoren und Leistungselektronik zu schützen
Unter Umständen zerlegt mit einem Netzteil was anderes.
Da ist natürlich was dran.
Auf den Bilder sieht es so aus, als ob die beiden Aktoren hinter dem Rücken mehr Last ab bekommen, als die Vorne.
Das ist vermutlich auch so. Nur um den Sitz weiter nach vorne zu bringen müsste ich ziemlich viel zerlegen. Einfach auf den Schienen nach vorne schieben verringert den Abstand zu den Bedienelementen, was ungut wäre. Aber für einen schnellen Versuch werde ich das mal machen.
Oder man packt noch eine vorgespanne Schraubenfeder drunter, damit kann man einen guten Teil der Last aufnehmen.
Ursprünglich waren da Gasdruckfedern vorgesehen (mit den alten Getrieben), was aber mit den neuen Getrieben nicht mehr benötigt wird (laut Hersteller). Vielleicht bau ich sie zumindest hinten mal versuchsweise wieder ein.
Die Spindeln sind nach Vorschrift geschmiert?
Die laufen sehr leichtgängig, daran liegt es wohl eher nicht.
Lärm ist nicht das große Problem, da die Gehäuse, in die das reinkommen soll, eh schon je zwei relativ laute Lüfter haben. Und im Betrieb hab ich eh die VR-Brille mit Kopfhörern auf ;-). Nur leider der verfügbare Einbauplatz halt fix und nicht verhandelbar.
Noch etwas zum Hintergrund: die Plattform hat 6 Motore, von denen je 3 von einer "Control Box" gesteuert werden. In diesen Boxen befinden sich original 3 Netzteile 24V350W, je eines pro Motor. Leider kommt es bei manchen Bewegungen zu einer kurzfristigen Überlastung und das betreffende Netzteil schaltet kurz ab. Die Bauhöhe dieser Netzteile ist 30mm, und da ist 350W das Maximum, was sich finden lässt. 480W hat dann schon 50mm Höhe und davon passen keine 3 Stück rein. Es gibt aber keinen Grund, warum es 3 separate Netzteile sein müssen, es kann also auch nur *eines* mit entsprechend höherer Leistung sein.
Die volle Leistung wird auch nicht kontinuierlich gezogen, sonder wird nur in Spitzen gebraucht.
Ich bin auf der Suche nach einem Netzteil, das 24V bei 1200W liefern kann.
Randbedingung ist, dass es nur eine maximale Größe von 215mm x 115mm x 100mm haben darf (die 100mm ließen sich notfalls auch auf 130mm erhöhen).
Hab schon relativ lang gegoogelt, bin aber nicht fündig geworden. Daher frage ich mal die "Schwarmintelligenz", vielleicht weiß ja jemand hier, wo ich sowas bekommen könnte.
Hat übrigens nichts mit VDR zu tun, sondern mit einem anderen Projekt (http://www.tvdr.de/flightsim).
