Druckbare Version des Themas
Hier klicken um das Thema im Original Format zu betrachten.
HTPC Forum > Installation/Konfiguration > [G2V_V6] Diashow nach mehreren stunden Betrieb


Geschrieben von: bbott am Samstag, 25.Februar 2017, 10:43 Uhr
Hallo,

ich habe bei meinem VDR1 nun bemerkt, dass nach mehreren Stunden Betrieb, das Bild nur noch als Diashow läuft. Ein Kanalwechsel (HD->HD, HD->SD) hilf nicht, auch das Menü regiert sehr träge.
Per SSH kann ich mich auch nicht mehr einloggen, nach der Kennwort Eingabe passiert aber nichts mehr.

Netzwerkfreigabe und Aufnahmen sind nicht beeinträchtigt.

Ein Reboot behebt das Problem.


EDIT:
Es scheint nicht mehr herunter zufahren zu können.

Geschrieben von: MegaV0lt am Samstag, 25.Februar 2017, 16:19 Uhr
Vielleicht hat es was mit NFS4 zu tun: http://j.mp/2laJw6U

Geschrieben von: R2D2 am Samstag, 25.Februar 2017, 17:19 Uhr
Nun ja das Problem mit "VFS: file-max limit xxxx reached" ist wohl schon uralt.

Du könntest mal versuche, das Limit neu zu setzten.

Laut Faustformel rechnet man pro 4MB RAM, 256.

Da Du ja 8GB, laut Log, verbaut hast, ergibt sich folgender Wert:

8 x 1024 = 8192
8129/4 x 256 = 524288

Setzten kannst Du den Wert so:

CODE
echo "fs.file-max = 524288" >>  /etc/sysctl.conf


Dann die neuen Parameter laden:

CODE
sysctl -p



Geschrieben von: bbott am Samstag, 25.Februar 2017, 22:15 Uhr
Danke. Das Bild läuft bisher nun stabil.

Leider ist SSH und VDRadmin Problem nun nach einem längeren Uptime nicht mehr erreichbar.

Geschrieben von: R2D2 am Samstag, 25.Februar 2017, 22:27 Uhr
Das war aber schon vorher so:

CODE
.....
Feb 25 10:26:57 g2v vdradmind[4470]: Connection to localhost:6419 failed: IO::Socket::INET: Bad hostname 'localhost'
Feb 25 10:26:57 g2v vdradmind[4470]: Connection to localhost:6419 failed: IO::Socket::INET: Bad hostname 'localhost'
Feb 25 10:26:57 g2v vdradmind[4470]: Connection to localhost:6419 failed: IO::Socket::INET: Bad hostname 'localhost'
Feb 25 10:26:57 g2v vdradmind[4470]: Connection to localhost:6419 failed: IO::Socket::INET: Bad hostname 'localhost'
Feb 25 10:26:57 g2v vdradmind[4470]: Connection to localhost:6419 failed: IO::Socket::INET: Bad hostname 'localhost'
Feb 25 10:26:57 g2v vdradmind[4470]: Connection to localhost:6419 failed: IO::Socket::INET: Bad hostname 'localhost'
Feb 25 10:26:57 g2v vdradmind[4470]: Connection to localhost:6419 failed: IO::Socket::INET: Bad hostname 'localhost'
Feb 25 10:26:57 g2v vdradmind[4470]: Connection to localhost:6419 failed: IO::Socket::INET: Bad hostname 'localhost'
.....


Ich würde da mal auf einen Fehlerhaften Nameserver Eintrag in der "/etc/resolv.conf" tippen.

Geschrieben von: bbott am Sonntag, 26.Februar 2017, 10:30 Uhr
Also gestern spät Abends wurde das Bild wieder zur Diashow. Selbst auf dem VDR selbst konnte ich mich nicht mehr einloggen!!!

Die /etc/resolv.conf:
CODE

# Generated by dhcpcd from eth0.dhcp
# /etc/resolv.conf.head can replace this line
nameserver 192.168.1.1
# /etc/resolv.conf.tail can replace this line


Steht nichts falsches oder zuviel, höchstens das etwas fehlt?

Ich habe darauf hin noch einmal:
CODE

emerge --sync
eix-update

emerge -av dev-perl/CGI

Heute morgen lief er noch ohne Fehler.

Geschrieben von: HelAu am Sonntag, 26.Februar 2017, 14:36 Uhr
Warum ist in deinem Logpaket die sys.log leer ?
Wie sieht deine /etc/hosts aus ?

Geschrieben von: bbott am Sonntag, 26.Februar 2017, 15:00 Uhr
Meine /etc/hosts sieht wie folgt aus:
CODE

# /etc/hosts: Local Host Database
#
# This file describes a number of aliases-to-address mappings for the for
# local hosts that share this file.
#
# In the presence of the domain name service or NIS, this file may not be
# consulted at all; see /etc/host.conf for the resolution order.
#

# IPv4 and IPv6 localhost aliases
::1  localhost

#
# Imaginary network.
#10.0.0.2               myname
#10.0.0.3               myfriend
#
# According to RFC 1918, you can use the following IP networks for private
# nets which will never be connected to the Internet:
#
#       10.0.0.0        -   10.255.255.255
#       172.16.0.0      -   172.31.255.255
#       192.168.0.0     -   192.168.255.255
#
# In case you want to be able to connect directly to the Internet (i.e. not
# behind a NAT, ADSL router, etc...), you need real official assigned
# numbers.  Do not try to invent your own network numbers but instead get one
# from your network provider (if any) or from your regional registry (ARIN,
# APNIC, LACNIC, RIPE NCC, or AfriNIC.)
#
127.0.0.1   localhost
127.0.0.1   g2v

Geschrieben von: R2D2 am Sonntag, 26.Februar 2017, 15:07 Uhr
Sofern Du kein ipv6 verwendest, würde ich die Zeile "::1 localhost" löschen, oder auskommentieren.

