Powered by Invision Power Board


Seiten: (4) « Erste ... 2 3 [4]  ( Zum ersten neuen Beitrag
 
Reply to this topicStart new topicStart Poll

> [G2V_V6] Diashow nach mehreren stunden Betrieb
HelAu
Geschrieben am: Mittwoch, 22.März 2017, 08:57 Uhr
Quote Post


Scheffe
****

Gruppe: Admin
Beiträge: 11012
Mitgliedsnummer.: 2
Mitglied seit: 2003-04-25



Kannst Du mal mysql und das streamdev plugin abschalten und das ganze nochmal beobachten, ?!
Zudem sollest Du das Script das ich gebastelt habe generell laufen lassen und nach nem Reboot die logs schicken, bzw beobachten ob nach geraumer Zeit überhaupt noch neue Pakete erstellt werden. (falls nicht ist alles gut)
Email PosterUsers WebsiteICQAOLYahoo
Top
franky
Geschrieben am: Mittwoch, 22.März 2017, 13:14 Uhr
Quote Post


Prinz
****

Gruppe: Supporter
Beiträge: 1568
Mitgliedsnummer.: 1547
Mitglied seit: 2006-11-19



Hallo,

vergangenes WE hatte ich dieses Verhalten mit der V6 auf einem AM1-System (MSI-AM1 mit A4-5350), das versehntlich nach der Benutzung nicht abgeschaltet wurde.
Da in der V6 die Standardeinstellung für "VDR ausschalten bei Inkativität" auf 0 steht, also deaktiviert ist, hatte das System natürlich auch keinen Auto-Shutdown gemacht.
Laut Log begann das Problem nach ca. 6 Stunden Inaktivität (keine Benutzereingaben!), im Log sichtbar durch die vdr-Meldung "ERROR: TS packet not accepted in Transfer Mode".

Genau diese Meldungen, die auftreten, wenn die GPU vom vdr keine TS-Pakete mehr zum HW-Decoding akzeptiert, finden sich auch in den Logs von bbott immer dann massenhaft, wenn die "Diaschow" läuft.
Und genau diese Meldung hat mich sofort an das Freeze Problem von Ende 2014 zu Beginn von AMD-VDPAU erinnert.

Das Diashow-Problem konnte ich auch auf einem anderen AM1-System (Asrock AM1-H/ A4-5350), das ich jetzt zum testen verwende und auf dem ich die V6 neu installiert habe, reproduzieren.
Das System war während der "Diashow" immer per FB, wenn auch eingeschränkt, bedienbar und nach einem VDR-Restart über das Befehle-Menü lief das System wieder normal.
Im syslog sieht man zwischen den "ERROR: TS packet not accepted in Transfer Mode" an softhddevice-Meldungen, dass die Video-Verarbeitung immer wieder anläuft.
Daher dieses Mal als Ergebnis kein Total-Absturz sondern "Diashow" und damit auch weiterhin eingeschränkte Bedienbarkeit per FB.
Diese Fehlermeldungen zum Transfer Mode deuten daraufhin, dass auch diesmal wieder die Radeon-GPU mit dem HW-Decoding Probleme hat und damit natürlich softhddevice und den vdr beeinflusst.
Vermutlich liegt die Ursache, wie damals 2014, wieder an den Treiber-Komponeten (Radeon-Kernel-Treiber, X11-Treiber, radeonsi/Mesa ...) für die Radeon.

Vor Änderungen an den Treibern hatte ich aber erst mal softhddevice vom vpp-git von pesintta auf das Standard-git von Johns umgestellt und den vdr mit plugins neu gebaut.
Aber auch mit softhddevice aus dem git-Master von Johns ist der Diashow-Effekt nach 5 bis 6h reproduzierbar, was meine Vermutung bestätigt, dass die Ursache doch bei den Radeon-Treibern liegt.

Da der Kernel-Neubau eine etwas langwieriger Angelegenheit ist, habe ich mir erst mal Mesa (radeonsi) und den X11-Treiber vorgenommen.
An Mesa wurde die letzten Monate bezüglich AMD-VDPAU wegen der neuen amdgpu-Treiber für die neuen Volcanic- und Arctic-Island Radeon-Chips intensiv gearbeitet.
Das in der V6 verwendete Mesa 17.0.0 ist das neue Developer-Release (Start 13.02.17 und im Prinzip Alpha-Stadium) von Mesa für OpenGL 4.5 und vermutlich noch nicht besonders stabil.
Da der Radeon-Treiber sowieso nur max. OpenGL 4.1 kann, wäre vermutlich das stabile Mesa 12.0.6 (OpenGL 4.3) ideal, ist aber leider aktuell nicht im Portage enthalten.

Ich habe daher gestern Abend ein Downgrade auf das ausgereiftere und im Portage enthaltene Mesa 13.0.5 (5. Mesa13 BugFix-Release vom 20.Feb 2017 - OpenGL 4.4) gemacht.
Da es einen neueren X11-Treiber x11-drivers/xf86-video-ati für Radeon (amdgpu hat einen eigenen) gibt, habe ich diesen von 7.8.0 auf 7.9.0 upgedatet.

Das Asrock-AM1-System läuft jetzt mit Mesa 13.0.5 und xf86-video-ati 7.9.0 seit gestern Abend 23:00, also jetzt seit über 14h, ohne Probleme.
Meine Vermutung, dass die Ursache wieder mal bei den Radeon-Treibern liegt, scheint sich also zu bestätigen.

Mein Hauptverdächtiger ist der radeonsi-Treiber aus dem Mesa-Paket, der ja auch in erster Linie für das HW-Decoding per AMD-VDPAU zuständig ist.
Daher werde ich als Nächstes mein "Test-System" nochmal neu Aufsetzen und als einzige Änderung zur V6 Standard-Installation ein Downgrade auf Mesa 13.0.5 machen.
Email Poster
Top
bbott
Geschrieben am: Mittwoch, 22.März 2017, 18:11 Uhr
Quote Post


Professional
****

Gruppe: G2V3+User
Beiträge: 922
Mitgliedsnummer.: 10935
Mitglied seit: 2009-07-24



Danke franky für die Infos.
Email Poster
Top
franky
Geschrieben am: Freitag, 24.März 2017, 23:19 Uhr
Quote Post


Prinz
****

Gruppe: Supporter
Beiträge: 1568
Mitgliedsnummer.: 1547
Mitglied seit: 2006-11-19



Hi bbott,

mit der neu aufgesetzten V6, bei der ich nur einen Mesa-Downgrade auf 13.0.5 gemacht habe, läuft mein System nun seit über 30h ohne dieses Diashow-Problem.

Der Übeltäter war also wirklich das noch instabile mesa-17.0.0.

Seit Mittwoch gibt es nun außer der 13.0.5 die am Montag freigegeben Versionen 13.0.6 und 17.0.2 im Gentoo-Portage.
Die sind aber beide aus Gentoo-Sicht im Portage noch als instabil gekennzeichnet.

Ich werde aber trotzdem mal die 13.0.6 testen.

Gruß
franky
Email Poster
Top
franky
Geschrieben am: Sonntag, 26.März 2017, 13:30 Uhr
Quote Post


Prinz
****

Gruppe: Supporter
Beiträge: 1568
Mitgliedsnummer.: 1547
Mitglied seit: 2006-11-19



Hi bbott,

ich habe nun außer der 13.0.6 auch noch die 17.0.2 getestet.

Mit Mesa 13.0.6 lief das System einwandfrei, ohne den Diashow-Effekt (Test nach ca. 20h abgebrochen).

Nach Upgrade auf Mesa 17.0.2 (2. BugFix der 17er Serie) war der Effekt wieder da.
Dabei viel mir auf, dass es von der Scaling-Einstellung in softhddevice abhängt, wie heftig das Problem ausfällt.
Mit Scaling-Einstellung "normal" oder "fast" ist das System, wie ich schon beschrieben hatte, noch eingeschränkt per FB bedienbar (ca. alle 1 bis 2 Sekunden ein Bildrefresh) und per SSH erreichbar.
Mit Scaling-Einstellung "HQ" ist das System nicht mehr bedienbar (kaum noch Bildrefresh) und nicht mehr per SSH erreichbar.

Ich würde Dir raten, die 13.0.5 auslassen und gleich das Downgrade von Mesa 17.0.0 auf 13.0.6 zu machen.
Denn laut Mesa-Homepage ist die 13.0.6 das finale Release der 13er Serie.
Email Poster
Top
bbott
Geschrieben am: Sonntag, 26.März 2017, 15:50 Uhr
Quote Post


Professional
****

Gruppe: G2V3+User
Beiträge: 922
Mitgliedsnummer.: 10935
Mitglied seit: 2009-07-24



Danke franky für die Infos und das testen. Schade das 17.0.2 nicht läuft.
Im Forum habe jetzt schon etliche Threads durchsucht, um die Mesa Version zu wechseln, leider bisher ohne Erfolg.

EDIT: Rechtschreibung
Email Poster
Top
R2D2
Geschrieben am: Sonntag, 26.März 2017, 16:26 Uhr
Quote Post


Prinz
****

Gruppe: Moderators
Beiträge: 5975
Mitgliedsnummer.: 1131
Mitglied seit: 2005-10-30



QUOTE (bbott @ Sonntag, 26.März 2017, 15:50 Uhr)
Danke franky für die Infos und das testen. Schade das 17.0.2 nicht läuft.
Im Forum habe jetzt schon etliche Threads durchsucht, um die Mensa Version zu wechseln, leider bisher ohne Erfolg.

Jetzt mal ehrlich, nach so langer Zeit sollte man schon wissen, wie man eine bestimmte Version eine Software unter Gentoo einspielt!

Ich würde Dir ja gerne helfen, aber leider habe ich ja "von Hardware keine Ahnung".

Ich habe zwar nicht studiert, aber bei Problemen mit der "Mensa" ist das vermutlich das falsche Forum. :D :P
Email PosterUsers WebsiteICQ
Top
franky
Geschrieben am: Sonntag, 26.März 2017, 16:37 Uhr
Quote Post


Prinz
****

Gruppe: Supporter
Beiträge: 1568
Mitgliedsnummer.: 1547
Mitglied seit: 2006-11-19



Hi bbott,

ich hätte eigentlich auch erwartet, dass ich Dir das nicht mehr erklären muss. ;)

