Streamdev Client/Server + CI Modul = Glückspiel ?

Quote from GTRDRIVER

evtl gibts hier nen Patch

Ja, ein paar Threads weiter unten in diesem Unterforum gibt es was, das helfen soll: vdr-plugin-streamdev-server/-client => mit vdr 2.3.4 nur FTA möglich

Für beide - um das zu wissen muss man sich nur ansehen, welche Dateien vom Patch geändert werden.

GTRDRIVER

du kannst das repo auch direkt holen - mit allen enthaltenen patches:

https://github.com/ciminus/vdr…n-streamdev/commits/devel

Bitte berichten ob das bei Euch funktioniert mit dem Patch.

Bei mir gab es leider nur sporadisch Verbesserungen.

@Frodo du nutzt es auch mit Physik oder mit satip?

bei mir läuft es mit den Cine S V6 an unicable schon sehr schön. Manchmal, so ca einmal die Woche krieg ich den Server allerdings beim Zappen zum Blockieren, da hilft nur noch vdr restart auf dem Server.

Leider ist das ein Ausschlusskriterium, Client neustarten wäre noch zu verkraften aber wenns den ganzen Server VDR wegreißt ist das schwierig. Was mir auch im Vergleich zum satip nicht so gefällt ist das die Streams nach Restart des Servers ohne einmal umzuschalten nicht weiterlaufen.

Der Server hat bei mir Physik, d.h. 2x DD DuoFlex S2 V4 an Jess/Unicable + Digital Devices Octopus Duo CI.

Ich dachte ja es läuft, aber nach einem Restart des Servers konnte der Client sich gar nicht mer bzw. nur noch vereinzelt auf FTA Kanäle verbinden. Auch ein restart des Client VDRs brachte keinen erfolg.

guten morgen,

Quote from Frodo

Der Server hat bei mir Physik, d.h. 2x DD DuoFlex S2 V4 an Jess/Unicable + Digital Devices Octopus Duo CI.

Ich dachte ja es läuft, aber nach einem Restart des Servers konnte der Client sich gar nicht mer bzw. nur noch vereinzelt auf FTA Kanäle verbinden. Auch ein restart des Client VDRs brachte keinen erfolg.

selbiges verhalten kenne ich, sobald der patch

ring buffer overflows -> cDevice::Detach() blockiert...

installiert wird.

das haengt evtl. mit den ganzen patches zusammen, die in @frodos testing-vdr-dev fuer den vdr gezogen werden. ein vanilla-vdr 2.3.8,

mit den beiden genannten patches fuer den vdr und streamdev, laeuft hier seit 20.12.17 ohne unterbrechung und absturz als server

gruss

beinhart

Ich probiere es mal ohne den Patch. Allerdings ist das Launchpad gerade besonders langsam... (vor 2 Stunden hochgeladen und vermutlich erst in 3 Stunden wird das bauen gestartet)

Als ich an den streamdev Problem gearbeitet habe, hatte ich auch immer ein vanilla-vdr 2.3.8 verwendet.

Bei den MLD Leuten gibt es wohl auch das Problem, welches Frodo hier beschreibt.

Die haben wohl auch eine ganze Reihe vdr-Patche integriert, wenn ich das richtig sehe. Kann schon sein, dass es daran liegt.

Das sich der Server manchmal aufhängt, kann schon an dem "cDevice::Detach() blockiert" Problem liegen, wofür Klaus ein Patch bereit gestellt hat.

Da sich der Server bei mir bis jetzt noch nicht aufgehangen hat und der Patch von Klaus bei mir irgendwie vorbei gegangen ist, habe ich es damit natürlich nie getestet

Ich hatte die Patches schon sehr reduziert, da ich noch diverse Probleme mit segfaults habe.

Aktuell nutze ich nur noch die folgenden Patches:

Den letzten Patch habe ich heute deaktiviert, leider scheint das Launchpad keine Lust zu haben. (Nach 10 Stunden soll ich nun weitere 8 warten) Und das obwohl noch die ganzen Plugins fehlen...

Meine ganzen Tests bis Dezember waren allesamt auch mit einem Vanilla VDR 2.3.8 - ohne irgend welches zusätzliches Gedöns, also nur

mit einem gepatchten streamdev (client und server). Ich habe es mit unterschiedlichsten Kombinationen über Wochen hinweg ausprobiert,

und war zu mindestens 99,9% zufrieden.

Beim Thema MLD sieht es leider nicht mehr ganz so spitze aus.

In der X86-64 Variante treten sporadisch mal Probleme auf - also vllt. so 95% - warum auch immer...

Die RPI Varianten sind derzeit leider nicht testbar, da sich scheinbar, in der MLD-5.4 Testing nach der Version vdr-2.3.8.214.42-214.43, irgend

welche Bugs eingeschlichen haben, die jegliches Testen unmöglich machen. Außerdem ist die aktuelle streamdev client/server Variante im