Geschrieben von: bbott am Sonntag, 26.Februar 2017, 17:56 Uhr
QUOTE (HelAu @ Sonntag, 26.Februar 2017, 15:36 Uhr)
Warum ist in deinem Logpaket die sys.log leer ?

Gute Frage ich habe keine Ahnung warum.

Geschrieben von: bbott am Sonntag, 26.Februar 2017, 22:48 Uhr
Leider ist das Problem ist immer noch aufgetreten.

Geschrieben von: HelAu am Montag, 27.Februar 2017, 08:35 Uhr
Wie gesagt deine syslog ist leer, irgendwas an deiner Installation stimmt nicht poste die mal die komplette Ausgabe von:
CODE
bash -x /_config/bin/g2v_log.sh
ls -al /log/

Geschrieben von: HelAu am Montag, 27.Februar 2017, 08:41 Uhr
Und solange das vdradmin Problem nicht behoben ist, solltest Du diesen auf keinen Fall starten, denn ich denke der zieht Dein system runter.
P.S. Und wenn das file handle problem auftritt, dann bräuchte man die Ausgabe von lsof, diese dürfte aber umfangreich sein wink.gif

Geschrieben von: MegaV0lt am Montag, 27.Februar 2017, 12:55 Uhr
Im ersten Logpaket in der rc.log ist beim Ruterfahren zu sehen, dass es einen Segfault gibt und sogar der SWAP voll ist... Irgendwas läuft da unrund. Vielleicht ein Plugin, das Quer schießt?

Die Probleme mit vdradmin sind vermutlich nur Folgefehler wegen Speichermangel und oder vollem Swap

PS:
Kannst ja mal versuchen den VDR mit absolut minimaler Pluginausstattung zu starten. Bzw. mal alles neu bauen...

Geschrieben von: bbott am Montag, 27.Februar 2017, 19:02 Uhr
Ich habe signalInfo deaktiviert, da ich fürher schon mal mit dem Plugin zu Problemen führte.

CODE

login as: root
Using keyboard-interactive authentication.
Password:
This is BASH 4.3.48(1)-release
         ____            ______     ______  ____
        / ___| ___ _ __ |___ \ \   / /  _ \|  _ \
       | |  _ / _ \ '_ \  __) \ \ / /| | | | |_) |
       | |_| |  __/ | | |/ __/ \ V / | |_| |  _ <
        \____|\___|_| |_|_____| \_/  |____/|_| \_\     V6.0 Update 5