Man macht das, wie bei Gentoo üblich, per emerge, also mit:
CODE
emerge -av mesa

Vorher natürlich den Portage syncen.

Das Portage ist jedoch in der V6 so konfiguriert, dass die aktuellste Version installiert wird.
Das wäre momentan die nicht erwünschte 17.0.2.

Kannst Du mit eix mesa einfach überprüfen.
Die fett angezeigte Version würde bei einem emerge verwendet.

Um jetzt die 13.0.6 zu installieren gibt es mehrere Möglichkeiten, Portage zu konfigurieren.
Eine wäre z.B. in der /etc/portage/package.keywords/media den vorhandenen Eintrag mit Angabe der exakten Version entsprechenden zu ändern.
Da derzeit die 17er Versionen eh nicht zu gebrauchen sind, habe ich die 13.0.6 installiert, indem ich die 17er maskiert habe.
Also vor dem emerge ein:
CODE
echo ">=media-libs/mesa-17.0.0" >>/etc/portage/package.mask/media
Email Poster
Top
bbott
Geschrieben am: Sonntag, 26.März 2017, 17:12 Uhr
Quote Post


Professional
****

Gruppe: G2V3+User
Beiträge: 922
Mitgliedsnummer.: 10935
Mitglied seit: 2009-07-24



