RPIHDDEVICE + Streamdev + aktueller VDR + RPI3 - ich bekomms nicht stabil zum laufen - bitte um HILFE

Was steht denn im Log, wenn das passiert?

Wie sehen die Einstellungen in der setup.conf für das Plugin aus?

Hast du die Patches eingebaut, die hier im Forum flottieren?

--- a/client/device.c
+++ b/client/device.c
@@ -188,7 +188,7 @@
 
 bool cStreamdevDevice::SetPid(cPidHandle *Handle, int Type, bool On) {
     Dprintf("SetPid, Pid=%d, Type=%d, On=%d, used=%d\n", Handle->pid, Type, On, Handle->used);
-    LOCK_THREAD;
+    //LOCK_THREAD;
 
     bool res = true; 
     if (Handle->pid && (On || !Handle->used)) {

Und außerdem:

--- a/client/socket.c
+++ b/client/socket.c
@@ -25,6 +25,7 @@
     m_Priority = -100;
     m_Prio = false;
     m_Abort = false;
+    m_SendABRT = true;
     m_LastSignalUpdate = 0;
     m_LastSignalStrength = -1;
     m_LastSignalQuality = -1;
@@ -268,8 +269,11 @@
     if (!CheckConnection()) return false;
 
     CMD_LOCK;
-
-    std::string command = (std::string)"TUNE " 
+    
+    std::string command = (std::string)"ABRT " + (const char*)itoa(siLive);
+    m_SendABRT = !Command(command, 220);
+    
+    command = (std::string)"TUNE " 
                 + (const char*)Channel->GetChannelID().ToString();
     if (!Command(command, 220))
         return false;
@@ -345,9 +349,12 @@
     CMD_LOCK;
 
     if (m_DataSockets[siLive] != NULL) {
-        std::string command = (std::string)"ABRT " + (const char*)itoa(siLive);
-        if (!Command(command, 220))
-            return false;
+        if(m_SendABRT) {
+            std::string command = (std::string)"ABRT " + (const char*)itoa(siLive);
+            if (!Command(command, 220))
+                return false;
+        }
+        m_SendABRT = true;
         DELETENULL(m_DataSockets[siLive]);
     }
     return true;
--- a/client/socket.h
+++ b/client/socket.h
@@ -25,6 +25,7 @@
     bool          m_Prio; // server supports command PRIO
     int           m_Priority; // current device priority
     bool          m_Abort; // quit command pending
+    bool          m_SendABRT;
 
     time_t        m_LastSignalUpdate;
     int           m_LastSignalStrength;
--- a/server/livestreamer.c
+++ b/server/livestreamer.c
@@ -672,23 +672,39 @@
 }
 
 void cStreamdevLiveStreamer::ChannelChange(const cChannel *Channel)
-{
+{    
     if (Running() && m_Device && m_Channel == Channel) {
-        // Check whether the Caids actually changed
-        // If not, no need to re-tune, probably just an Audio PID update
-        if (!memcmp(m_Caids, Channel->Caids(), sizeof(m_Caids))) {
-            dsyslog("streamdev: channel %d (%s) changed, but caids remained the same, not re-tuning", Channel->Number(), Channel->Name());
-        }
-        else {
-            Detach();
-            if (m_Device->SwitchChannel(m_Channel, false)) {
-                Attach();
-                dsyslog("streamdev: channel %d (%s) changed, re-tuned", Channel->Number(), Channel->Name());
-                memcpy(m_Caids, Channel->Caids(), sizeof(m_Caids));
-            }
-            else
-                isyslog("streamdev: failed to re-tune after channel %d (%s) changed", Channel->Number(), Channel->Name());
-        }
+        Detach();
+        int NumUsableSlots = 0;
+        if (Channel->Ca() >= CA_ENCRYPTED_MIN) {
+            for (cCamSlot *CamSlot = CamSlots.First(); CamSlot; CamSlot = CamSlots.Next(CamSlot)) {
+                if (CamSlot->ModuleStatus() == msReady) {
+                    if (CamSlot->ProvidesCa(Channel->Caids())) {
+#if APIVERSNUM >= 20303 
+                        if (!ChannelCamRelations.CamChecked(Channel->GetChannelID(), CamSlot->MasterSlotNumber())) {
+#else
+                        if (!ChannelCamRelations.CamChecked(Channel->GetChannelID(), CamSlot->SlotNumber())) {
+#endif
+                            NumUsableSlots++;
+                        }
+                    }
+                }
+            }
+            if (!NumUsableSlots) {
+                isyslog("streamdev: cam slot not available");
+                return;
+            }
+        }
+    
+        if (m_Device = cDevice::GetDevice(Channel, LIVEPRIORITY, false)) {
+            if (m_Device->SwitchChannel(Channel, false)) {
+                Attach();
+            } else { 
+                isyslog("streamdev: failed to re-tune after channel %d (%s) changed", Channel->Number(), Channel->Name());
+            }            
+        } else {
+            isyslog("streamdev: device not available");            
+        }
     }
 }

Die MLD 5.4 läuft hier auf einem 3b+ stabil. Allerdings habe ich das originale Wlan nicht zum laufen gebracht.

Ein angeschlossener Wlanstick funktioniert aber und hat auch einen besseren Empfang.

Gruß Jan

Hallo,

nutzt du die Pakte von eTobi? Ich habe vor einigen Monaten mal mit den aktuellen Paketen aus seinem Repro getestet und hatte immer Hänger. Ein Bug in streamdev war damals die Ursache. Habe es daher auch mit Sat>Ip probiert und dann gab es Probleme mit dem OSD. Tobi hat den benötigten Patch für streamdev in der Zwischenzeit eingebaut. Konnte das Ganze dann aber nicht mehr testen, da ich im Ausland war. Ab morgen habe ich wieder Zugriff und möchte dann einen neuen Versuch starten. Das alte System läuft auf einem Pi der 1. Generation, habe aber auch einen Zero und einen Pi 3B. Vielleicht finden wir ja gemeinsam eine Lösung?

Gruß

Motz_e

GTRDRIVER ich hab den VDR die letzten Jahre auch mit einem selbstgebauten Raspbian am laufen gehabt aber wenn er nur Client ist lohnt sich der Aufwand nicht wirklich. Nimm doch einfach MLD. Da hast du ja auch so ziemlich alle Möglichkeiten und kannst auf dem Server ja weiter den Eigenbau laufen lassen.

Ich hab damit auf jedenfall bessere Erfahrungen gemacht als mit meinen Eigenbauten. Ich hab auch immer wieder das Problem gehabt das beim Menüaufruf plötzlich der VDR neu gestartet hat und danach liefs wieder ganz normal weiter. Dank der tollen Versionierung vom VDR darf man ja in einem nicht funktionierenden Forum Patches zusammensuchen anstatt sowas einfaches wie GIT zu verwenden.. Das machen die Jungs von MLD in meinem Fall für mich

Ja MLD gibt's für einige Systeme und ich denke mal das ziemlich viele das mittlerweile auf dem Raspberry verwenden.

Ich hab mich vorher auch gesträubt irgendwelche fertigen Sachen zu verwenden aber MLD bietet ja genug Zugriff auf die Shell, apt ist dabei und es funktioniert eigentlich ziemlich gut.

Wenig Grund das alles selbst aufzusetzen zumal das dann auch noch langsamer booted und man auf viele Kleinigkeiten achten muß bzw. das anpassen muß.

Jepp... seh ich genauso. MLD drauf und gut ist. Macht ja keinen Sinn auf einem RPI zu compilieren. Bei mir laufen schon seit längerem zwei RPIs als Clients unter MLD.

Oh ja da bin ich dabei. Und geht mir genau so mit den fertigen Distris bin ich nie warm geworden und meine momentane Umgebung unter 2.2 läuft seit Jahren stabil und im Prinzip wartungsfrei.

Würde aber mittelfristig auch gerne 2.4 einsetzen um die Plugins für remote timer z.B. in Rente schicken zu können. Das läuft hier dann aber im Prinzip auf einen Neubau der Softwareumgebung hinaus, das hat mich bisher davon abgehalten.

Davon abgesehen hab ich als ich letztlich einen alten wenig genutzten RPI 1 Client auf einen aktuellen Rpi 3 upgraden wollen. Einer meiner Clients ist bereits ein Rpi3 die anderen sind Rpi2. Der neue 3er war nur mit dem nie upgedateten Image des existierenden 3ers zum laufen zu bekommen. Ein neu aufgesetztes Raspbian Stretch hatte immer Hänger beim Menü bedienen. Ich hatte das irgendwann dann mal auf irgendeine Lib heruntergetrackt dann aber einfach das laufende Image gecloned und war zufrieden damit und hatte keine Lust mehr weiter zu suchen.

Würde bei einer Neuauflage wieder da ansetzen und erst mal einen nackten VDR 2.4 als Raspi Streaming Client mit streamdev aufsetzen wollen und sehen wie das ohne weitere Plugins läuft. Dann die (für mich zumindest wegen WAF) wesentlichen Plugins (Fritzbox, SkinFlatPlus).

bye

Sven

Woran scheitert es denn? Im Grunde braucht ihr doch nur Raspbian, die build-deps vom VDR und den Sourcecode vom 2.4er.

Ich mach das immer ganz dirty, installiere den VDR vom Raspbian via apt, kompilieren den neuen vdr und tausch einfach die Binary aus und eben die Plugins dann auch.

Dann hat man in kürzester Zeit nen selbst kompilierten VDR am Laufen der mit den Startskripten vom Raspbian startet.

Anleitung gibt's eigentlich ja eh schon:

http://www.vdr-wiki.de/wiki/in…Client_-_VDR_Installation

Ja wäre auch eine Möglichkeit. Ich habe seit 2002 im Prinzip die gleiche Struktur wie ich einen VDR aufsetze. Die ist was die Dateistruktur betrifft recht unterschiedlich zum aktuellen Stnadard, deshalb habe ich immer direkt aus den Sourcen gebaut. Hat auch bisher geklappt bis zu raspbian Sarge mit den oben beschriebenen Problemen. Wie gesagt, ich vermute das das an irgendwelchen libs liegt und evtl. die Patches das lösen.

Muss mir das die Tage mal wieder genauer ansehen. Ein momentan ungenutzter Raspi 3 liegt hier noch rum werde den dann mal zum testen nutzen und von Grund auf ein neues Image bauen.

bye

Sven

Also bei den VDR-Patches wird man wohl um keinen drum rum kommen da kls mit dem Locking-Kram so viele Fallstricke eingebaut hat die dann auch noch bei unmöglichsten Kombinationen auftreten das die eigentlich doch Notwendig sind um eben genau diese Unregelmässigkeiten auszuschließen.

Ich würde an eurer Stelle ja erstmal mit einem 2.3er VDR probieren ob dieser auf der aktuellen Installation läuft. Damit könnt ihr schonmal die ganzen Libs als Ursache ausschließen.

Bzgl. Patches für Streamdev muß ich passen. Soweit ich weiß wurde das ja angepasst an die 2.3.7 und seitdem sollte das unter dem aktuellen 2.4er auch laufen.

Ich hatte damit eigentlich keine Probleme, ist aber auch schon wieder eine Weile her.

Fakt ist, das MLD z.B. mit dem aktuellen VDR eigentlich ordentlich läuft. Sollte also eigentlich auch Möglich sein das selbst ordentlich zum Laufen zu kriegen.

Hi,

sagen wir so, ich habe hier im Haus insgesamt 4 VDR Clients am laufen. Alle unter 2.2 und die laufen stabil, Hänger treten da wenn überhaupt vielleicht einmal im Monat, eher seltener auf. Das ganze unter Raspbian Wheezy oder Jessie. Unter Debian 9 Stretch gibt es einige interessante Effekte mit rpihddevice wegen lib Problemen, egal ob vdr 2.2 oder 2.4. Interessante Effekte gibt es dann auch mit z.B. dem skinflatplus das auf einmal keine EPG details mehr anzeigen will, classic oder lcars skin geht.

Was ich damit sagen will es gibt offenbar einige Abhängigkeiten die zu den o.g. Effekten führen. Was ich am Wochenende ausprobieren möchte ist ein sauberes Raspbian Image als Basis aufzusetzen. Dort dann zunächst einen plain vanilla vdr 2.4 nur mit rpihddevice und streamdev. Bisher habe ich dafür nie irgendwelche patches benötigt, weder für den vdr noch streamdev.

Offenbar gibt es aber, was ich in der letzten Zeit nicht wirklich verfolgt habe, durch diverse 2.4er Änderungen an den lock Machanismen hier Bedarf an Patches. Das muss ich mir auch erst mal noch anschauen.

Irgendwelche 2.3.x Versionen zu verwenden halte ich im ersten Schritt nicht für zielführend, denn wenn das läuft holt man sich wieder unbestimmte Probleme mit hinein durch Plugins die 2.4 voraussetzen (evtl. auch nur unabsichtlich) . Wenn 2.4 gar nicht stabil zu bekommen ist würde ich persönlich den Schritt zurück zu 2.3er Versionen lediglich zur Analyse machen wollen.

bye

Sven

Beim Lesen eurer Beiträge ist mir gerade eingefallen das ja ab 2.3 diese Problematik losging und sich eigentlich bis zur 2.4 hingezogen haben. Also würde ich zur Analyse ein neues System aufsetzen und die 2.2er testen und wenn die läuft auf die 2.4er wechseln.

Du hast BISHER keine Patches dafür benötigt weil die bisherigen Stable-Versionen auch Stable waren aber wenn du mal hier im Forum suchst findest du einen Thread von Klaus der dir mit seinen 7 Patches bestätigt das die 2.4er eigentlich ziemlich Müll ist und nicht so "stable" wie die Vorgänger.

Du wirst also mit der Vanilla definitiv noch Probleme haben die selbst der Entwickler kennt. Ohne Plugins anzufangen empfiehlt sich allerdings auf jedenfall. Viele Plugins waren früher schon beim VDR eher Fehlerträchtig und durch diese geänderten Locking-Mechanismen ist es anscheinend noch schlimmer zumal viele Plugins da nicht explizit drauf vorbereitet worden und der Teufel dann im Detail steckt.

Grüsse, Jan