Mo 27. Feb 18:56:59 CET 2017
g2v ~ # bash -x /_config/bin/g2v_log.sh
+ source /_config/bin/g2v_funcs.sh
++ trap g2v_exit EXIT
++ '[' '' == '' ']'
++ source /etc/vdr.d/conf/vdr
+++ NET=Ja
+++ DHCP=1
+++ HOSTNAME=g2v
+++ IPADR=192.168.1.111
+++ GATEWAY=192.168.1.111
+++ NAMESERVER=192.168.1.1
+++ SUBNET=255.255.255.0
+++ WORKGROUP=VDR
+++ DOMAIN=
+++ PROXY_HOST=
+++ PROXY_PORT=8080
+++ SAMBA=1
+++ SSH=1
+++ NFS=0
+++ NFS_RO=1
+++ FRITZWATCH=0
+++ VDRADMIN=1
+++ NTP=0
+++ FTP=1
+++ WAKEONLAN=1
+++ LOG_LEVEL=3
+++ REMOTE=AtricUSB
+++ LIRCCFG=Harmony_kls_vdr
+++ LCD=None
+++ WARN_DISK_FREE=1000
+++ MIN_DISK_FREE=20
+++ KBD_LAYOUT=Deutsch
+++ DISC_SLOWDOWN=cdspeed
+++ DISC_SPEED=6
+++ AUTOMOUNT=1
+++ MOUNTNAMEDEV=0
+++ DISC_AUTORUN=0
+++ DIRECTISA=1
+++ FSCK_WEEK=0
+++ BOOT_SPLASH=0
+++ SHUTDOWN_METHOD=Shutdown
+++ WAKEUP_RESERVE=300
+++ WAKEUP_METHOD=ACPI
+++ NVRAM_BOARD=
+++ IGNORE_CONNECTION=1
+++ PB_FUNCTION=HALT
+++ WAKEUP_HOUR=5
+++ WAKEUP_DURATION=0
+++ EPGSCAN=Aus
+++ STR_WU_LIMIT=5
+++ STR_MAN_LIMIT=1
+++ CMDSUBMENU=1
+++ WATCHDOG=30
+++ WATCHDOG_REBOOT=0
+++ VDR_NICE=0
+++ DVB_CARD_NUM=8
+++ UNICABLE=Ja
+++ SET_MARKS='Nach Aufnahme'
+++ MAINTAIN_NOAD=0
+++ SHAREMARKS=0
+++ USE_CUTTING_DIR=0
+++ MAINTAIN_CUTTING=1
+++ SCREEN_RESOLUTION=1080p
+++ GUI_FONTSIZE=22
+++ VO_DRIVER=vdpau
+++ AO_DRIVER=alsa
+++ VO_ASPECT=anamorphic
+++ VO_CROP=0
+++ OVERSCAN_TOP=0
+++ OVERSCAN_BOTTOM=0
+++ OVERSCAN_LEFT=0
+++ OVERSCAN_RIGHT=0
+++ PLUGINS=' osdteletext skinenigmang epgsearch extrecmenu music live epgtablei                                                                           d0 dbus2vdr weatherforecast admin streamdev-server tvm2vdr burn skindesigner tvg                                                                           uideng skinnopacity softhddevice '
++ '[' '' == '' ']'
++ source /etc/vdr.d/conf/gen2vdr.cfg
+++ VDR_CONFIG_DIR=/etc/vdr
+++ VDR_PLGCONFIG_DIR=/etc/vdr/plugins
+++ VIDEO=/video
+++ VDR_SOURCE_DIR=/usr/local/src/VDR
+++ VDR_EXEC=/usr/local/bin/vdr
+++ VDR_LIB_DIR=/usr/local/lib/vdr
+++ EPG_FILE=/var/vdr/epg.data
+++ EPG_IMAGES=/var/vdr/epgimages
+++ VDR_SHUTDOWN_SCR=/_config/bin/vdrshutdown
+++ VDR_FORCE_SHUTDOWN=/tmp/.force-shutdown
+++ RUNVDR_PATH=/tmp/vdr
+++ RUNVDR_RUN=/tmp/vdr/vdr_run
+++ RUNVDR_INIT=/tmp/vdr/vdr_init
+++ RUNVDR_EXIT=/tmp/vdr/vdr_exit
+++ RUNVDR_RESTART=/tmp/vdr/vdr_restart
+++ RUNVDR_RECORD=/tmp/vdr/vdr_record
+++ STOPVDR_FILE=/tmp/.stopvdr
+++ ADMIN_SCRIPT_PATH=/etc/vdr/plugins/admin
+++ ADMIN_CFG_FILE=/etc/vdr/plugins/admin/admin.conf
+++ ADMIN_EXEC_SCRIPT=/etc/vdr/plugins/admin/.admexec
+++ ADMIN_LOG_FILE=/log/vdradmplg.log
+++ GETVAL=/etc/vdr/plugins/admin/getadmval.sh
+++ SETVAL=/etc/vdr/plugins/admin/setadmval.sh
+++ VDR_CONSOLE=8
+++ VDR_USER=root
+++ VDR_START_FILE=/tmp/.vdrlaststart
+++ WAKEUP_FILE=/_config/status/Wakeup
+++ MANSTART_FILE=/_config/status/ManualStart
+++ G2V_DISPLAY=:0
+++ DISPLAY=:0
+++ export DISPLAY
+++ GG_ACTAPP_FILE=/_config/status/gg_actapp
++ glogger 'Script starts <>'
+++ readlink /proc/6427/fd/255
++ SELF=/_config/bin/g2v_log.sh
++ '[' 3 '!=' 0 ']'
++ '[' 'Script starts <>' == -s ']'
++ '[' 'Script starts <>' == -o ']'
++ PARM=
++ logger -t G2V_6427_6401 /_config/bin/g2v_log.sh 'Script starts <>'
+ echo 'Collecting information ...'
Collecting information ...
+ '[' '' = -v ']'
+ '[' '' = -v ']'
+ VERBOSE=0
+ OUTPUT=
++ find /log/ /tmp/ -mtime +5 -type f
++ grep -v g2v_log_install
+ rm -f
++ date +%m%d%H%M
+ DT=02271857
+ LOG_ARCH=/tmp/g2v_log_02271857.tar.xz
++ date +%s
+ LOG_DIR=/tmp/g2v_log_1488218220
+ rm -rf /tmp/g2v_log_1488218220
+ mkdir -p /tmp/g2v_log_1488218220
+ cd /tmp/g2v_log_1488218220
+ dmesg -T
+ biosinfo
+ lsmod
+ lshw
+ lsusb -v
+ lspci -vn
+ ps -ef
+ biosinfo
+ /_config/bin/query_mb.sh
+ uname -a
+ /_config/bin/detect_modules.sh
+ ls -l /tmp/
+ ls -l /usr/local/src/
+ cat /proc/meminfo
+ cat /proc/cpuinfo
+ top -b -d 1 -n 5
+ ifconfig
+ ping -c 2 -w 5 www.htpc-forum.de
+ echo ''
+ echo resolv.conf:
+ cat /etc/resolv.conf
+ cat /proc/bus/input/devices
+ hwinfo
+ mount
+ df
+ cat /log/messages
+ FILES='/log/kodi.log.old /log/rc.log /log/dmsg /install.log /_config/update/update.log /etc/gen2vdr/applications  /etc/gen2vdr/remote  /etc/vdr.d/conf/vdr /etc/vdr/setup.conf /etc/vdr/channels.conf /etc/X11/xorg.conf /etc/vdr/plugins/admin/admin.conf /root/.kodi/temp/*log*  /log/vdr-xine.log /log/Xorg.0.log /root/.xine/config /root/.xine/config_xineliboutput /etc/asound.conf /etc/asound.state  /tmp/vdr/vdr_* /etc/X11/xorg.conf.d/*'
+ '[' 0 = 1 ']'
+ cp -af /log/kodi.log.old /log/rc.log /log/dmsg /install.log /_config/update/update.log /etc/gen2vdr/applications /etc/gen2vdr/remote /etc/vdr.d/conf/vdr /etc/vdr/setup.conf /etc/vdr/channels.conf /etc/X11/xorg.conf /etc/vdr/plugins/admin/admin.conf /root/.kodi/temp/kodi.log /log/vdr-xine.log /log/Xorg.0.log /root/.xine/config /root/.xine/config_xineliboutput /etc/asound.conf /etc/asound.state /tmp/vdr/vdr_exit /tmp/vdr/vdr_init /tmp/vdr/vdr_record /tmp/vdr/vdr_restart /tmp/vdr/vdr_run /etc/X11/xorg.conf.d/10-evdev.conf /etc/X11/xorg.conf.d/10-quirks.conf /etc/X11/xorg.conf.d/20opengl.conf .
+ /_config/bin/get_core.sh
+ aplay -lL
+ for i in '/proc/asound/card[0-9]'
+ cnum=0
+ echo 'SoundCard 0 :'
+ amixer contents -c 0
+ amixer scontents -c 0
+ alsactl store 0
+ echo ''
+ for i in '/proc/asound/card[0-9]'
+ cnum=1
+ echo 'SoundCard 1 :'
+ amixer contents -c 1
+ amixer scontents -c 1
+ alsactl store 1
+ echo ''
+ tar -cJf /tmp/g2v_log_02271857.tar.xz .
+ svdrps MESG '/tmp/g2v_log_02271857.tar.xz wurde erstellt'
+ glogger 'svdrpsend MESG /tmp/g2v_log_02271857.tar.xz wurde erstellt'
++ readlink /proc/6427/fd/255
+ SELF=/_config/bin/g2v_log.sh
+ '[' 3 '!=' 0 ']'
+ '[' 'svdrpsend MESG /tmp/g2v_log_02271857.tar.xz wurde erstellt' == -s ']'
+ '[' 'svdrpsend MESG /tmp/g2v_log_02271857.tar.xz wurde erstellt' == -o ']'
+ PARM=
+ logger -t G2V_6427_6401 /_config/bin/g2v_log.sh 'svdrpsend MESG /tmp/g2v_log_02271857.tar.xz wurde erstellt'
+ /usr/bin/svdrpsend.sh MESG '/tmp/g2v_log_02271857.tar.xz wurde erstellt'
<13>Feb 27 18:58:29 root: Starte svdrpsend MESG /tmp/g2v_log_02271857.tar.xz wurde 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_02271857.tar.xz wurde erstellt'
+ rc='method return time=1488218309.100101 sender=:1.0 -> destination=:1.5 serial=10 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_02271857.tar.xz wurde erstellt" - method return time=1488218309.100101 sender=:1.0 -> destination=:1.5 serial=10 reply_serial=2
  int32 250
  string "Message queued"'
