[Wanninger]

Mit der letzten Version von 14:25h treten zwar kaum (2x in einer Stunde) watchdogs auf, dafür geht das Zappen
deutlich schlechter, und auch das OSD bleibt gerne mal auf der Strecke, oder es verschwindet gar nicht mehr, und
ein weiteres zappen kann schon mal 20...30 sekunden dauern.

Ebenso habe ich sehr häufig die Fehler wie bei Dido.

---

[clausmuus]

OK, dann teste Bitte noch mal mit der jetzigen Version.
So wie's ausschaut ist der permashift Patch dafür verantwortlich. Wobei ich eigentlich erwarten würde, das der ohne das permashift Plugin keine Veränderung bewirken sollte...

[Wanninger]

Momentan bekomme ich so gut wie kein OSD mehr zu sehen, und das steht in der messages:

Code: [Select]

Jan  7 15:49:28 (none) user.err vdr: [4957] ERROR (device.c,1902): Bad file descriptor
Jan  7 15:49:30 (none) user.err vdr: [4911] rpihddevice: [libav] Header missing
Jan  7 15:49:30 (none) user.err vdr: [4911] rpihddevice: failed to decode audio frame!
Jan  7 15:49:32 (none) user.err vdr: [4978] ERROR (device.c,1902): Is a directory
Jan  7 15:50:52 (none) user.err vdr: [4980] ERROR (device.c,1902): Bad file descriptor
Jan  7 15:50:54 (none) user.err vdr: [4988] ERROR (device.c,1902): Bad file descriptor
Jan  7 15:51:05 (none) user.err vdr: [4993] ERROR (device.c,1902): Bad file descriptor
Jan  7 15:51:27 (none) user.err vdr: [4890] rpihddevice: [OpenVG] failed to create pixmap! (timed out)
Jan  7 15:51:43 (none) user.err vdr: [4890] rpihddevice: [OpenVG] failed to create pixmap! (timed out)
Jan  7 15:51:53 (none) user.err vdr: [4890] rpihddevice: [OpenVG] failed to create pixmap! (timed out)
Jan  7 15:51:54 (none) user.err vdr: [4995] ERROR (device.c,1902): Bad file descriptor
Jan  7 15:51:58 (none) user.err vdr: [5000] cStreamDevice::GetTSPacket: GetChecked: NOTHING (0)
Jan  7 15:52:26 (none) user.err vdr: [4890] rpihddevice: [OpenVG] failed to create pixmap! (timed out)
Jan  7 15:52:46 (none) user.err vdr: [4890] rpihddevice: [OpenVG] failed to create pixmap! (timed out)
Jan  7 15:52:56 (none) user.err vdr: [4890] rpihddevice: [OpenVG] failed to create pixmap! (timed out)
Jan  7 15:53:01 (none) user.err vdr: [5010] ERROR (device.c,1902): Bad file descriptor
Jan  7 15:53:35 (none) user.err vdr: [4890] rpihddevice: [OpenVG] failed to create pixmap! (timed out)
Jan  7 15:53:45 (none) user.err vdr: [4890] rpihddevice: [OpenVG] failed to create pixmap! (timed out)

---

[clausmuus]

Hm, diese Version sollte mit der Vorletzten identisch sein, und bei der ging ja alles...

[Wanninger]

Stimmt, da hatte ich im rpihddevice die Tonausgabe von Multi auf Stereo geändert, weil der Ton nach dem Umschalten
gerne mal weg war. Jetzt hab ich wieder auf Multi, und es ist wieder so wie vorher.

[clausmuus]

Soll heißen, jetzt geht's?

[Dido]

Also gefühlt läuft die letzte Version am flüssigsten...

Habe 2 RPI3 am Laufen, einer der ab und zu mal zwischen Testing und Unstable gewechselt hat.

Bei diesem bekommen ich nach wir vor ab und zu Bildhänger und die Meldung

Code: [Select]

ERROR: TS packet not accepted in Transfer Mode

Der frisch installierte RPI3 (Testing Image heute heruntergeladen) hat diese Meldungen noch nicht gebracht und Bildhänger habe ich auch noch nicht gesehen.

[Dido]

so, ich habe den "Problem RPI3" gerade mal frisch installiert und bisher auch keine Bildhänger und Meldungen mehr feststellen können.

Ich werde das mal im Auge behalten.

[Wanninger]

--> ...so, nach der kleinen Verwirrung von vorhin, habe ich nochmal von vorne zu testen begonnen, und es schaut jetzt so aus:

1. Sowohl der vdr vom 02.12.2017 ->'43ger und der aktuelle von heute um 15:39h funktionieren gleichermaßen gut.
2. Auch die neue Version lief bei den Tests mit streamdev problemlos

--> Da ich die gepatchte Version des streamdev client/server vom 24.12.2017 noch aufbewahrt hatte, habe ich diese auch noch getestet.

3. Auch die gepatchte streamdev Version läuft mit dem neuesten vdr zusammen ohne Probleme, und tut wofür der Patch gedacht ist.

Würde sagen, dass es passt!

@Wanninger,
genau den Patch habe ich in meinem letzten Build weg gelassen, weil das die letzte verbleibende Änderung war.

Ist dieser Patch "vdr-2.3.8-fixdevicedetachlock-2" in der x86-xx Variante der MLD auch drin?
...und wenn ja, warum verhält er sich da anders? Schon ein wenig seltsam...

---

[clausmuus]

Ja, der ist im x86'er enthalten. Warum der da kein Problem macht, beim RPI aber schon ist mir auch nicht klar.
Ausserdem ist beim x86'er der permashift Patch enthalten, den ich beim RPI auch weg gelassen habe, weil der zu den kurzen Aussetzern geführt hat.
Der streamdev Patch ist beim x86' und RPI enthalten.

[MarMic]

Vllt hat auch keiner streamdev mit x86 getestet? Oder nutzt das hier jemand?

[Wanninger]

Vllt hat auch keiner streamdev mit x86 getestet? Oder nutzt das hier jemand?

...oh doch!

Ich zum Beispiel.

Ich nutze fast ausschliesslich streamdev und xineliboutput/vdr-sxfe auf meinen (Linux) Notebooks als Clients und die Gegenstücke laufen bei mir ausschliesslich im ESXi...

---

[clausmuus]

Ich hab das vorhin auch noch mal in ner VM auf dem x86'er getestet.

[Wanninger]

@Claus

Die X86 hatten auch bei  mir von Anfang an keine Probleme gemacht. Wenn es da Fehler gäbe, würde mir das ganz schnell auffallen.

OT:

Wenn du nochmal Zeit hast, könntest vllt. noch nach dem xineliboutput Plugin schauen. Das wird seit ein paar Tagen nicht mehr gebaut. (Beim RPI3)

---

[Wanninger]

@Claus

Ich glaub ich hab da noch was:

Im x86-64 fehlen die beiden Dateien

Code: [Select]

root@vdr-148:/var/cache/apt/archives$ apt-get download vdr-plugin-streamdev-server
E: Can't find a source to download version '2017.09.30-19.7+2.3.8.214.44' of 'vdr-plugin-streamdev-server:amd64'
root@vdr-148:/var/cache/apt/archives$ apt-get download vdr
E: Can't find a source to download version '2.3.8.214.44-214.48' of 'vdr:amd64'

---