@franky

Sorry, aber auf
CODE
echo ">=media-libs/mesa-17.0.0" >>/etc/portage/package.mask/media

ein wäre ich nicht gekommen.

Ein "emerge -av mesa" war mir klar. Aller ich habe einfach keine Idee, Hinweis oder Howto gefunden die Version zu beeinflussen.


Ein " eix media-libs/mesa" liefert:
CODE

[?] media-libs/mesa
    Available versions:  13.0.5^d (~)13.0.6^d [m](~)17.0.2^d [m]**9999^d {bindist +classic d3d9 debug +dri3 +egl +gallium +gbm gcrypt gles1 gles2 libressl +llvm +nettle +nptl opencl openmax openssl osmesa pax_kernel pic selinux vaapi valgrind vdpau vulkan wayland xa xvmc ABI_MIPS="n32 n64 o32" ABI_PPC="32 64" ABI_S390="32 64" ABI_X86="32 64 x32" VIDEO_CARDS="freedreno i915 i965 imx intel nouveau r100 r200 r300 r600 radeon radeonsi vc4 vivante vmware"}
    Installed versions:  17.0.0_rc3^d(12:48:07 PM 02/08/2017)(classic dri3 egl gallium gbm gles2 llvm nptl pic vaapi vdpau -bindist -d3d9 -debug -gles1 -opencl -openmax -osmesa -pax_kernel -selinux -valgrind -vulkan -wayland -xa -xvmc ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="64 -32 -x32" VIDEO_CARDS="i915 i965 intel r600 radeon radeonsi -freedreno -ilo -imx -nouveau -r100 -r200 -r300 -vc4 -vivante -vmware")
    Homepage:            https://www.mesa3d.org/
    Description:         OpenGL-like graphic library for Linux


