Beiträge von fausouthpark

    Ich habe meinen Rasberry PI 2 Model B mit der aktuellen Version von OpenELEC (7.0 beta 3, interne Version 6.95.3) mit dem Remote Pi Board von MSL Digital Solutions erweitert.

    Wie in der Anleitung von MSL Digital Solutions beschrieben (http://www.msldigital.com/pages/support-…board-plus-2015) habe ich die autostart.sh, das erste Script (irswitsch.sh) und das 2. Script (invoke shutdown in der OpenELEC-Version) installiert.

    Shutdown, Startup und die Fernbedienung über IR funktionieren sehr gut.

    Leider hat das System jedoch sporadisch, bei jedem 2. bis 3. Systemstart, Probleme die ihm zugewiesene IP-Adresse zu verwenden und ist dementsprechend nicht über IP ansprechbar. Die Zuweisung der IP-Adresse über DHCP sollte hierbei irrelevant sein, da das Problem auch bei einer festen IP-Adresse auftritt.

    Sobald ich das LAN-Kabel ab- und wieder anstecke, bezieht das System sofort die richtige IP-Adresse und ist ansprechbar. Ich vermute das Problem im Bereich Timing beim Systemstart/Netzwerkschnittstelle. Hat evtl. jemand aus dem
    Forum das Board in einer ähnlichen Konstellation am laufen, bzw. Erfahrung mit den Scritps von MSL?

    Anbei die eingesetzten Scripts für Startup/Shutdown:

    #!/bin/bash
    # prevent restarting XBMC at shutdown. This is only used for OpenElec before V5
    LOCKDIR="/var/lock/"
    LOCKFILE="xbmc.disabled"
    # this is the GPIO pin receiving the shut-down signal
    GPIOpin1=14
    # functions
    add_omit_pids() {
    omit_pids="$omit_pids -o $1"
    }
    safe_shutdown () {
    # for OpenElec before V5
    touch "$LOCKDIR/$LOCKFILE"
    # for OpenElec V5 and later
    systemctl stop kodi
    add_omit_pids $(pidof connmand)
    add_omit_pids $(pidof dbus-daemon)
    killall5 -15 $omit_pids
    for seq in `seq 1 10` ; do
    usleep 500000
    clear > /dev/tty1
    killall5 -18 $omit_pids || break
    done
    sync
    umount -a >/dev/null 2>&1
    poweroff -f
    }
    echo "$GPIOpin1" > /sys/class/gpio/export
    echo "in" > /sys/class/gpio/gpio$GPIOpin1/direction
    while true; do
    sleep 1
    power=$(cat /sys/class/gpio/gpio$GPIOpin1/value)
    if [ $power != 0 ]; then
    echo "out" > /sys/class/gpio/gpio$GPIOpin1/direction
    echo "1" > /sys/class/gpio/gpio$GPIOpin1/value
    sleep 3
    safe_shutdown
    fi
    done

    ----------

    #!/bin/bash
    if [ "$1" != "reboot" ]; then
    GPIOpin=15
    GPIOpin1=14
    echo "$GPIOpin" > /sys/class/gpio/export
    # execute shutdown sequence on pin
    echo "out" > /sys/class/gpio/gpio$GPIOpin/direction
    echo "1" > /sys/class/gpio/gpio$GPIOpin/value
    usleep 125000
    echo "0" > /sys/class/gpio/gpio$GPIOpin/value
    usleep 200000
    echo "1" > /sys/class/gpio/gpio$GPIOpin/value
    usleep 400000
    echo "0" > /sys/class/gpio/gpio$GPIOpin/value
    # set GPIO 14 high to feedback shutdown to RemotePi Board
    # because the irswitch.sh has already been terminated
    echo "$GPIOpin1" > /sys/class/gpio/export
    echo "out" > /sys/class/gpio/gpio$GPIOpin1/direction
    echo "1" > /sys/class/gpio/gpio$GPIOpin1/value
    usleep 4000000
    fi

    Ich habe mich gestern noch einmal intensiv mit der Synology Media Station, die wiederum die Synology Video Station voraussetzt, beschäftigt.

    Fazit:
    Es ist mir gelungen 4K-Inhalte über einen längeren Zeitraum über DNLA auf dem Samsung TV fehlerfrei in der nativen Auflösung abzuspielen.
    Leider verhält sich der DNLA-Player dabei nicht gerade optimal, so bereitet vor- und zurückspulen, oder auch die Auswahl der Quellen nicht gerade Freude.

    Die Verwendung der für Samsung verfügbaren Synology Video Station-APP bietet bei der Aufbereitung der Auswahl der Quellen zwar eine gute Lösung, fängt aber leider auch wieder das Stocken an und ist damit wie der Einsatz des Kodi -DNLA-Servers nicht sinnvoll möglich.

    Das Synology NAS zeigt bei dem obig angesprochen fehlerfreien Abspielen eines Streams eine Downloadrate vom NAS von < 5 MByte/s, was < 40 Mbit/entspricht.
    Soweit der rpi wie von david.copperfile beschrieben die Bandbreite auf Grund des Routings "teilt", könnte die 10/100er Ethernet Schnittelle dann doch zum Problem werden.
    Warum die Synology Video Station-APP trotz identischer Quelle stockt wird wohl ein Rätsel bleiben.

    Schade, ich würde immer noch gerne den Kodi -DNLA-Server einsetzen.
    Ohne die Möglichkeit über die Parametern des DNLA-Servers evtl. noch etwas rauszuholen habe ich aber keinen Ansatzpunkt mehr.

    Nord75:
    4K-Streaming sollte, nach dem was ich bis jetzt gelesen haben ab ca. 15 Mbit/s grundsätzlich möglich sein. Voraussetzung hierfür ist jedoch, dass der DLNA-Client ausreichend buffern kann. Der Datendurchsatz sollte damit am Anfang des Streams in die Maximale Auslastung der Bandbreite gehen, und dann auf ca. 15 Mbit/s abfallen.
    Das sollte eigentlich mit einer 10/100er Ethernet Schnittstelle möglich sein.

    @david.coperfiel:
    Danke für die Idee, aber ich habe diese Möglichkeit mit den Synology Standard-Apps schon geprüft und verworfen, wie bereits in meinem ersten Post geschrieben.



    Der Einsatz von Video-Station oder Plex als DLNA-Server auf dem NAS ist leider keine Option, da nach meiner Erfahrung keine native Wiedergabe der Inhalte möglich ist.
    Auch die Anschaffung neuer Hardware ist aktuell keine Option, da ich gerne mit der bestehenden Hardware eine Lösung finden möchte.

    Der Samsung TV erkennt die 4K-Inhalte gem. eigener Systeminfo bei der Wiedergabe als (3840 × 2160 Pixel), die Framerate wird leider nicht dargestellt.
    Da es ist um Referenzmaterial für Präsentationszwecke verschiedener TV-Hersteller gehandelt hat sollte es auch "richtiges" 4K sein.

    Gibt es evtl. eine Möglichkeit am Rasberry Performance Lacks über eine Logdatei auszulesen, etc.?

    Ich möchte gerne 4K-Inhalte auf meinem Samsung TV (UE55KU6459) wiedergeben, die Files sollen dabei auf dem vorhandene NAS (Synology DS216J) gespeichert sein.

    Da mein Rasberry Pi B+ (OpenElec 7.0 Beta 3) die 4K-Inhalte auf Grund der fehlenden Hardwareunterstützung nicht wiedergeben kann, habe ich daran gedacht die 4K-Files nativ über den DLNA-Server von Kodi an den Samsung TV zu streamen.
    Der Samsung TV kann DLNA und mit 4K-Inhalten umgehen (H.265/HEVC-Codec Unterstützung) und die 4K-Inhalte lassen sich auch über den DNLA-Client des Samsung TV problemlos anwählen.

    Problem: Obwohl alle beteiligten Komponenten (Rasberry Pi B+, NAS und Samsung-TV) über LAN angebunden sind kommen die Videos immer wieder zum Stocken, da vermutlich nachgeladen werden muss.


    Gibt es Erfahrung bzgl. der Wiedergabe von 4K-Inhalten über den DLNA-Server von Kodi die mir evtl. weiterhelfen können, z.B. Konfigurationsanpassungen im Bereich des DLNA-Servers?

    Der Einsatz von Video-Station oder Plex als DLNA-Server auf dem NAS ist leider keine Option, da nach meiner Erfahrung keine native Wiedergabe der Inhalte möglich ist.
    Auch die Anschaffung neuer Hardware ist aktuell keine Option, da ich gerne mit der bestehenden Hardware eine Lösung finden möchte.

    Vielen Dank, Fau