Posts by Paulaner

    Die Muxe liest TVH automatisch aus der m3u-Liste von der telerising.api ein. Aus den Muxen werden dann die Services erstellt.

    Man muss also nicht jeden Mux einzeln bearbeiten. Aber dazu am Besten im Kodi-Forum informieren, da sind die TVH Profis unterwegs!


    Die ganzen Einstellungen bei TVH sind etwas Tricky, aber es gibt da einige Tutorials die weiterhelfen. Ich habe auch mir alles zusammen gesucht und durch rumprobieren getestet.


    Mit den Aufnahmen muss ich nochmal etwas rumprobieren, da habe ich lange nichts mehr probiert. Das wird aber auf jeden Fall irgendwie gehen, denn in KODi funktioniert es ja auch.


    Momentan habe ich nicht allzuviel Zeit, da ich viel Unterwegs bin. Kommende Woche bin ich auch nicht zu Hause, erst Ende Mai werde ich wieder Zeit haben.

    Hat jemand von euch einen zattoo premium Vertrag und konnte testen ob man mit Telerising auch 2 oder mehr gleichzeitige Streams haben kann?

    Bei Zattoo gibt es momentan 3 Streaming-Tarife. Alle Tarife kann man kostenlos für 1 Monat testen und bei einem Abo sind diese monatlich kündbar.

    Ich habe den Zattoo Ultimate Tarif mit 4 gleichzeitigen Streams und das funktioniert auch so.

    Beim Premium-Tarif gibt es 2 gleichzeitige Streams, die Du auf 1 Gerät oder auf 2 verschiedenen Geräten Europaweit, also auch im Urlaub, anschauen kannst.



    wie ist denn der Stand der Dinge? Gibt es neue Erkenntnisse oder schon mal eine kleines Tutorial zum selber bauen/testen?

    Für einen produktiven Einsatz kann man z.Z. nur die zugehörigen Android-Apps von Zattoo verwenden.

    Hier funktioniert alles einwandfrei:

    • inkl. EPG
    • Timer-Aufnahmen in der Cloud
    • Wiedergabe von Anfang an, wenn man zu einer bereits laufenden Sendung schaltet.


    Eine weitere gut funktionierende Möglichkeit ist die Verwendung von KODI.

    Hier gibt es einige IPTV-Addons und auch ein spezielles ZattooHiQ-Addon, welches ähnlich wie die Android-Apps arbeiten.


    Eine weitere schon ziemlich gut funktionierende Lösung ist über die Telerising.api, TVheadend und KODI mit dem PVR-Addon "TVheadend HTSP Client".

    Hier funktioniert die Wiedergabe gut und die Timer-Aufnahmen funktionieren über TVheadend und werden dabei direkt auf dem eigenen PC und nicht in der Cloud gespeichert. In der Cloud sind die Aufnahmen begrenzt und werden nach glaub ich ca. einem Monat gelöscht.



    VDR mit dem IPTV-Plugin:

    Darum ging es ja die ganze Zeit in diesem Thread. ;)

    Für das vdr-plugin-iptv gibt es nach jetzigen Stand 3 Möglichkeiten die Streams von Zattoo zu empfangen.

    Grundlegend muss dazu immer mindestens das Script der Telerising.API verwendet werden, welches die einzelnen IPTV-Streams (TV-Sender) zur Verfügung stellt.


    Jetzt gibt es 2 Möglichkeiten diese Streams über das IPTV-Plugin in einen TS-Stream umzuwandeln, damit der VDR etwas damit anfangen kann:

    1. FFMPEG über das Script "ffmpeg2iptv_raw". Aktuelle Version des Scriptes im Anhang.
      Dazu muss man eine Datei /etc/vdr/plugins/urls.conf erstellen, welche die URL aus der Telerising.API für jeden Stream enthält.
    2. VLC-Player über das Script "vlc2iptv_raw". Aktuelle Version des Scriptes im Anhang.
      Hier muss man für jeden Stream eine Datei TV-Sender-Name.conf in /etc/vdr/plugins/iptv/vlcinput erstellen, welche die URL aus der Telerising.API für den Stream enthält. Man könnte das Script evtl. auch so umbauen, dass dafür auch die /etc/vdr/pugins/iptv/urls.conf  aus PKT. 1. genommen werden könnte.

    Eine 3. Möglichkeit für die Anzeige der IPTV-Streams ist den Stream vom TVheadend zu nehmen, denn in TVheadend wird der Stream bereits in einen TS-Stream umgewandelt. Hier wird nur die channelid von TVheadend gebraucht. Ein extra Script braucht man hierfür nicht, da ja der Stream schon als TS-Stream vorliegt.


    Auszug aus meiner /etc/vdr/plugins/iptv/urls.conf:

    Code
    1,http://192.168.1.3:5000/api/zde/live/ard.m3u8
    2,http://192.168.1.3:5000/api/zde/live/zdf.m3u8
    3,http://192.168.1.3:5000/api/zde/live/rbb-brandenburg.m3u8
    4,http://192.168.1.3:5000/api/zde/live/mdr-sachsen.m3u8
    5,http://192.168.1.3:5000/api/zde/live/ndr-niedersachsen.m3u8
    6,http://192.168.1.3:5000/api/zde/live/rtl_deutschland.m3u8
    7,http://192.168.1.3:5000/api/zde/live/pro7_deutschland.m3u8
    ...


    Auszug aus meiner channels.conf für die einzelnen Test-Möglichkeiten:


    FAZIT:

    Ein produktiver Einsatz im VDR ist aktuell noch nicht empfehlenswert, da es immer noch unterschiedliche Probleme mit der Umwandlung des IPTV-Streams in einen TS-Stream gibt. Die Probleme treten nur selten auf, stören dann aber doch schon etwas:

    • manchmal kein Bild nach umschalten
    • sehr selten Stocken der Wiedergabe für 1..2 Sekunden bei der Wiedergabe


    Was aber aktuell noch gar nicht funktioniert sind Timer-Aufnahmen. :(

    Manchmal funktioniert eine Timer-Aufnahem einwandfrei, aber meistens passiert es, dass nach 20 ... 30 Minuten die Aufnahme Störungen hat.

    Dabei fehlen dann Teile der Aufnahme, oder die Aufnahme endet einfach, weil nur noch Fehler da sind. da bin ich noch am suchen, woran das liegen könnte.



    Aktuell finde ich die Wiedergabe über den VLC-Player am besten, denn hier gibt es nur sehr, sehr selten eine Störung im Stream.

    Was beim VLC-Player noch stört, sind die langen Umschaltzeiten von ca. 10 sek. beim Zappen. Aber wenn es dann läuft gibt es peaktisch keine Bildstörungen mehr, kein Stocken des Bildes.


    ffmpeg2iptv_raw.txt

    vlc2iptv_raw.txt

    Bin wieder aus dem Urlaub zurück und habe mal kurz das aktuelle VDR*ELEC-Image mit dem geänderten vdr-plugin-softhdodroid gesteste:

    VDR-CoreELEC-Amlogic-ne.aarch64-21.1-Omega-2024-05-04.1-Generic.img.gz


    Jetzt habe ich auch Audio, wenn ich von KODI zurück zum VDR switche!

    Super! Dank an jojo61 :thumbup:



    Bei meinen heutigen Tests ist mir dann noch ein ganz anderer Fehler aufgefallen:

    Ich habe mir mal vor einigen Monaten (als ich noch SAT hatte) ein paar Minuten eines Fussballspiels bei RTL-UHD aufgenommen.

    Was ich seitdem als Test nehme, ob die Wiedergabe von UHD mit HDR-HLG funktioniert.


    Hier mit der Dune HD und dem CoreElec-ne.aarch64 mit Kernel 5.4.210 habe ich kein Bild.

    Wenn ich die Wiedergabe starte, dann bleibt das "alte" Bild stehen, ich höre den neuen Ton der Wiedergabe (DD+ 5.1) für ein paar Sekunden und dann ist auch der Ton stumm. :(


    Auf dem Odroid-N2 mit CoreELEC-ng.arm und Kernel 4.9.269 funktioniert die Wiedergabe dagegen einwandfrei:

    Bild in UHD mit HDR-HLG und der Ton in DD+ 5.1 :)

    Bevor man da aber mehr Zeit rein steckt, wollte ich erst mal sehen, ob das mit ffmpeg überhaupt sinnvoll funktioniert.

    Na ja, mit ffmpeg funktioniert es auf jeden Fall, denn das wird ja bei TvHeadend und dem zugehörigen KODI-Addon PVR-HTS-TvHeadend verwendet.


    Ich habe ja schon die Streams vom TvHeadend genommen und im VDR über das iptv-Plugin angeschaut. Funktioniert auch einwandfrei.

    Dazu holt man sich die channels.m3u aus dem TvHeadend: http://<ip-adresse>:9981/playlist

    und generoiert dann daraus Einträge für die vdr-channels.conf.


    Die channels.m3u von TvHeadend sieht so aus:

    Code
    #EXTM3U
    #EXTINF:-1 logo="https://ondemo.tmsimg.com/assets/s90447_ll_h15_ab.png?w=360&amp;h=270" tvg-id="44b9f53f46416f790d5c048a843d7a55" tvg-chno="1",Das Erste HD
    http://192.168.1.3:9981/stream/channelid/1073068356?profile=pass
    #EXTINF:-1 logo="https://ondemo.tmsimg.com/assets/s67217_ll_h15_ab.png?w=360&amp;h=270" tvg-id="98edca5553f74d339d4c8d823b52ad5a" tvg-chno="2",ZDF HD
    http://192.168.1.3:9981/stream/channelid/1439362456?profile=pass
    .....

    und daraus dann entsprechende Einträge in der channels.conf für das vdr-iptv-Plugin erstellt:

    Code
    :@41 IPTV Tvheadend
    Das Erste HD tvh;IPTV:410:S=0|P=0|F=CURL|U=http%3A//192.168.1.3%3A9981/stream/channelid/1073068356?profile=pass|A=410:I:0:258=27:256=@15;257=@122:0:0:1:0:0:0
    ZDF HD tvh;IPTV:420:S=0|P=0|F=CURL|U=http%3A//192.168.1.3%3A9981/stream/channelid/1439362456?profile=pass|A=420:I:0:258=27:256=@15;257=@122:0:0:1:0:0:0
    .....


    Damit kann man dann direkt die Streams anschauen, da diese bereits in das *.ts-Format gewandelt sind. :)

    Leider werden die EPG-Daten, die bereits in TvHeadend eingemappt sind über diese playlist-Streams , nicht mit weitergegeben.

    Das hatte ich ja am Anfang gehofft, denn da würde ich nur TvHeadend nehmen und hätte mir dem Rest erspart.

    Da aber leider das EPG nicht mit weitergegeben wird, wollte ich den Umweg über TvHeadend vermeiden und direkt eben das ffmpeg verwenden.



    In TvHeadend hat ja so viele Einstell-/Setup-Möglichkeiten, dass man sich da doch etwas einarbeiten muss, bevor man ein vernünftiges Ergebnis bekommt. Und das ffmpeg braucht man ja in jedem Fall, ob mit oder auch ohne TvHeadend.


    Ein Versuch wäre vielleicht noch die Streams über das satip-Plugin zu bekommen, d.h. das TvHeadend als SatIP-Server laufen zu lassen.

    Und dann mit dem vdr-satip-Plugin die Streams zu empfangen. das habe ich aber bisher noch nicht hinbekommen (habe auch nicht soviel getestet).

    Ich weiß aber leider nicht, ob da die EPG-Daten mitgegeben werden. :/

    Ich war schon froh, daß ich einen Treiber nach Anleitung kompilieren konnte (wenn auch erst im 2. Anlauf). Jetzt bin ich aber überfordert.

    Also das Kompilieren eines TBS-Treibers ist doch nun wirklich kein Zauberwerk:


    • Aktuellen Treiber von hier auf den VDR-Linux-PC runterladen: TBS Open Source Linux Driver Offline Package V20230829
    • Entpacken und auf der Konsole in das Verzeichnis "media_build" gehen.
    • Wenn man im Verzeichnis "media_build" ist, dann einfach ./install.sh eingeben
    • Warten bis alles kompiliert ist, dabei werden auch die zugehörigen Firmware-Dateien kopiert und dann 1x reboot machen
    • Das wars



    Oder so machen wie es in der Readme.txt steht:

    Code
    make sure that you have installed gcc then use these command
    
     wget http://www.tbsdtv.com/download/document/linux/media_build-2023-08-29.tar.bz2
     sudo rm -rf /lib/modules/`uname -r`/kernel/drivers/media/
     tar jxvf media_build-2023-08-29.tar.bz2
     cd media_build
     ./install.sh
     reboot


    Mehr ist da nicht zu tun.


    WICHTIG ist noch, nach einem Kernelupdate muss man den Treiber wieder neu kompilieren.

    Dazu nicht das "alte" Verzeichnis "media_build" nehmen, da gibt es meistens Probleme.

    Ich habe mir deshalb das Verzeichnis "media_build" an eine anderen Ort als sozusagen "Original" hinkopiert

    und kopiere es dann bei Bedarf nach /usr/src/media_build und mache da das ./install.sh

    Danach lösche ich dan das Verzeichnis "/usr/src/media_build" (ca. 1,5GB).

    Wenn dann das nächste Kernelupdate kommt, dann wird wieder das "Original" dahin kopiert und das Kompilieren kann beginnen.

    Ich habe noch etwas rumprobiert mit den Werten von PROBESIZE und ANALYZEDURATION aber eine wesentliche Verkürzung der Umschaltzeiten konnte ich nicht erreichen. Auch nach dem ich beide Werte ganz aus dem ffmpeg-Befehl gelöscht habe, war keine große Veränderung erkennbar.


    Ich habe die ffmpeg-commandline noch etwas angepasst und das Stream-Mapping aus der ///pipe ... von Telerising übernommen, wie es an TvHeadend übergeben wird. Hier mal am Beispiel für den Stream von "Das Erste HD", wie es von der telerising.api ausgegeben wird:

    Code
    pipe:///usr/bin/ffmpeg -loglevel fatal -re -i "http://192.168.1.3:5000/api/zde/live/ard" -ignore_unknown -map 0:0 -map 0:1 -map 0:2? -map 0:3? -map 0:4? -c:a:0 copy -c:a:1 copy -c:v copy -c:s copy -f mpegts -metadata service_name="Das Erste HD" pipe:1


    Und so sieht die ffmpeg-commandline momentan bei mir aus:

    Code
    LC_NUMERIC=C ffmpeg -loglevel warning -re -i "${URL}" \
      -ignore_unknown -map 0:0 -map 0:1 -map 0:2? -map 0:3? -map 0:4? -c:a:0 copy -c:a:1 copy -c:v copy -c:s copy \
      -f mpegts -map_metadata -1 -mpegts_transport_stream_id $TID -mpegts_pmt_start_pid 4096 -mpegts_service_id $SID \
      -mpegts_original_network_id $NID "udp://$HOST:$PORT?pkt_size=1316&buffer_size=65536&overrun_nonfatal=1" &>/tmp/ffmpeg.log &


    Die Umschaltzeiten zwischen den Streams sind bei mir ca. 3 ... 6 Sekunden bis Bild+Ton da sind, meistens sind es ca. 4 Sekunden. damit kann ich leben, denn ich bin nicht der Powerzapper, sondern schaue mir schon bewusst eine Sendung an.

    Aber dann gibt es ab und zu beim Zappen einen Stream, wo es dann auch mal wesentlich länger dauert, bzw. der Stream ganz stoppt und man muss dann 1x hin- und herschalten, damit wieder ein Bild kommt.


    Aufgefallen ist mir noch, dass meist zuerst das Bild nach ca. 2 Sek. da ist und dann dauert es noch 1 ... 3 Sek. ehe dann auch der Ton richtig da ist.

    Mit dem Audio-Ton gibt es bei mir noch die meisten Probleme. Im syslog hatte ich sehr oft beim Umschalten diese Meldung bzgl. Audio:

    Code
    yavdr vdr: [1256] switching to channel 113 I-65281-313-113 (3sat HD ffmpeg)
    yavdr api[1405]: 192.168.1.3 - - [21/Apr/2024 15:13:23] "GET /api/zde/live/3sat HTTP/1.1" 200 -
    yavdr vdr: audio: audio started and underrun, increase AudioBufferTime?!
    yavdr vdr: audio/alsa: wait underrun error? 'Datenübergabe unterbrochen (broken pipe)'


    Manchmal kam es dann sogar zu sehr vielen Bild- und Tonfehlern bis zum Bildausfall und dann waren es diese Meldung im syslog:

    Code
    yavdr vdr: message repeated 592 times: [ audio: audio started and underrun, increase AudioBufferTime?!]


    Ich habe daraufhin dann die "AudioBufferTime" im softhddevice-Plugin auf dem maximalen Wert von 1000ms erhöht.

    Nun kommen diese obigen Meldungen nur noch selten und der Stream läuft fast immer sauber durch.


    Ob es nun allgemeine Fehler im Stream sind, oder vermutlich doch eher ist das das Umkodieren der Audiostreams im ffmpeg nicht optimal konfiguriert. Denn bei der Android-App von Zattoo kommt das nicht vor. Da wird immer nach 2...3 Sekunden zum nächsten Stream geschaltet.


    Aber seit dem ich die softhddevice.AudioBufferTime = 1000 gesetzt habe sind die Meldungen wesentlich weniger geworden.

    Nur beim Umschalten auf einen anderen IPTV-Stream kommt fast immer noch diese Meldung, also ist das mit dem Audio noch nicht ganz okay.

    Code
    yavdr vdr: audio/alsa: wait underrun error? 'Datenübergabe unterbrochen (broken pipe)'

    Wenn ich hingegen zwischen den DVB-C Kanälen umschalte, dann habe ich diese Meldung nicht.



    Was mir jetzt noch fehlt ist das zugehörige EPG für die IPTV-Streams.

    Für TVheadend habe ich dazu bereits eine passende xmltv-Datei. Die müsste man doch eigentlich auch für die IPTV-Streams im VDR verwenden können.

    Nur weiß ich momentan noch nicht, wie ich diese mit den IPTV-Streams im VDR verknüpfen kann/muss. Das ist für mich noch absolutes Neuland!


    Das werde ich dann aber erst in 2 Wochen in Angriff nehmen können, denn in der kommenden Woche bin ich aber im Urlaub und werde in den Bergen wandern gehen. Zum Glück nicht hier in Deutschland, sondern es geht auf die Kanaren, da ist das Wetter doch wesentlich angenehmer! :)

    Ich habe die neue Version von Core*Elec VDR-CoreELEC-Amlogic-ne.aarch64-21.0-Omega-2024-04-20.1.tar installiert,

    um gleich noch den Patch gegen die Bildprobleme nach Wiedergabe eines VC-1 Videos von jojo61 zu testen.

    Die neue Testversion mit der Änderung in der "video.c" funktiniert einwandfrei. :thumbup:

    Nach der Wiedergabe eines VC-1 Videos und danach zurückswitchen zum VDR gibt es nun keine Bildprobleme mehr! Perfekt! :)


    Dann noch das Problem mit: "Kein Audio nach dem zurückswitchen von KODI zum VDR":

    Ich habe dazu mal die switch_vdr_softhdodroid.sh etwas abgeändert und den kompletten Speicherpfad im Script angegeben:

    Damit gibt es jetzt, die bereits weiter oben beschriebenen, Teilerfolge:

    * Switch von VDR zu KODI und dann direkt wieder zurück zum VDR: Audioton ist da! :thumbup:

    * Switch von VDR zu KODI und dann in Kodi ein Video o.ä. wiedergeben und erst danach zurück zum VDR: Da gibt es meistens kein switch direkt zum VDR, sondern es wird ein "Neustart" ausgeführt. Manchmal, aber sehr selten, wird dann doch direkt zum VDR geswitcht und der Audioton ist da.

    Diese Lösung ist nach m.M. die eleganteste, aber irgendwie ist da leider noch der Wurm drin! :(


    Hier mal noch die Ausgabe auf der Konsole, wenn ich manuell: "/usr/sbin/alsactl restore -f /storage/alsafile.dat" ausführe:

    Code
    /usr/sbin/alsactl restore -f /storage/alsafile.dat
    alsa-lib /home/vdrstern/actions-runner/_work/VDRSternELEC/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ne.aarch64-21/build/alsa-lib-1.2.11/src/ucm/main.c:1554:(snd_use_case_mgr_open) error: failed to import hw:0 use case configuration -2
    alsa-lib /home/vdrstern/actions-runner/_work/VDRSternELEC/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ne.aarch64-21/build/alsa-lib-1.2.11/src/ucm/main.c:1554:(snd_use_case_mgr_open) error: failed to import hw:0 use case configuration -2
    Found hardware: "AML-AUGESOUND" "" "" "" ""
    Hardware is initialized using a generic method
    /usr/sbin/alsactl: set_control:1475: Cannot write control '2:0:0:SPDIFIN audio samplerate:0' : Operation not permitted
    /usr/sbin/alsactl: set_control:1475: Cannot write control '2:0:0:SPDIFIN Audio Type:0' : Operation not permitted
    /usr/sbin/alsactl: set_control:1475: Cannot write control '2:0:0:AML chip id:0' : Operation not permitted
    /usr/sbin/alsactl: set_control:1475: Cannot write control '2:0:0:Media Video Delay:0' : Operation not permitted

    Trotz der ausgegebenen Fehler werden hier die gespeicherten Einstellungen für HDMITX Audio Source Select wiederhergestellt, d.h. wird von Spdif_b auf das für den VDR richtige Spdif gesetzt.

    Direkt im Umschalt-Script klappt das leider nur, wenn vorher in KODI nix gelaufen ist. Die oben gezeigte Konsolenausgabe ist dabei immer gleich. Ich habe das getestet, in dem ich den alsactl  restore - Befehl aus dem Script rauskommentiert habe und diesen dann manuell auf der Konsole eingegeben habe und über alsamixer konnte ich sehen, dass von "Spdif_b" nach "Spdif" gewechselt wurde.


    Warum das im Umschalt-Script nicht so richtig will kann vielleicht Zabrimus sagen. :/

    Das komische ist eben nur, dass das Script funktioniert, wenn vorher in KODI nichts gemacht wurde. Ansonsten kommt zu 90% ein Neustart/Reboot.




    Dann habe ich noch den anderen von jojo61 vorgeschlagenen Test gemacht und:

    Dann baue doch mal vor dem atta ein amixer set 'HDMITX Audio Source Select' Spdif ein

    Ich habe es getestet und es hat auf Anhieb funktioniert! :) :thumbup:

    Es ist eben nur nicht so allgemein einsetzbar wie der Vorschlag von beta , sondern eben speziell auf diesen Fall zugeschnitten.

    Das sieht dann so aus:

    Habe ich getestet, das resultat ist das gleiche!

    Muss ich doch noch etwas revidieren, denn manchmal klappt der Vorschlag, den beta gemacht hat doch:


    Wenn ich vom VDR zu KODI wechsel und dann ohne etwas in KODI zu machen, direkt wieder zurück zum VDR switche, dann habe ich Audio.

    Das ist ohne das /usr/sbin/alsactl restore -f /storage/alsafile.dat nicht so.

    Aber wenn ich vom VDR zu KODI switche und dann in KODI noch ein Video schaue, oder Musik höre und erst dann wieder zum VDR zurückswitche, dann wird ein "Reboot/Neustart" ausgelöst. Das ist dann nicht das was man will.


    Ich werde erst später am Tage wieder zu Hause sein und dann werde ich nochmal das ganze ausführlicher testen und schauen, was da evtl. im Log/Konsole zu sehen ist. Mir war das unterschiedliche Verhalten nämlich erst Gestern sehr spät am Abend aufgefallen.

    Habe ich mal versucht. Die switch_vdr_softhdodroid.sh sieht jetzt so aus:

    nach einem neustart und Wechsel zu KODI müsste doch eigentlich jetzt eine Datei /storage/alsafile.dat erstellt werden, aber es passiert nichts.


    Wenn ich allerdings manuell auf der Konsole ein /usr/sbin/alsactl store -f alsafile.dat ausführe, dann wird die Datei erstellt.

    Wenn ich dann die Datei ebenfalls auf der Konsole "restoren" will, dann kommt folgende Fehlermeldung:

    Code
    /usr/sbin/alsactl restore -f alsafile.dat
    alsa-lib /home/vdrstern/actions-runner/_work/VDRSternELEC/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ne.aarch64-21/build/alsa-lib-1.2.11/src/ucm/main.c:1554:(snd_use_case_mgr_open) error: failed to import hw:0 use case configuration -2
    alsa-lib /home/vdrstern/actions-runner/_work/VDRSternELEC/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ne.aarch64-21/build/alsa-lib-1.2.11/src/ucm/main.c:1554:(snd_use_case_mgr_open) error: failed to import hw:0 use case configuration -2
    Found hardware: "AML-AUGESOUND" "" "" "" ""
    Hardware is initialized using a generic method
    /usr/sbin/alsactl: set_control:1475: Cannot write control '2:0:0:SPDIFIN audio samplerate:0' : Operation not permitted
    /usr/sbin/alsactl: set_control:1475: Cannot write control '2:0:0:SPDIFIN Audio Type:0' : Operation not permitted
    /usr/sbin/alsactl: set_control:1475: Cannot write control '2:0:0:AML chip id:0' : Operation not permitted
    /usr/sbin/alsactl: set_control:1475: Cannot write control '2:0:0:Media Video Delay:0' : Operation not permitted


    Bin jetzt erstmal kurz unterwegs, kann erst später wieder weitermachen.

    Quote

    Ich habe mir das nochmal angeschaut. Hattest du auch das Umschaltscript für das Audio Device angepasst ? Also nach dem ATTA ein

    Code

    Code
    -a hw:CARD=AMLAUGESOUND,DEV=2 -p hw:CARD=AMLAUGESOUND,DEV=2

    eingebaut.

    Uuups, das habe ich irgendwie gar nicht mitgekriegt.

    Allerdings weiß ich gar nicht in welche Datei das reinkommen soll, denn diese ganze Umschaltscripte hat ja Zabrimus entwickelt.

    Da müsste evtl. er mal helfen, dann wüerde ich das testen.


    Ich habe Dir mal ein Sample-Video mit dem Videocodec VC-1 auf deine Cloud hochgeladen.

    Den Bildfehler erkennt man am Besten an scharfen Kanten im Bild bzw. an Texteinblendungen.


    Mit dem testen eines geänderten softhdodroid-Plugin ist das nicht so einfach, da ich immer die von Zabrimus bereitgestellten Images nehme. Ich hatte schonmal mit Selbstkompilieren versucht, aber dazu ist mein System einfach zu schwachbrüstig! X/

    Ihr nutzt ja auch unterschiedliche Ausgabeplugins.

    Yepp, das war aber vorher nicht klar, da pille2011 vorher nicht explizit geschrieben hatte, welches softhddevice-Plugin er verwendet.

    Deshalb habe ich ja meine Lösung für das von mir verwendete softhddevice-cuvid gepostet, falls andere demnächst auch auf das Problem stoßen sollten. ;)


    lnj

    Thank you very much for this information.
    So since there are no downsides to using -v nvdec, I'll stick with it for now. ;)

    pille2011

    also Deine Probleme "mit Tonaussetzern, Bild friert ein, UHD-Sender gehen gar nicht" kann ich so absolut nicht nachvollziehen.

    Das funktioniert bei mir alles einwandfrei.


    Der große Unterschied zwischen uns ist die Grafikkarte: GT1030 vs. T600!

    Mein Fehlerbild mit dem nvidia-535-Treiber ist ja auch ein anderes:

    Bei Dir Probleme mit SD-Sendern und bei mir mit HD-Sendern in 1080i

    Mir ist jetzt das gleiche passiert, das nach einem dist-upgrade auch der nvidia-Treiber von v525 auf v535 geändert wurde.

    Ich verwende das softhddevice-cuvid von lnj und hatte dann Bildfehler, allerdings nur in den Sendern mit 1080i Auflösung.


    Meine Lösung war, den Decoder von -v cuvid auf -v nvdec zu ändern. Jetzt ist das Bild auch bei den 1080i-Sendern wieder i.O.

    In den Settings zum softhddevice-cuvid-Plugin ist jetzt automatisch BWDIF eingestellt. Das habe ich erstmal so gelassen.


    Ich habe nun mal im Internet gesucht um herauszufinden, welche Vor- oder auch Nachteile die Nutzung von nvdec hat, aber so richtig schlau bin ich aus den Kommentaren dazu nicht geworden.

    Deshalb mal eine Frage in die Runde: Gibt es überhaupt Nachteile, wenn man als Decoder nvdec nutzt?

    Rein vom Bildeindruck konnte ich jetzt selbst auf meinem großen 75"-Sony-TV nichts erkennen. Also ich bin erstmal damit zufrieden. ;)

    jojo61

    ich habe mal die Tests mit cat /sys/class/vfm/map gemacht, aber da gibt es keine Unterschiede in den Ausgaben von VDR nach Neustart (Bild i.O.) oder dem VDR nach KODI (Bild schlecht).

    Ich habe dann auch noch einen Test gemacht, wo ich in KODI ein Video mit h.264 gespielt habe und da ist ja nach der Rückkehr zum VDR das Bild i.O. und da ist die Ausgabe auf der Konsole genau dieselbe.


    cat /sys/class/vfm/map nach einem Neustart des VDR [ Bild i.O. ] :


    cat /sys/class/vfm/map nach zurückswitchen von KODI zum VDR, wenn vorher in KODI ein Video mit VC-1 gelaufen ist [ Bild schlecht ]:


    Hier nochmals zum Vergleichendie Ausgaben von cat /sys/class/vfm/map jeweils VDR-Neustart, Switchen zu KODI, nach Abspielen von Video mit VC-1 und nach dem Zurückswitchen zum VDR.

    Nach dem Neustart des VDR [Bild gut] : 01_sys.class.vfm.map_vdr-neustart.txt

    Umschalten vom VDR zu KODI: 02_sys.class.vfm.map_kodi-vor-vc1.txt

    In KODI nach dem Abspielen eines Video mit VC-1: 03_sys.class.vfm.map_kodi-nach-vc1.txt

    Zurückswitchen zum VDR [Bild schlecht] : 04_sys.class.vfm.map_vdr-nach-kodi-vc1.txt