Es scheint noch die 17er Version aktiv zu sein.
Email Poster
Top
R2D2
Geschrieben am: Sonntag, 26.März 2017, 17:27 Uhr
Quote Post


Prinz
****

Gruppe: Moderators
Beiträge: 5975
Mitgliedsnummer.: 1131
Mitglied seit: 2005-10-30



Ist schon lustig, was hier wieder für Klimmzüge gemacht werden....

Es braucht nichts maskiert zu werden, es reicht völlig aus, "mesa" aus den Keywords zu entfernen. ^^
Email PosterUsers WebsiteICQ
Top
bbott
Geschrieben am: Sonntag, 26.März 2017, 17:44 Uhr
Quote Post


Professional
****

Gruppe: G2V3+User
Beiträge: 922
Mitgliedsnummer.: 10935
Mitglied seit: 2009-07-24



QUOTE (R2D2 @ Sonntag, 26.März 2017, 18:27 Uhr)
Ist schon lustig, was hier wieder für Klimmzüge gemacht werden....

Es braucht nichts maskiert zu werden, es reicht völlig aus, "mesa" aus den Keywords zu entfernen. ^^

Danke. Das ist wieder typisch, statt eine Lösung inkl. Code sauber zu dokumentieren, wird eine bessere Lösung angedeutet. Wenn man dann über die Suche nichts findet und nur bla bla liest, dann angemacht wird, freut man sich umso mehr. Danke.
Das ist einer der Gründe warum Linux sich nicht durchsetzen kann und wird.

Es sind wohl alle User mit AMD VDPAU betroffen, damit wäre ein HowTo oder Update hilfreich. Statt dessen werden alte Kamellen heraus geholt, für dessen Wortwahl man sich bereits entschuldigt hat und alle anderen die ebenfalls an einer Lösung Interesse hätten bzw. benötigen erhalten keine Unterstützung. Nochmals Danke.
Email Poster
Top
franky
Geschrieben am: Sonntag, 26.März 2017, 18:40 Uhr
Quote Post


Prinz
****

Gruppe: Supporter
Beiträge: 1568
Mitgliedsnummer.: 1547
Mitglied seit: 2006-11-19



QUOTE (bbott @ Sonntag, 26.März 2017, 18:12 Uhr)
@franky
.....

Ein " eix media-libs/mesa" liefert:
CODE