+ glogger -s '/tmp/g2v_log_02271857.tar.xz wurde erstellt'
++ readlink /proc/6427/fd/255
+ SELF=/_config/bin/g2v_log.sh
+ '[' 3 '!=' 0 ']'
+ '[' -s == -s ']'
+ PARM=-s
+ shift
+ logger -s -t G2V_6427_6401 /_config/bin/g2v_log.sh '/tmp/g2v_log_02271857.tar.xz wurde erstellt'
<13>Feb 27 18:58:29 G2V_6427_6401: /_config/bin/g2v_log.sh /tmp/g2v_log_02271857.tar.xz wurde erstellt
+ cd ..
+ rm -rf /tmp/g2v_log_1488218220
+ '[' '' = -m ']'
+ '[' '' '!=' '' ']'
+ g2v_exit
+ glogger 'Script ends'
++ readlink /proc/6427/fd/255
+ SELF=/_config/bin/g2v_log.sh
+ '[' 3 '!=' 0 ']'
+ '[' 'Script ends' == -s ']'
+ '[' 'Script ends' == -o ']'
+ PARM=
+ logger -t G2V_6427_6401 /_config/bin/g2v_log.sh 'Script ends'
g2v ~ # ls -al /log/
total 906312
drwxr-xr-x 22 root     root          4096 Feb 27 18:47 .
drwxr-xr-x 13 root     users         4096 Feb 19 14:56 ..
drwxr-xr-x  2 root     root          4096 Feb 19 15:11 ConsoleKit
-rw-r--r--  1 root     root         41955 Feb 27 18:47 Xorg.0.log
-rw-r--r--  1 root     root         41955 Feb 27 12:12 Xorg.0.log.old
drwxrwxrwx  2 root     root          4096 Nov 14 16:15 chrony
drwxrwxrwx  2 root     root          4096 Mar 10  2015 critical
drwxrwxrwx  2 root     root          4096 May 11  2015 cron
-rw-r-----  1 root     root         26274 Feb 27 18:46 dmesg
drwxrwxrwx  2 root     root          4096 Feb 27 12:11 dmsg
-rw-rw----  1 portage  portage       1759 Feb 26 02:12 emerge.log
-rw-r--r--  1 root     root          7059 Feb 27 18:47 epgsearch.log
-rw-r--r--  1 root     root         77579 Feb 26 04:00 epgsearch.log-20170226
-rw-r--r--  1 root     root             0 Feb 27 12:10 g2v_cleanup.log
-rw-r--r--  1 root     root        316828 Feb 27 12:07 g2v_log_02271206.tar.xz
-rw-r--r--  1 root     root        176548 Feb 27 12:10 g2v_log_02271210.tar.xz
-rw-r--r--  1 root     root        153560 Feb 19 15:02 g2v_log_install.tar.xz
drwxrwxrwx  2 root     root          4096 May 11  2015 kernel
-rw-r--r--  1 root     root           292 Feb 27 18:56 lastlog
drwxrwxrwx  2 root     root          4096 May 11  2015 mail
-rw-------  1 root     root     905237642 Feb 27 18:58 messages
-rw-------  1 root     root       4270402 Feb 26 04:00 messages-20170226.gz
-rw-------  1 root     root        291369 Feb 27 12:10 messages-20170227.gz
drwxrwxrwx  2 minidlna minidlna      4096 Aug 12  2014 minidlna
drwxr-xr-x  2 mysql    mysql         4096 Feb 19 15:01 mysql
-rw-r--r--  1 root     root         22301 Feb 26 11:13 noadstat
drwxrwxrwx  2 root     root          4096 Feb 19 14:56 oscam
drwxrwxrwx  2 plex     plex          4096 Jan 10  2015 pms
drwxrwsrwx  3 portage  portage       4096 Feb 26 02:11 portage
drwxrwxrwx  2 root     root          4096 Apr  4  2015 pwdfail
-rw-r--r--  1 root     root        477733 Feb 27 18:47 rc.log
-rw-r--r--  1 root     root         65955 Feb 26 03:57 rc.log-20170226.gz
drwxrwxrwx  3 root     root          4096 Feb 26 10:19 samba
drwxrwxrwx  2 root     root          4096 Feb  6 07:57 sandbox
drwxrwxrwx  2 root     root          4096 May 11  2015 sshd
-rw-------  1 root     root            64 Feb 27 18:56 tallylog
drwxrwxrwx  2 root     root          4096 Mar 11  2015 telnet
-rw-------  1 root     root        329620 Feb 27 18:46 vdr_error.log
-rw-------  1 root     root      16031088 Feb 26 04:00 vdr_error.log-20170226
drwxr-xr-x  2 vdradmin vdradmin      4096 Jan 27 09:18 vdradmin
-rw-r--r--  1 root     root           380 Feb 27 12:10 vdradmplg.log
drwxrwxrwx  2 root     root          4096 Feb  2 14:28 wicd
-rw-rw-r--  1 root     utmp        330624 Feb 27 18:56 wtmp
drwxrwxrwx  2 vdr      vdr           4096 Nov 27  2015 xxv
g2v ~ #