RPI Zweig vorübergehend nicht mehr gepatcht.

Bleiben also nur die MLD -5.4 Testing Varianten für X86-xx Hardware als Testobjekte.

Sicherheitshalber hab ichs vorhin nochmal mit vanillas probiert, und das geht immer noch einwandfrei.

Werd's auch nochmal in Kreuzkombination probieren: MLD-Server-->Vanilla-Client und Vanilla-Server-->MLD-Client

-Wanninger

Hi Frodo,

Quote from Frodo

Den letzten Patch habe ich heute deaktiviert, leider scheint das Launchpad keine Lust zu haben. (Nach 10 Stunden soll ich nun weitere 8 warten) Und das obwohl noch die ganzen Plugins fehlen...

...zum Thema "Launchpad"

> https://lists.ubuntu.com/archi…/2018-January/000103.html

Gruss

Wolfgang

Also sobald der vdr-2.3.8-fixdevicedetachlock-2 Patch von Klaus am Client eingespielt wird, friert der Client sehr häufig ein.

Egal ob ein gepatchtes streamdev verwendet wird oder die ungepatchte Variante von https://projects.vdr-developer…/vdr-plugin-streamdev.git

Als Plugins hatte ich am Client nur den streamdev client und das softhddevice.

Hi,

ich war heute Vormittag auf der Suche nach dem Selben Problem und konnte ebenfalls den vdr-2.3.8-fixdevicedetachlock-2 Patch von Klaus als Ursache ausmachen.

Claus

Hier noch der Backtrace der 2 Threads die anscheinend den Deadlock verursachen:

Thread 7 (Thread 0x7f45757de700 (LWP 13324)):
#0  0x00007f45c60783bd in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x00007f45c6071163 in pthread_mutex_lock () from /lib64/libpthread.so.0
#2  0x0000000000527059 in cMutex::Lock (this=0x1d518d8) at thread.c:224
#3  0x000000000052778f in cMutexLock::Lock (this=0x7f45757dde10, Mutex=<optimized out>) at thread.c:404
#4  0x000000000049152f in cDevice::Action (this=0x1d4efa0) at device.c:1676
#5  0x0000000000527635 in cThread::StartThread (Thread=0x1d4efa0) at thread.c:293
#6  0x00007f45c606e61b in start_thread () from /lib64/libpthread.so.0
#7  0x00007f45c499e91f in clone () from /lib64/libc.so.6

Thread 1 (Thread 0x7f45c66ee740 (LWP 13151)):
#0  0x00007f45c60783bd in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x00007f45c6071163 in pthread_mutex_lock () from /lib64/libpthread.so.0
#2  0x0000000000527059 in cMutex::Lock (this=0x1d4efc0) at thread.c:224
#3  0x00000000005277f0 in cThread::Lock (this=<optimized out>) at thread.h:94
#4  cThreadLock::Lock (this=0x7ffe9e0eafb0, Thread=<optimized out>) at thread.c:430
#5  0x00007f45b49bd261 in cStreamdevDevice::SetPid (this=0x1d4efa0, Handle=0x1d4f0c8, Type=<optimized out>, On=<optimized out>) at device.c:191
#6  0x000000000048db00 in cDevice::DelPid (this=this@entry=0x1d4efa0, Pid=101, PidType=PidType@entry=cDevice::ptOther) at device.c:622
#7  0x000000000048fde2 in cDevice::Detach (this=<optimized out>, Receiver=Receiver@entry=0x1e364b0) at device.c:1810
#8  0x00000000004ed834 in cReceiver::Detach (this=this@entry=0x1e364b0) at receiver.c:128
#9  0x0000000000534bae in cTransfer::~cTransfer (this=0x1e364b0, __in_chrg=<optimized out>) at transfer.c:22
#10 0x0000000000534dba in cTransfer::~cTransfer (this=0x1e364b0, __in_chrg=<optimized out>) at transfer.c:24
#11 cTransferControl::~cTransferControl (this=0x1cd5d40, __in_chrg=<optimized out>) at transfer.c:72
#12 0x0000000000534df9 in cTransferControl::~cTransferControl (this=0x1cd5d40, __in_chrg=<optimized out>) at transfer.c:73
#13 0x00000000004eafd3 in cControl::Shutdown () at player.c:105
#14 0x0000000000492fa9 in cDevice::SwitchChannel (this=0x1d4c5a0, Channel=0x1cb6bd0, LiveView=LiveView@entry=true) at device.c:787
#15 0x00000000004798bb in cChannels::SwitchTo (this=this@entry=0x7a2aa0 <cChannels::channels>, Number=<optimized out>) at channels.c:1040
#16 0x00000000004c83f8 in cDisplayChannel::ProcessKey (this=0x1e3a490, Key=kDown) at menu.c:4774
#17 0x0000000000472a5f in main (argc=<optimized out>, argv=<optimized out>) at vdr.c:1390