[?] media-libs/mesa
    Available versions:  13.0.5^d (~)13.0.6^d [m](~)17.0.2^d [m]**9999^d {bindist +classic d3d9 debug +dri3 +egl +gallium +gbm gcrypt gles1 gles2 libressl +llvm +nettle +nptl opencl openmax openssl osmesa pax_kernel pic selinux vaapi valgrind vdpau vulkan wayland xa xvmc ABI_MIPS="n32 n64 o32" ABI_PPC="32 64" ABI_S390="32 64" ABI_X86="32 64 x32" VIDEO_CARDS="freedreno i915 i965 imx intel nouveau r100 r200 r300 r600 radeon radeonsi vc4 vivante vmware"}
    Installed versions:  17.0.0_rc3^d(12:48:07 PM 02/08/2017)(classic dri3 egl gallium gbm gles2 llvm nptl pic vaapi vdpau -bindist -d3d9 -debug -gles1 -opencl -openmax -osmesa -pax_kernel -selinux -valgrind -vulkan -wayland -xa -xvmc ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="64 -32 -x32" VIDEO_CARDS="i915 i965 intel r600 radeon radeonsi -freedreno -ilo -imx -nouveau -r100 -r200 -r300 -vc4 -vivante -vmware")
    Homepage:            https://www.mesa3d.org/
    Description:         OpenGL-like graphic library for Linux


Es scheint noch die 17er Version aktiv zu sein.

Hi bbott,

da hattest Du aber sicher noch kein "emerge -av mesa" ausgeführt, sondern nur den Befehl zum maskieren der 17er Versionen.
Denn die "Installed Version" ist ja noch 17.0.0_rc3 vom 08.02.17 und die 17.0.2 ist makiert [m].

Emerge musst Du natürlich auf jeden Fall noch ausführen, damit mesa neu gebaut wird.
Also erst maskieren und dann noch das emerge.

Der Vorschlag von R2D2 würde dann aber nicht 13.0.6 installieren, da nach dem Entfernen von mesa aus den keywords die aktuellste stabile Version installiert wird.
Wie man an deiner eix-Ausgabe sieht ist die aktuellste stabil gekennzeichnete Version, also ohne (~) davor, die 13.0.5.
Die 13.0.5 wäre auch OK, ist aber halt nicht die aktuellste 13er, die dein Problem behebt.

Mit meinem Vorschalg vor dem emerge die 17er zu maskieren, wird weiterhin die aktuellste Version installiert, aber ohne dabei die maskierten 17er zu berücksichtigen.
Somit wird die 13.0.6 installiert.
Email Poster
Top
bbott
Geschrieben am: Sonntag, 26.März 2017, 19:49 Uhr
Quote Post


Professional
****

Gruppe: G2V3+User
Beiträge: 922
Mitgliedsnummer.: 10935
Mitglied seit: 2009-07-24



Das emerge -av mesa hatte beim erstmal Fehler ausgespuckt, beim zweiten Anlauf lief es und 13.0.6 ist nun aktiv. Danke franky.
Email Poster
Top
bbott
Geschrieben am: Mittwoch, 29.März 2017, 19:14 Uhr
Quote Post


Professional
****

Gruppe: G2V3+User
Beiträge: 922
Mitgliedsnummer.: 10935
Mitglied seit: 2009-07-24



Leider ist das Problem nun teils schlimmer, das Bild wird schwarz.

FOlgende Konsolen ausgabe erhalte ich:
CODE
Mi 29. Mär 19:27:04 CEST 2017
gen2vdr ~ # /_config/bin/g2v_log.sh
Collecting information ...
xcb_connection_has_error() returned true
xcb_connection_has_error() returned true
xcb_connection_has_error() returned true
xcb_connection_has_error() returned true
xcb_connection_has_error() returned true
xcb_connection_has_error() returned true
xcb_connection_has_error() returned true
xcb_connection_has_error() returned true
<13>Mar 29 20:12:49 root: Starte svdrpsend MESG /tmp/g2v_log_03292010.tar.xz wur                                                                           de erstellt
+ '[' 3 -lt 2 ']'
+ DEST=de.tvdr.vdr
+ OBJECT=/Skin
+ shift
+ INTERFACE=skin.QueueMessage
+ shift
++ dbus-send --system --type=method_call --dest=de.tvdr.vdr --print-reply /Skin                                                                            de.tvdr.vdr.skin.QueueMessage 'string:/tmp/g2v_log_03292010.tar.xz wurde erstell                                                                           t'
+ rc='method return time=1490811169.158426 sender=:1.7 -> destination=:1.16 seri                                                                           al=47 reply_serial=2
  int32 250
  string "Message queued"'