Das Massage File im Log Ordner ist mit ~860MB sehr groß.

EDIT:
Anbei ein Log mit deaktivierten VDRAdmin.

Geschrieben von: HelAu am Dienstag, 28.Februar 2017, 11:07 Uhr
Gut jetzt ist die syslog nicht leer, und zum Zeitpunkt des Logerstellens sehe ich kein ernsthaftes Problem, hattest Du da dennoch das Einzelbildproblem ?

Geschrieben von: bbott am Dienstag, 28.Februar 2017, 18:29 Uhr
Also ich hatte im admin Tool VDRadmin deaktiviert, nach einem Reboot hebe ich festgestellt, dass er trotzdem noch läuft und manuell beendet. Trotzdem kam die Diashow nach ein paar Stunden.

So ich habe jetzt noch mal den Skindesigner und weather deaktiviert.

Geschrieben von: bbott am Samstag, 04.März 2017, 18:43 Uhr
So ich habe heute morgen das System neu aufgesetzt, die Config nicht vom alten VDR gesichert, aber das Problem besteht immer noch.

Die DVB-Treiber noch nicht aktualisiert und keine Updates außer die V6.0 Update 5 eingespielt.

Plugins aktiviert habe ich nur:
- burn
- tvm2vdr
- streamdev-server


Nun ist zu den Standard-Plugins nur noch streamdev-server aktiv.

Geschrieben von: HelAu am Sonntag, 05.März 2017, 00:23 Uhr
Dummerweise ist die syslog wieder leer. Wie erstellst Du das Logpaket ? per Gui oder per shell ?
Idealerweise immer per ssh während der Fehler auftritt.
Und falls die syslog leer ist dann sollte im Fenster ein Fehler zu sehen sein

Geschrieben von: bbott am Sonntag, 05.März 2017, 12:56 Uhr
Ich sammle per vdradmin, osd und manchmal per shell die Logs. Ich ging bisher davon aus, dass alle drei Varianten den gleichen Konsolen befehl absetzen.

Ich habe nun alle drei Variante ausprobiert, die VDRadmin Variante schein nicht mehr zufunktionieren:
- VDRadmin 175KB
- OSD 448KB
- Shell 1.228KB


Leider kann ich die Logs erst nach dem Fehler sammel, evtl. könnte ich es nochmals versuchen über das OSD anzustoßen. Shell und Konsole gehen nicht da ein Login wie bereits erwähnt nicht mehr möglich ist, da nach dem Passwort das Login einfriert.

Im Angang habe ich alle drei Varianten.

Geschrieben von: HelAu am Sonntag, 05.März 2017, 21:22 Uhr
Gut bei einem 600 MB Logfile wundert mich das nicht.
Irgendwas ist mit vdradmin im Argen , bevor Du die vdradmin Fehlermeldungen nicht weg hast braucht man nicht nach anderen Fehlern zu suchen

Geschrieben von: bbott am Montag, 06.März 2017, 19:46 Uhr
Anbei das Log bei Fehler per OSD, Konsole ging nicht.

VDRadmin ist deaktiviert.

Geschrieben von: HelAu am Dienstag, 07.März 2017, 09:01 Uhr
Das hilft leider auch nichts, irgendwas frisst deine filehandles auf.
Kannst Du mal neu starten und:
lsof > /tmp/lsof.out1
machen.
und nach ner halben Stunde
lsof > /tmp/lsof.out2
und diese beiden Ausgaben gziped posten ?
Und falls die Kiste jetzt noch läuft dann poste die aktuelle Ausgabe von lsof vor dem Reboot (auch gzipped)

Geschrieben von: MegaV0lt am Dienstag, 07.März 2017, 09:30 Uhr
Ich habe ja keine Ahnung, aber in der ps.out sind viele SCREEN-Prozesse (runterfahren) zu sehen. Kann das sein? Beenden die sich nicht von selbst?

Und in top.out über 500 Tasks ist sicher nicht normal. Bei mir sind es ~180

Und was ist bioset?

Geschrieben von: HelAu am Dienstag, 07.März 2017, 09:46 Uhr
So wie das aussieht hängt der dbus wenn ihm die filehandles ausgehen. Die ganzen hängeden Prozesse sind alles Folgefehler vom Ausgehen der filehandles, also müssen wir erst rausbekommen, was die filehandles ausgehen lässt

Geschrieben von: MegaV0lt am Dienstag, 07.März 2017, 15:14 Uhr
Ok, vielleicht macht es ja Sinn, die Befehle
CODE
lsof > lsof.out
screen -list > screen.out
mit in die g2v_log.sh aufzunehmen?

Geschrieben von: HelAu am Dienstag, 07.März 2017, 15:28 Uhr
Zumindest die von lsof , die screen tasks finden sich ja auch in der ps.out

Geschrieben von: bbott am Dienstag, 07.März 2017, 17:33 Uhr
@Helau

anbei die lsof 1 und 2. THX

Geschrieben von: HelAu am Dienstag, 07.März 2017, 23:53 Uhr
Das sieht beides noch ganz normal aus. Wenn das Problem auftritt dann schick mal eine neue Ausgabe von lsof

Geschrieben von: bbott am Mittwoch, 08.März 2017, 07:27 Uhr
Würde ich gerne bisher war es aber so das ich weder per SSH noch per Konsole mich einloggen konnte.

Was mir noch aufgefallen ist, dass ein Ausschalten per OSD nicht möglich ist er geht in eine Endlosschleife, kündigt immer wieder das Herunterfahern an ohne es zu tun. Beim Neustart per OSD klappt es und ein angefangenes Login (SSH) ging aufeinmal und es wurde mehrfach gemeldet, dass das System herunterfährt und das system neugestartet.