+ logger 'dbus-send --system --type=method_call --dest=de.tvdr.vdr --print-reply                                                                            /Skin de.tvdr.vdr.skin.QueueMessage "string:/tmp/g2v_log_03292010.tar.xz wurde                                                                            erstellt" - method return time=1490811169.158426 sender=:1.7 -> destination=:1.1                                                                           6 serial=47 reply_serial=2
  int32 250
  string "Message queued"'
<13>Mar 29 20:12:49 G2V_4635_23598: /_config/bin/g2v_log.sh /tmp/g2v_log_0329201                                                                           0.tar.xz wurde erstellt


angehängte Datei ( Anzahl der Downloads: 47 )
angehängte Datei  g2v_log_03292010.tar.xz
Email Poster
Top
bbott
Geschrieben am: Mittwoch, 29.März 2017, 19:21 Uhr
Quote Post


Professional
****

Gruppe: G2V3+User
Beiträge: 922
Mitgliedsnummer.: 10935
Mitglied seit: 2009-07-24



Eine lsof_ Datei, nach dem Crash erstellt.

angehängte Datei ( Anzahl der Downloads: 42 )
angehängte Datei  lsof_1703292017.0.rar
Email Poster
Top
franky
Geschrieben am: Mittwoch, 29.März 2017, 21:09 Uhr
Quote Post


Prinz
****

Gruppe: Supporter
Beiträge: 1568
Mitgliedsnummer.: 1547
Mitglied seit: 2006-11-19



Hi bbott,

mein System läuft nun mit mesa 13.0.6 seit mehr als 3 Tagen rund um die Uhr ohne den Fehler.
Ich kann den Fehler bei meinem AM1-System nicht mehr reproduzieren!

Was mir an deinem syslog auffällt sind die vielen Fehlermeldungen von vdradmind.
Den habe ich überhaupt nicht aktiviert, da ich stattdessen das live-Plugin verwende.

An meinem System habe ich nach der Neuinstallation der V6 sonst nur noch folgende Anpassungen vorgenommen, die aus meinenen AMD-Erfahrungen sinnvoll sind.

1. Ich habe bei AMD-Systemen generell den skindesigner deaktiviert, da dieser mit AMD-VDPAU ohne opengl-OSD-Beschleunigung sowieso nicht besonders flüssig läuft und nur Probleme macht.
Bei dir ist er aktiv.
Als Skin verwende ich stattdessen das gute "alte" nOpacity plus den "alten" tvguide.

2. Da bei AMD auch immer wieder mal das HQ-Scaling in Softhddevice Probleme gemacht hatte, habe ich das für alle Auflösungen auf "normal" gesetzt (bei Dir HQ).
Wie ich mittlerweile festgestellt habe, bekommt softhddevice mit dem HQ-Scaling besonders nach einem Update auf ffmpeg 3.2.x ( z.B. durch kodi Neubau) große Probleme.

Ansonsten kann ich Dir nicht wirklich weiterhelfen, wenn ich den Fehler bei mir nicht reproduzieren kann.
Email Poster
Top
bbott
Geschrieben am: Donnerstag, 30.März 2017, 19:30 Uhr
Quote Post


Professional
****

Gruppe: G2V3+User
Beiträge: 922
Mitgliedsnummer.: 10935
Mitglied seit: 2009-07-24



@franky

Danke, ich habe jetzt nOpacity aktiviert. sowie skindesigner deaktiviert. Sowie das TVguide plugin.

Das HQ werde ich beim nächsten mal herunterstellen.
Email Poster
Top
franky
Geschrieben am: Donnerstag, 30.März 2017, 23:22 Uhr
Quote Post


Prinz
****

Gruppe: Supporter
Beiträge: 1568
Mitgliedsnummer.: 1547
Mitglied seit: 2006-11-19



Hi bbott,

ich habe bei meinem Test-Sytem das HQ-Scaling mal wieder aktiviert und danach alle 4 bis 5 Stunden einen VDR-Restart.
Ist zwar ein etwas anders Verhalten als bei Dir (kein Total-Crash), das aber nicht gleich auffällt, wenn man nicht dauernd vor der Kiste sitzt.
Das HQ-Scaling ist also definitv weiterhin sehr kritisch für softhddevice mit AMD-VDPAU.
Man sieht das auch im syslog (auch deinem) an den häufigen " video/vdpau: missed frame" und "video: speed up video, droping frame" Meldungen.

Bei Dir sind diese Meldungen nur aufgrund vieler anderer Meldungen nicht so schnell zu finden.
Dominierend in deinem syslog sind auch die vielen vdradmind-Meldungen des VDR-WebIF VDRAdmin (nicht verwechseln mit dem admin-Plugin!).
Das könnte evtl. auch den VDR stark belasten und bei Dir zu dem anderen Verhalten führen.
Da Du ja auch das live-Plugin aktiviert hast, das ein vergleichbares WebIF für den VDR zur Verfügung stellt, würde ich vorschlagen, die Option "VDRADMIN automatisch starten" in g2v_setup.sh unter "Netzwerk" wieder auf "nein" zu setzten.

Und natürlich auch dringend in den Einstellungen von softhddevice für alle Auflösungen das Scaling auf "normal" stellen!
Email Poster
Top
franky
Geschrieben am: Freitag, 31.März 2017, 21:39 Uhr
Quote Post


Prinz
****

Gruppe: Supporter
Beiträge: 1568
Mitgliedsnummer.: 1547
Mitglied seit: 2006-11-19



Hi bbott,

nachdem ich noch VDRAdmin aktiviert hatte, konnte ich den VDR nach relativ kurzer Laufzeiteit (ca. 1h) weder per VDRAdmin noch per SSH (WinSCP) erreichen aber weiterhin per Live-Plugin auf Port 8008.
Das Netzwerk funktioniert also noch aber der SSH-Login nicht mehr, was vermutlich an VDRAdmin liegt.
Im syslog sieht man dann auch massenhaft die vdradmind-Fehlermeldungen.

Mit aktiviertem HQ-Scaling und aktiviertem VDRAdmin hatte ich jetzt auch den Effekt, dass der TV nach längerer Laufzeit nur schwarzes Bild bringt.

Da scheinen sich also doch mehrere Effekte bei deinem "Diashow"-Problem überlagert zu haben.

Hauptverursacher für die "Diaschow" ist für mich weiterhin das instabile Mesa 17 das sich negativ auf softhddevice auswirkt und an 2. Stelle das HQ-Scaling, das softhddevice bei AMD-VDPAU zusätzlich instabil macht.
Und dann der skindesigner, der bei AMD-VDPAU mangels OpenGL-OSD softhddevice zusätzlich belastet.

Der VDRAdmin scheint dann dabei auftretende NW-Instabilitäten zu verstärken, was man ggf. noch seperat mit deaktiviertem HQ-Scaling testen müsste.

Also bei AMD-Grafik zusätzlich zum Mesa-Downgrade auf jeden Fall das HQ-Scaling in softhddevice deaktivieren und auf skindesigner verzichten.
Email Poster
Top
bbott
Geschrieben am: Freitag, 11.August 2017, 15:28 Uhr
Quote Post


Professional
****

Gruppe: G2V3+User
Beiträge: 922
Mitgliedsnummer.: 10935
Mitglied seit: 2009-07-24



Also ich habe VDRAdmin aktualisiert seit Monate ohne Probleme aktiv.


Gibt es was neues von der Mesa 17 Front und den AMD Grafik Treibern? Ist inzwischen das Problem gefixed?
Email Poster
Top
Thema wird von 0 Benutzer(n) gelesen (0 Gäste und 0 Anonyme Benutzer)
0 Mitglieder:

Topic OptionsSeiten: (4) « Erste ... 2 3 [4]  Reply to this topicStart new topicStart Poll