Geschrieben von: HelAu am Mittwoch, 08.März 2017, 08:22 Uhr
Und Du kannst nicht per Tastatur ran und mittels ctrl-f1 auf die Konsole ?

Geschrieben von: bbott am Mittwoch, 08.März 2017, 11:07 Uhr
Leider beleibt er da auch nach der Passworteingabe hängen.

Geschrieben von: MegaV0lt am Mittwoch, 08.März 2017, 12:17 Uhr
Packe mal das Skript z. B. nach /root und lasse es beim VDR-Start mitlaufen:
CODE
cd /root
wget https://dl.dropboxusercontent.com/u/1490505/VDR/log_lsof.sh
chmod +x /root/log_lsof.sh

Im Hintergrund starten (Bis zum nächsten reboot):
CODE
/root/log_lsof.sh &


Optional:
CODE
echo '/root/log_lsof.sh &' > /etc/vdr.d/8099_log_lsof

Danach wir das Skript immer beim VDR-Start geladen und läuft im Hintergrund. Es werden max. 25 logs erstellt. Danach werden die alten überschrieben.

Selbst nicht getestet müsste aber gehen...

Hier der Inhalt
CODE
#!/bin/bash

# log_lsof.sh
# Script to get the output of lsof every 15 minutes
# Saves log to /var/log/lsof_yymmdd.xx.out

SELF="$(readlink /proc/$$/fd/255)" || SELF="$0"  # Eigener Pfad (besseres $0)
SELF_NAME="${SELF##*/}"                          # skript.sh

MY_PID=($(pidof -x "$SELF_NAME"))                # Mehr als eine PID?
if [[ ${#MY_PID[@]} -gt 1 ]]; then
 echo "$SELF_NAME alredy running - Exit!" >&2
 exit 1
fi

cnt=0  # Zähler
WAITTIME=$((15*60))  # Wartezeit in Sekunden
LSOF_OUT="/var/log/lsof_$(date +%y%m%d)"  # Datei ohne Zähler und ".out"

while true; do
 ((cnt+=1)); [[ $cnt -gt 25 ]] && cnt=1  # Max. 25 Versionen
 lsof > "${LSOF_OUT}.${cnt}.out"
 sleep "$WAITTIME"
done



Edit: Da hatte noch das exit im Skript gefehlt (Zeile 12)

Geschrieben von: MegaV0lt am Mittwoch, 08.März 2017, 15:24 Uhr
Anstatt das Skript automatisch zu starten kann anstelle der letzten echo ... auch nur das angegebnen werden:
CODE
/root/log_lsof.sh &
Dann läuft das Skript nur bis zum nächsten reboot...

Geschrieben von: bbott am Mittwoch, 08.März 2017, 23:23 Uhr
@MegaV0lt
Schon mal Danke.

Ich habe es nun ~3,5h laufen lassen, das Bild ist noch i. O., allerdings geht das Login per Putty nicht mehr, d. h. evtl. ist schon was zu sehen?

Geschrieben von: HelAu am Mittwoch, 08.März 2017, 23:45 Uhr
Also ich seh noch nichts kannst Du ein logpaket per gui auf stick erstellen und posten ?! und wenns dann "kaputt" ist noch eines zusammen mit der lsof Ausgabe ?!

Geschrieben von: bbott am Donnerstag, 09.März 2017, 06:37 Uhr
Anbei nun mit Bildrucklern.

Geschrieben von: bbott am Donnerstag, 09.März 2017, 06:40 Uhr
Die Logs per OSD (nicht USB, USB kommt noch)

Geschrieben von: bbott am Donnerstag, 09.März 2017, 07:29 Uhr
So ich habe nochmal versucht USB-Logs zu ziehen, dass scheint nicht zu funktionneiren. Da das Login nicht mehr funktioniert, denke ich, dass der USB-Stick auch nicht mehr mounten kann und somit die Logs nicht mehr auf den Stick kopiert werden können.

Geschrieben von: HelAu am Donnerstag, 09.März 2017, 07:45 Uhr
Hat sich am lsof log was geändert ? Wobei natuelich die Gefahr besteht dass die Filehandles aus sind

Geschrieben von: HelAu am Donnerstag, 09.März 2017, 08:58 Uhr
Aber zuerst mal würde ich das filehandle limit hochsetzen:
CODE
echo "fs.file-max = 2097152" > /etc/sysctl.d/fsmax.conf
reboot

und beobachten ob das nicht alleine hilft ....

Geschrieben von: HelAu am Donnerstag, 09.März 2017, 10:19 Uhr
Erweitere mal das Script von Megavolt ein bisschen:
CODE
#!/bin/bash

# log_lsof.sh
# Script to get the output of lsof every 15 minutes
# Saves log to /var/log/lsof_yymmdd.xx.out

SELF="$(readlink /proc/$$/fd/255)" || SELF="$0"  # Eigener Pfad (besseres $0)
SELF_NAME="${SELF##*/}"                          # skript.sh

MY_PID=($(pidof -x "$SELF_NAME"))                # Mehr als eine PID?
if [[ ${#MY_PID[@]} -gt 1 ]]; then
echo "$SELF_NAME alredy running - Exit!" >&2
exit 1
fi
DB=$(date +%y%m%d%H%M)
cnt=0  # Zähler
WAITTIME=15  # Wartezeit in Sekunden
LSOF_OUT="/var/log/lsof_$DB"  # Datei ohne Zähler und ".out"
cat /proc/sys/fs/file-nr > "${LSOF_OUT}.${cnt}.out"
OLD_FNR=$(cut -f1 "${LSOF_OUT}.${cnt}.out")
MAX_FNR=$(cut -f3 "${LSOF_OUT}.${cnt}.out")
lsof >> "${LSOF_OUT}.${cnt}.out"
                                         
while true; do
  FNR=$(cut -f 1 /proc/sys/fs/file-nr)
  if [ $((FNR-OLD_FNR)) -gt 1000 ]; then
     ((cnt+=1)); [[ $cnt -gt 25 ]] && cnt=1  # Max. 25 Versionen
     {
     cat /proc/sys/fs/file-nr
     lsof
     tail -n 100 /log/messages
     } > "${LSOF_OUT}.${cnt}.out"
     gzip -f "${LSOF_OUT}.${cnt}.out"
     OLD_FNR=$FNR
     if [ $((FNR+50000)) -gt $MAX_FNR ]; then
        logger -s "Max Filenumbers nearly reached"
        /_config/bin/g2v_log.sh  "${LSOF_OUT}"
        screen -dm sh -c "reboot"
     fi
     logger -s "Filenumbers increased"
  fi
  sleep "$WAITTIME"
done


Damit wird alle 15 Sekunden geprüft ob die Filehandles um 1000 seit dem letzten Log gestiegen sind und falls ja dies in ein Log geschrieben.
Sind die Filehandles am Ende wird ein Reboot ausgelöst.
Lass dies mal laufen und falls es zum Reboot kommt, oder du manuell einen Restart machen musst, dann schick danach alle lsof_* Datein unter /log

Geschrieben von: bbott am Donnerstag, 09.März 2017, 17:02 Uhr
Danke. Ich habe nun Helau erweitertes Skrip am laufen, anbei die ersten Logs (ohne sichtbare Fehler!).


Geschrieben von: bbott am Donnerstag, 09.März 2017, 19:35 Uhr
Nach einem Reboot kommen folgende Logs heraus:

Geschrieben von: HelAu am Donnerstag, 09.März 2017, 22:25 Uhr
Ich denke mal das Problem ist Lirc. Funktioniert die AtricUSB FB ?
Lirc zieht 100 % CPU da ist was faul.

Geschrieben von: bbott am Donnerstag, 09.März 2017, 23:00 Uhr
Nein, seit der V6 klappt bei LIRC nichts mehr, es kommen gar keine Codes (irc etc.) mehr an. Selbst die LED sind tot.

Geschrieben von: bbott am Samstag, 11.März 2017, 17:58 Uhr
Ich habe jetzt ArticUSB deaktiviert und vom USB-Port abgezogen. Trozdem habe ich das verhalten. sad.gif

Geschrieben von: HelAu am Dienstag, 14.März 2017, 00:01 Uhr
Läuft denn Lirc noch ?

Geschrieben von: bbott am Mittwoch, 15.März 2017, 20:44 Uhr
In Top und inputlirc zeigen kein laufendes lirc mehr an.

Geschrieben von: HelAu am Mittwoch, 15.März 2017, 23:15 Uhr
Dann gehen mit jetzt die Ideen aus, was an Deinem System anders ist, ist die AMD GPU denkbar dass es an der Kombination mit dem Softhddevice liegt.
Aktiviere doch mal einen der anderen softhddevice branches die unter /usr/local/src/VDR/PLUGINS/src vorhanden sind.

P.S.
CODE
VFS: file-max limit 524288 reached

Ich dachte Du hast das hochgesetzt ?!

Geschrieben von: bbott am Donnerstag, 16.März 2017, 21:13 Uhr
Welcher softhddevice branches ist standard mäßig aktiv? Ich habe in der Readme als auch im Forum keine Infos zum wechsel des softhddevice branches gefunden.

Geschrieben von: bbott am Donnerstag, 16.März 2017, 23:20 Uhr
QUOTE (HelAu @ Donnerstag, 16.März 2017, 00:15 Uhr)
P.S.
CODE
VFS: file-max limit 524288 reached

Ich dachte Du hast das hochgesetzt ?!




Ich habe es wie R2D2 schrieb auf 524288 erhöht
CODE
echo "fs.file-max = 524288" >>  /etc/sysctl.conf


Soll ich es nochmals erhöhen?

Geschrieben von: HelAu am Freitag, 17.März 2017, 09:46 Uhr
QUOTE (bbott @ Donnerstag, 16.März 2017, 23:20 Uhr)
Ich habe es wie R2D2 schrieb auf 524288 erhöht
CODE
echo "fs.file-max = 524288" >>  /etc/sysctl.conf


Soll ich es nochmals erhöhen?

http://www.htpc-forum.de/forum/index.php?showtopic=10410&view=findpost&p=73776

Geschrieben von: bbott am Freitag, 17.März 2017, 17:37 Uhr
@Helau

Da es vor der Neuinstallation nicht geholfen hatte, habe ich es nicht mehr auf dem Radar gehabt. Ich hoffe das es nun hilft. Sorry und Danke.

Geschrieben von: bbott am Sonntag, 19.März 2017, 11:25 Uhr
Ich wollte schon schreiben, dass das Problem nicht mehr auftritt. Leider passiert es immer noch nur dauerte es länger.

Geschrieben von: MegaV0lt am Sonntag, 19.März 2017, 11:53 Uhr
Du könntest mal, so weit Möglich, den VDR mal ohne VDR laufen lassen: stp vdr
Dann könnte man schon mal eingrenzen, ob es am System oder am VDR/Plugins liegt. Für den Test kannst Du das VFS ja wieder runter setzen...

Geschrieben von: bbott am Dienstag, 21.März 2017, 17:11 Uhr
QUOTE (MegaV0lt @ Sonntag, 19.März 2017, 12:53 Uhr)
Du könntest mal, so weit Möglich, den VDR mal ohne VDR laufen lassen: stp vdr
Dann könnte man schon mal eingrenzen, ob es am System oder am VDR/Plugins liegt. Für den Test kannst Du das VFS ja wieder runter setzen...

Ich bin noch nicht dazu gekommen ein passend großes Zeitfenster zu finden.

Heute als ich neustarten wollte per OSD, ist das VDR-Programm abgestürzt und neugestartet

Danach war das Bild i. O., anbei das Log das danach erstellt wurde.

EDIT:
SSH geht danach auch wieder, scheint wirklich ein VDR Problem zu sein?! Aber das ist doch immer noch 2.2.0?! Das hatte doch schon die V5.x?!

Geschrieben von: MegaV0lt am Dienstag, 21.März 2017, 17:28 Uhr
Hast Du schon mal den VDR neu gebaut incl. "Clean"? Und auch mal die Plugins aktualisieren lassen
Ich vermute ein Plugin. So viele hast Du ja nicht am laufen.

Die Plugins:
CODE
Mar 21 06:44:39 g2v vdr[3618]: [3618] loading plugin: /usr/local/lib/vdr/libvdr-osdteletext.so.2.2.0 *
Mar 21 06:44:39 g2v vdr[3618]: [3618] loading plugin: /usr/local/lib/vdr/libvdr-epgsearch.so.2.2.0 *
Mar 21 06:44:39 g2v vdr[3618]: [3618] loading plugin: /usr/local/lib/vdr/libvdr-femon.so.2.2.0 *
Mar 21 06:44:39 g2v vdr[3618]: [3618] loading plugin: /usr/local/lib/vdr/libvdr-live.so.2.2.0
Mar 21 06:44:39 g2v vdr[3618]: [3618] loading plugin: /usr/local/lib/vdr/libvdr-epgtableid0.so.2.2.0
Mar 21 06:44:39 g2v vdr[3618]: [3618] loading plugin: /usr/local/lib/vdr/libvdr-dbus2vdr.so.2.2.0 *
Mar 21 06:44:39 g2v vdr[3618]: [3618] loading plugin: /usr/local/lib/vdr/libvdr-weatherforecast.so.2.2.0
Mar 21 06:44:39 g2v vdr[3618]: [3618] loading plugin: /usr/local/lib/vdr/libvdr-admin.so.2.2.0 *
Mar 21 06:44:39 g2v vdr[3618]: [3618] loading plugin: /usr/local/lib/vdr/libvdr-streamdev-server.so.2.2.0
Mar 21 06:44:39 g2v vdr[3618]: [3618] loading plugin: /usr/local/lib/vdr/libvdr-skindesigner.so.2.2.0
Mar 21 06:44:39 g2v vdr[3618]: [3618] loading plugin: /usr/local/lib/vdr/libvdr-tvguideng.so.2.2.0
Mar 21 06:44:39 g2v vdr[3618]: [3618] loading plugin: /usr/local/lib/vdr/libvdr-skinnopacity.so.2.2.0
Mar 21 06:44:39 g2v vdr[3618]: [3618] loading plugin: /usr/local/lib/vdr/libvdr-softhddevice.so.2.2.0 *
Sind ja nicht so viele. Schau mal ob die alle aktuell sind. Die mit dem * habe ich selber laufen...

Geschrieben von: bbott am Dienstag, 21.März 2017, 17:40 Uhr
Ich habe noch nichts aktualisiert, nur die gen2vdr Updates eingespielt.

Du meinst:

CODE

emerge --sync
layman -S



CODE

 make clean
 make
 make clean-plugins
 make plugins



CODE

/_config/bin/vdrmkplg.sh
/_config/bin/instvdr.sh

Geschrieben von: MegaV0lt am Mittwoch, 22.März 2017, 08:27 Uhr
Ich dachte an
CODE
/_config/bin/build-vdr2.sh

Die Fragen Updates aktualisieren und Clean bauen mit "j" beantworten.
Bei Debug mache ich immer "n", weil der VDR so deutlich langsamer reagiert.

Das Skript baut dann den VDR und alle Plugins neu. Am Ende wird noch gefragt, ob der VDR aktiviert werden soll. Das kopiert dann die Dateien an die richtige Stelle.


Geschrieben von: HelAu am Mittwoch, 22.März 2017, 08:57 Uhr
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)

Geschrieben von: franky am Mittwoch, 22.März 2017, 13:14 Uhr
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 http://www.htpc-forum.de/forum/index.php?showtopic=10016 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.

Geschrieben von: bbott am Mittwoch, 22.März 2017, 18:11 Uhr
Danke franky für die Infos.

Geschrieben von: franky am Freitag, 24.März 2017, 23:19 Uhr
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

Geschrieben von: franky am Sonntag, 26.März 2017, 13:30 Uhr
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 https://www.mesa3d.org/ ist die 13.0.6 das finale Release der 13er Serie.

Geschrieben von: bbott am 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 Mesa Version zu wechseln, leider bisher ohne Erfolg.

EDIT: Rechtschreibung

Geschrieben von: R2D2 am Sonntag, 26.März 2017, 16:26 Uhr
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. biggrin.gif tongue.gif

Geschrieben von: franky am Sonntag, 26.März 2017, 16:37 Uhr
Hi bbott,

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

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

Geschrieben von: bbott am Sonntag, 26.März 2017, 17:12 Uhr
@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.

Geschrieben von: R2D2 am Sonntag, 26.März 2017, 17: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. ^^

Geschrieben von: bbott am Sonntag, 26.März 2017, 17:44 Uhr
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.

Geschrieben von: franky am Sonntag, 26.März 2017, 18:40 Uhr
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.

Geschrieben von: bbott am Sonntag, 26.März 2017, 19:49 Uhr
Das emerge -av mesa hatte beim erstmal Fehler ausgespuckt, beim zweiten Anlauf lief es und 13.0.6 ist nun aktiv. Danke franky.

Geschrieben von: bbott am Mittwoch, 29.März 2017, 19:14 Uhr
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

Geschrieben von: bbott am Mittwoch, 29.März 2017, 19:21 Uhr
Eine lsof_ Datei, nach dem Crash erstellt.

Geschrieben von: franky am Mittwoch, 29.März 2017, 21:09 Uhr
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.

Geschrieben von: bbott am Donnerstag, 30.März 2017, 19:30 Uhr
@franky

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

Das HQ werde ich beim nächsten mal herunterstellen.

Geschrieben von: franky am Donnerstag, 30.März 2017, 23:22 Uhr
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 http://www.vdr-wiki.de/wiki/index.php/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!

Geschrieben von: franky am Freitag, 31.März 2017, 21:39 Uhr
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.

Geschrieben von: bbott am Freitag, 11.August 2017, 15:28 Uhr
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?

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)