Beiträge von buers

    Habe mir nochmals die SRF-Streams angesehen. Habe alle ohne Audio-Deskription probiert, alle liefern Fehler hier. Scheint kein Geo-Lock. Der Stream liegt als HTTP-Live-Stream (HLS) segmentiert vor. Einzelne Segmente laden hier nicht - http-Fehler 404. Ist das bei euch auch so? Wer klein bisschen mit der Kommandozeile umgehen kann und ffmpeg installiert hat, mag mal probieren mit deutscher IP oder insbesondere auch wer mit Schweizer IP (ich habe nur deutsche IP getestet).

    Code
    ffmpeg -i "https://srf-vod-amd.akamaized.net/ch/hls/film/2025/03/film_20250306_013920_10268038_v_webcast_h264_,q40,q10,q20,q30,q50,q60,.mp4.csmil/index-f6-v1-a1.m3u8" -map 0 -c copy "Ostfrieslandkrimis (2017) S01E01 Ostfriesenkiller.mp4"

    Sollte gleichermaßen auf Windows/Linux/MacOS funktionieren.

    Ich denke, alle UHD Inhalte des ZDF sind in HEVC kodiert. Bei "Der Schwarm" war es auch so. ffprobe sagt: "Video: hevc (Main 10) (hvc1 / 0x31637668), yuv420p10le(tv, bt2020nc/bt2020/arib-std-b67), 3840x2160 [SAR 1:1 DAR 16:9], 4216 kb/s, 50 fps, 50 tbr, 1k tbn (default)"

    Interessante Seite zu UHD-Inhalten des ZDF: https://www.zdf.de/ultra-high-definition

    "Früher" waren die UHD-Streams allerdings versteckt - man musste die URL manipulieren. Ich denke nach einer Diskussion mit rols1 vor einer ganze Weile hatte er das in seinem Addon implementiert. Ob man die immer noch manipulieren muss, habe ich jetzt nicht gecheckt. In Mediathekview scheinen sie jedenfalls nicht drin. yt-dlp scheint sie allerdings zu detektieren.

    Nun will ich sie mir auch ansehen. Falls noch jemand Interesse hat: folgende Kommandos laden die einfach zu findenden Episoden runter, jeweils beste Qualität bei ZDF und Arte. SRF ginge auch mit ffmpeg, lief bei mir aber jeweils auf Übertragungsfehler.

    Einfach Befehle selektieren und auf Konsole kopieren - sollte unverändert unter Windows, Linux und MacOS funktionieren. Namen sind Kodi-freundlich (und auch Menschen-freundlich) gewählt. Wer kein curl hat aber wget kann curl -o ersetzen durch wget -O. Es wird automatisch ein Unterverzeichnis erstellt. Ohne Fehler-Behandlung.


    S01E8/9/10 fehlen leider. Das Kommando ist trotzdem noch drin, falls jemand die URL findet und sie nachtragen will. Stört ansonsten nicht, wenn nix runterlädt.

    EDIT: Die Namen beziehen sich auf tvdb als Scraper. Dort heißen die Krimis "Ostfrieslandkrimis" wie in Wikipedia auch. Auf tmdb und imdb heißen sie offenbar "Ostfriesenkrimis". Ob auch Aliase für den jeweils anderen Namen vorhanden sind, habe ich nicht geprüft. Ggf. muss man, wenn man nicht tvdb als Scraper nutzt, entsprechend umbenennen.

    Da, wo in der Spalte "Größe [MB]" Werte von ca 1000 stehen, ist die maximale Auflösung 720p. Steht da etwas um die 1800, ist es 1080p.

    Mediathekview zeigt bei der Größe stets die Größe der mittleren Auflösung an (zumindest bei mir). Damit steht in der Spalte bei den ZDF-Downloads stets ca 1800 MB, unabhängig davon, ob der jetzt auch in Full-HD vorliegt oder nicht. Siehe z.B. mein Screenshot in #7. Die Full-HD Version hat ca. 3500 MB.

    Arte DVB-T2 Aufnahmen haben nach meiner Einschätzung bessere Qualität als Mediathek-Downloads von Arte. Mag sein, dass alles hochskaliert ist. Laut dem Wikipedia-Artikel, den ich zitiert hatte, ist es nicht ganz klar. Scheint auch nicht so leicht eine klare Aussage dazu zu finden. Was durchaus für hochskaliert sprechen mag. Hatte da auch mehrfach widersprüchliches gelesen - mal heißt es, dass es praktisch keine modernen Produktionen in 720p mehr gibt, und alles mindestens 1080p produziert wird. Mal liest man es grade andersrum, bzgl. deutscher ÖR Sender.

    Bei Arte gibt es nur 720p, kein 1080p.

    Ja, da hatte ich mich in meiner Aussage getäuscht, sorry.

    Weder in der Mediathek noch im linearen TV.

    Wie erwähnt, sendet ARTE auf DVB-T2 in 1080p. Über hochskaliert oder nicht hatte ich mich ausgelassen.

    Hat jetzt mit den Ostriesenkrimis nix mehr zu tun, aber bei ARTE gibt es über andere Wege auch (wenige) UHD-Inhalte: https://www.arte.tv/de/videos/RC-0…-uhd-qualitaet/ Die sind allerdings nicht so einfach runterzuladen. Mit Kommandozeile z.B.:

    Code
    ffmpeg -i https://arte-uhd-cmafhls.akamaized.net/corner_uhd/117000/117100/117154-000-B/2025042916337EFDBF30A6701453CCE9E81A2F14A1/medias/117154-000-B_v2160.m3u8 -i https://arte-uhd-cmafhls.akamaized.net/corner_uhd/117000/117100/117154-000-B/2025042916337EFDBF30A6701453CCE9E81A2F14A1/medias/117154-000-B_aud_VOA-ALL_2.m3u8 -map 0:v -map 1:a -c copy "Mit dem Zug durch Taiwan (2024).mp4"

    Bobbi2021 - Als ich anfing, meinen Beitrag zu schreiben, stand dein Beitrag noch, sonst hätte ich es nicht erwähnt. (Dauerte bisschen, bis ich mit meinem Beitrag fertig war mit all dem code, kurz getestet und auch nicht dran geblieben).

    ich bezog mich auf die MediathekViewWeb-Suche im ARDundZDF-Addon und die Quellen, die https://mediathekviewweb.de/api/query zurückliefert.

    Ich will mich da nicht kabbeln, kann allerdings die Aussage nicht nachvollziehen, die ja ursprünglich lautete "Full-HD-Auflösungen habe ich, glaube ich, bei MediathekView noch nicht gesehen." Nutze ich die API, die du angegeben hast, mit curl (sorry, wenn da die Zeilenumbrüche nicht richtig dargestellt werden):

    Code
    curl      -v      -XPOST https://mediathekviewweb.de/api/query      -H'Content-Type: text/plain'      -d'
    {
      "queries" : [
         {"fields" : ["title"], "query" : "Ostfriesenmoor"}
      ]
    }' | jq

    erhalte ich als Ergebnis auch eine Full-HD-Auflösung. Hier ist URL:

    Code
    "url_video_hd": "https://nrodlzdf-a.akamaihd.net/none/zdf/23/02/230204_2015_sendung_oki/3/230204_2015_sendung_ok
    i_a1a2_6660k_p37v17.mp4"

    Komplette Antwort war

    Laut ffprobe " Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709, progressive), 1920x1080 [SAR 1:1 DAR 16:9], 5090 kb/s, 50 fps, 50 tbr, 1k tbn (default)". Das ist Full-HD. Vielleicht missverstehe ich dich weiterhin, rols1. Oder bist du evt. mit UHD durcheinander gekommen? Dazu hatten wir auch schon mal vor einer Weile eine Diskussion. Siehe auch Kommentar ganz am Ende.

    Bobbi2021, deine Aussage in #3 hatte ich wahrgenommen, und nicht an ihr gezweifelt - im Ggt. das selbst stichprobenhaft verifiziert. In der Tat sind da manche nicht in Full-HD vorhanden, was nach meiner Erfahrung eher ungewöhnlich ist bei den Mediathek-Inhalten von ARTE oder ZDF oder vielen anderen ÖR-Sendern. Hatte kürzlich auch mehrere Skripte hier gepostet, die ganze Serien herunterladen, war jeweils 1080p. Die URLs hatte ich "ohne Tricks" ermittelt (manchmal sind UHD-Downloads möglich, da fand ich die URLs nicht so einfach).

    Full-HD-Auflösungen habe ich, glaube ich, bei MediathekView noch nicht gesehen.

    Vielleicht missverstehe ich, wie du das meinst, aber bei mir wurden in den letzten Jahren die meisten Sendungen, die mich interessierten in Full-HD angeboten. Zum Thema hier z.B.:

    Die URL lautet

    Code
    https://nrodlzdf-a.akamaihd.net/none/zdf/23/02/230204_2015_sendung_oki/3/230204_2015_sendung_oki_a1a2_6660k_p37v17.mp4

    . Die heruntergeladene Datei hat auch wirklich 1920x1080 Auflösung.

    Unabhängig davon, ob der Sender 720p ausstrahlt auf ASTRA, haben nach meiner Erfahrung und Einschätzung die Downloads mit Full-HD die beste Qualität. Die kommt meines Erachtens dennoch nicht an die Qualität von Astra in 720p heran. Datenmenge ist auch viel geringer.

    Auch gar keine Ahnung, ob ARTE ueber ASTRA 1080p sendet.

    Über Astra nicht, über DVB-T2 schon. Ob die 1080p in DVB-T2 jetzt aus 720p hochgerechnet sind, oder nativ, scheint von Sender und Sendung abzuhängen. Wikipedia sagt:

    "Stand 2022 werden im Ersten und den Dritten viele Sendungen ohne eine Hochskalierung von nativen 1080p50 HD-Quellen gesendet, beim ZDF beschränkt man sich dabei noch hauptsächlich auf eigene fiktionale Programme und wenige Studioproduktionen, lizenzierte fiktionale Programme werden beim ZDF nach wie vor nur hochskaliert." DVB-T2 HD in Deutschland – Wikipedia Man kann spekulieren, dass Ähnliches für die Mediatheken gilt. Was leider für die Mediatheken grundsätzlich gilt, ist dass es keinen 5.1 Ton gibt, auch wenn auf den anderen Übertragungswegen 5.1 Ton vorhanden ist.

    So ist es korrekt. Das meinte ich mit dem Missverständnis. Hier muss bei uns zur Zeit CEST stehen. Die Aussage, dass "Linux Systemzeit UTC sein soll" hattest du missverstanden. Es sollte normalerweise (bei typischen Home-Systemen) die korrekte lokale Zeitzone konfiguriert sein. Wie ich (offenbar erfolglos) versucht hatte zu erläutern, widerspricht das nicht der Aussage, dass die "Systemzeit" UTC ist.

    Mit den regel-basierten Timern kenne ich mich nicht aus. Ansonsten sollte dein Linux-System auf die korrekte lokale Zeitzone konfiguriert sein. Wie ich versucht hatte zu erläutern, läuft die interne Uhr oder die System-Uhr oder die BIOS Uhr normalerweise dennoch in UTC. Kann dir aber grundsätzlich egal sein. TVH zeigt dir dann alles in lokaler Zeit an (kommuniziert aber im Hintergrund dennoch mit UTC).

    Die EIT-Zeitzonen-Differenz aus dem Screenshot sollte auf UTC stehen in tvh (das ist auch Default so). Das hast du schon richtig verstanden, das ist nur, wenn Zeitangaben für EPG (durch EIT = Event Information Table oder durch xmltv oder auch andere Quellen) fehlerhaft sind. Ich habe das bei uns noch nicht gesehen (ASTRA, DVB-T2, DVB-C).
    EDIT: Was ist denn die Ausgabe von date auf der Linux Konsole?

    Unter Linux ist eigentlich vorgesehen, dass die Systemzeit auf UTC eingestellt ist.

    Möglicherweise liegt hier das Missverständnis. In der Tat ist das so, dass beispielsweise auf traditioneller PC-Hardware die Systemuhr (das ist die Uhr, die unabhängig und außerhalb vom Betriebssystem läuft) normalerweise in UTC läuft. Das Linux-Betriebssystem selbst nutzt intern auch UTC, für die Darstellung den Benutzter gegenüber und für Benutzereingaben wird dennoch lokale Zeit genutzt. Das date Kommando sollte dementsprechend auch die lokale Zeit ausgeben (und auch die Zeitzone).

    EPG-Informationen, die tvheadend verarbeitet, liegen normalerweise in der Tat auch in UTC vor. Im xmltv-Format stehen Zeitstempel in UTC zusammen mit einer Zeitdifferenz zu UTC (z.B. bei uns zur Zeit +2 h). Unabhängig von der lokalen Zeitzone, kann tvh diese intern als UTC verarbeiten, aber dir gegenüber halt wieder in lokaler Zeit anzeigen. Das stimmt dann auch für einen Fernsehsender aus Großbritannien, der eigentlich eine andere Zeitdifferenz zu UTC hat, als ein deutscher Fernsehsender.

    ntpd ist bei vielen Distribution schon lange durch Alternativen (chrony, systemd-timesyncd o.ä.) ersetzt worden.

    EDIT OOmatrixOO - mögliche Lösung (falls noch benötigt) ganz unten.

    Ok, das erklärt es dann. Ich war halt wegen deiner Aussage zu den 1000 Sekunden verwundert - ist ja bei uns immer überschritten bei "normalem" WIndows-Linux-Multiboot.

    Ich hatte vor längerer Zeit schon Mal die Logs in Windows und Linux genau geprüft, Zeitkorrektur war immer schnell nach "Fremd-Boot".

    Klar, programmierte Real-Time-Clock (RTC) Events, die den Rechner starten sollen (nicht aufwecken aus S3 oder S4) machen in Multi-Boot Probleme. In Hacker-/Nerds-Konfig kriegt man das aber auch pragmatisch in den Griff. Man wird RTC nutzen in einem "Hauptsystem", das man eh öfters nutzt und das per Default ohne weitere Interaktion bootet. Wenn man fremd bootet, muss man noch einen Leer-Boot/Shutdown (z.B. durch Skript) im Hauptsystem machen. (Oder man verzichtet auf Timer im S5 und stellt auf S4 um, was auch praktisch kaum Energie braucht). Ich fürchte allerdings, dass all die Erkenntnis dem OP nicht wirklich hilft. EDIT - mir fällt grade ein, dass RTC Wakeups vermutlich nicht funktionieren in Windows.

    Ja, bei nicht vernetzten Geräten hat man ein Problem. Denke mir (Spekulation) dass das halt in Windows für immer von (nicht vernetztem) DOS geerbt wurde und dem alten BIOS Time Interrupt. Was Windows früh aus der BIOS-Zeit machen wird, ist einen UTC-basierten Timer zu initialisieren (vermutlich den 100ns Timer, der auf 1601-01-01 00:00:00 UTC beruht - sehr viele Windows APIs nutzen diesen Zeitstempel).

    Ich frage mich, wieso die BIOS-Zeit (die ja nicht eindeutig bzgl. Zeitzone zu identifizieren ist) nicht durch was moderneres ergänzt wurde, das keinen Interpretations-Spielraum zulässt und von den OS zur Bootzeit genutzt werden kann. BIOS hat sich ja ansonsten auch weiterentwickelt. Damit sollte auch "täglich um 8:00 lokaler Zeit wecken" funktionieren.

    Wenn ich dran denke, versuche ich mal ein RTC Wakeup in Linux direkt nach Ende der Sommerzeit. Bin zuversichtlich, dass das korrekt funktioniert. Vielleicht muss ich bisschen üben, mit den rtcwake Optionen.

    OOmatrixOO , nach all der Diskussion könnte folgendes für dich funktionieren: BIOS Zeit auf UTC umstellen. AUfwecktimer im BIOS löschen, auf OS-Ebene das rtcwake Kommando nehmen, um Booten zu programmieren wenn es nächstes Mal 08:00 ist. rtcwake -m off ... könnte zum Testen hilfreich sein. Skripting mit Zeit/Datum ist nicht ganz trivial. Kann die bei Interesse und Bedarf sicherlich auch bei geholfen werden.

    Ein wichtiger und schwerwiegender Hinderungsgrund für zügige Digitalisierung in Deutschland ist auch der Föderalismus. Gerade im Bildungswesen und insbesondere bei den Universitäten merkt man das, wenn beispielsweise Studierende die Uni wechseln. Die ganzen Daten z.B. zu Scheinen müssen analog übertragen/angeglichen werden. Selbst einfachste und selbstverständliche Dinge wie Video-Konferenzen können komplexer sein als nötig. Die verschiedenen Bundesländer setzen auf unterschiedliche Systeme (u.a. wegen unterschiedlicher Sicherheits-Abwägungen).

    Auch bei Justiz, Landesverwaltungen, ... setzt jede auf ihre SW. Durchaus interessante Projekte, auf Open Source zu setzen, z.B. Big Blue Button und Matrix, werden wohl für unabsehbare Zeit Landes-spezifisch bleiben.

    Bei Firmen-Fusionen ist die Angleichung/Integration/Migration der IT oft ein äußerst komplexer Prozess. Dort gibt es aber eine treibende Kraft, die im öffentlichen Sektor fehlt.

    Das Vergaberecht (Ausschreibungen) mag da auch noch mitspielen - ist zwar nix Deutschland-spezifisches, kann aber nach meiner Einschätzung die Unterschiedlichkeit der IT in föderalen Strukturen verstärken.

    Manchmal kaschiert ein erreichbarer NTP Server die doppelte Verstellung durch Dual-Boot, aber oft geht das auch schief. Beispiel ntpd: Zeitserver die mehr als 1000 Sekunden von der eigenen Uhrzeit abweichen werden als ungültige Zeitquelle deklariert und verworfen.

    Interessant. Ich habe das seit gefühlt Jahrzehnten nicht mehr gesehen auf einigen Dual-Boot-Installationen bei mir, dass Zeit Probleme macht. Wie du schreibst, korrigieren Zeitserver das für Nutzer praktisch unmerklich. Ich meinte immer das ginge über ntp/ntpd. Hatte dabei Suse, Redhat, fedora, ubuntu und vermutlich mehr Varianten, die alle keine Probleme machten bei Multi-Boot mit verschiedenen Versionen von Windows über die Jahre.

    und zum Anderen ist der UTC "Quatsch" für einen lokalen Computer einfach Unsinn.

    Da habe ich ein Deja Vu - noch einmal weise ich drauf hin: praktisch alle wichtigen Zeitfunktionen laufen über UTC-parallele Zeit - und das ist auch wichtig und richtig so. Auch lokale Computer kommunizieren international. Datumsstempel von Dateien in allen modernen Dateisystemen sind selbstverständlich UTC basiert (werden aber für die Darstellung an den Enduser auf lokale Zeit umgerechnet). Bei Windows auf Terminal-Servern oder sogenannten VDIs ist es üblich dass User aus verschiedenen Zeitzonen sich anmelden, und das als Desktop nutzen. Für die Anzeige wird die Zeit umgerechnet. Normale POSIX-normierte Funktionen basieren auf UTC, genauso wie die wichtigsten Zeitfunktionen in Programmiersprachen, die ich kenne (z.B. time()). Code, der mit lokaler Zeit arbeitet hat oft (subtile) Bugs. Es gibt eine Stunde im Jahr, die mit lokalen Zeitstempel zweimal vorkommt und der lokale Zeitstempel kann keine eindeutige Zeit definieren. Transaktionen mit DBs, viele APIs, praktisch alles UTC basiert. Zeitdifferenzen von lokalen Zeitstempeln sind schwer zu berechnen ohne Umrechnung auf "globale Zeit" (und die ist bei DST-Umstellung wie genannt nicht immer eindeutig).

    Auch im Nerds-Universum sind beispielsweise EPG UTC basiert.

    Aber jetzt gewähre ich dir wieder das letzte Wort ...

    [...] auf einer Skala von 0 bis 10?

    Geht auch 11?

    Erinnert mich an die wahre Geschichte, vielleicht Ende 1990er oder Anfang 2000er Jahre. Tour de France Teilnehmer Erik Zabel wurde gegen Schluss der Rundfahrt gefragt, wie es ihm gehe. "Auf einer Skala von 1 bis 10 fühle ich mich wie 'ne 0."

    Ich hatte parallel zu deiner Nachfrage meinen Beitrag ergänzt unter dem Screenshot. Möglicherweise hast du das nicht gelesen - sollte deine Frage beantworten. Nach meiner Erfahrung muss bei Shared Folder (bzw. deutsch "Netzwerkfreigabe") was eingetragen werden, und zwar schon immer.

    Möglicherweise heißt bei dir der richtige Eintrag "Toshiba_EXT".

    Nein, ich meinte Screenshot 9 nach Forums-Zählung:

    Ich habe keine Fritzbox, deswegen weiß ich nicht, wie dort die Freigabe = Shared Folder per Default genannt wird, bzw. mit welchem Namen das explizit konfiguriert wurde. Möglicherweise FRITZ.NAS. Jedenfalls ist das kein kompletter Pfad, sondern ein Name einzutragen ohne Slashes und Backslashes.

    Ich finde, die von Dir angehängte Bilddatei kommt prima auf den Bildschirm,

    Ja, ist in der Darstellungskette eindeutig durchgängig 4k. Auf meinem 4k Computer-Monitor mit Kodi auf Windows-PC sind die grünen vertikalen Linien noch etwas schärfer. Meine Android-TV Boxen zeigen leider die mittleren 10 Linien jeweils als einen Balken (was auf zwischendurch Full HD Bearbeitung hinweist). Habe das identische Bild auch als kurzes 4k Video - das wiederum wird korrekt am TV mit den identischen Boxen dargestellt, und auch dort Grün etwas mehr ins Weiß verlaufend ganz ähnlich wie bei dir. Denke, das liegt an den Bildschirmen. Dass Fotos in Kodi zwischendurch mal schlechter skaliert werden, und deswegen halt unschärfer als nötig dargestellt werden, kommt nicht nur bei mir vor. Haben hier und im Kodi.tv-Forum auch andere berichtet.

    Will da nicht zu sehr von deinem Thema abschweifen - ist aber immerhin eine erwähnenswerte Eigenschaft der hier diskutierten Box. Nur als Vergleich mein Computer-Monitor (jetzt mit Smartphone fotografiert, oben war Screenshot):

    Und TV, hier läuft Kodi direkt auf dem TV, aber in anderen Konstellationen (außer mit PC als Zuspieler) sieht es auch nicht anders aus. Wie gesagt, das entsprechende Video stimmt wieder:

    Danke für die Antworten.

    Überrascht mich in der Tat, dass hier eine Widevine-Zertifizierung vorliegt. Werde da bei Gelegenheit selbst mal bisschen genauer nachlesen, was AOSP = Android Open Source Project bedeutet. Ich hätte erwartet, dass da das gesamte Betriebssystem (seitens Google) dem Box-Hersteller im Quelltext vorliegt. Und für die Zertifizierung hätte ich notwendige Geheimniskrämerei erwartet. Abgesehen davon sollte doch derjenige, der Kontrolle über das gesamte OS im Quelltext hat auch direkten Zugriff auf Videospeicher haben (nachdem alles Übertragene entschlüsselt ist). Wundert mich, dass das der Zertifizierung nicht entgegensteht.

    ASOP war einer der Hauptgründe

    Nehme an, du meinst AOSP. Oder sitze ich hier total auf der Leitung? Ansonsten finde ich persönlich auch gerade diesen Aspekt reizvoll.

    Ja, das mit 32bit stimmt [...] Trotzdem ist die Box das Schnellste was ich bisher erlebt habe.

    Daran zweifle ich keinesfalls. Hatte hier auch schon in ähnlichen Diskussionen beschrieben, wieso 32 bit schneller sein kann und manchmal ist. Bei der Box gibt es aber einen gewaltigen Unterschied, zu den anderen, die ich hier im Forum bislang diskutiert sah: 8 GB RAM. Wieso zum Teufel sollte ein Hersteller 8 GB RAM einbauen, wenn nur 4 GB adressiert werden können? Oder gibt es da vielleicht einen zweiten Memorypool, der meinetwegen für Video-RAM genutzt werden kann? Output des free-Kommandos (Spoiler in meinem vorigen Beitrag) wäre evt. schon noch interessant.

    Google liefert anscheinend Android/Google-TV bloss als 32-bit Version aus.

    Schon gut möglich, aber hier geht es doch um AOSP - hattest du das wahrgenommen? Hätte erwartet, dass AOSP als 32bit wie als 64bit übersetzt werden kann. So wie auch Kodi aus dem identischen Repository halt auch für verschiedene OS und auch für verschiedene Bitness übersetzt werden kann (und auch meine Programme ...). Sicherlich wird man neben den Quellen des OS auch Treiber benötigen, die Hersteller-spezifisch sind. Aber die sollte doch der Hersteller auch im Griff haben und als Quellen im Zugriff und bei vernünftiger moderner Programmierung würde ich da auch erwarten dass die Treiber 64 bit fähig sind.

    Fotos 4k ja.

    Um ganz sicher zu sein, kannst du mal angehängte gezippte jpeg Datei testen? Da sollte man pro Farbe zwölf eindeutig getrennte Linien sehen (und nicht verwaschen - Farbe, weiß doppelt dick, Farbe, weiß, Farbe, weiß, ...). Haben wirklich viele Kodi-Boxen ein Problem mit (liegt nicht nur an den Boxen, sondern auch an der Programmierung von Kodi. Indikator war nach meiner Beobachtung oft nur ein Eintrag in der Whitelist). Hier ist ein vergrößerter Ausschnitt:

    Die Datei habe ich mal absichtlich zusätzlich gezippt, da sie sonst anscheinend durch die Forensoftware (für diesen Zweck) kaputt geht.

    Ah die alte Heimat, warst also auch mal ein Bodenseeler

    Habe in Konstanz studiert. Dabei auch in Kreuzlingen/CH gewohnt. Ist schon ne ganze Weile her - da konnte man im Winter hin und wieder noch von Allensbach zur Reichenau mit den Schlittschuhen laufen. Denke, die Gelegenheiten werden rar.

    Ich habe auch einen Denon AVR und ein Win11 Notebook. Das hängt normalerweise nicht am AVR (da nutze ich FireTV oder Magenta Box), habe aber mal interessehalber probiert, ob bei mir Ähnliches passiert. Habe auch im Gedächtnis, dass Kodi-Einstellungen zu Audio nicht immer selbsterklärend oder naheliegend sind und dass ich auch schon sowas gesehen hatte in der Vergangenheit - ein Tonformat geht, anderes nicht, abhängig von Audio-Einstellungen.

    Selbst habe ich keine selbst aufgenommenen Videos. Habe mal eine gerippte BluRay mit 7.1 und 5.1 DTS probiert, und auch TV-Aufnahmen mit AC3 (5.1) und mit einfachem Stereo. Ging jetzt alles bei der zweiten Einstellung die ich probierte: Passthrough (PT) an, als PT Gerät "HDMI - Denon AVR (3 HD Audio Driver for Display ...). Directsound Default hat auch alles abgespielt, aber nur Stereo-Ausgabe. Was man sieht an Auswahl hängt vermutlich von der PC-HW, installierten Treibern, evt. von Konfig auf dem PC ab. Hast du hier mal die verschiedenen Möglichkeiten durchpermutiert? Insbesondere mit und ohne PT? Und bei mit PT alle Auswahlmöglichkeiten probiert? Bei mir wird angeboten:

    Bei Ausgabegerät wird mir noch mehr angeboten. Es gibt auch zahlreiche widersprüchliche Empfehlungen, zu dem was man bei "Anzahl Audiokanäle" einstellen soll bei Nutzung von PT. Ich habe 5.1 eingestellt (was meiner Konfig entspricht). Oft liest man, man soll bei PT lieber 2.0 einstellen. Im Moment steht in der Beschreibung, dass diese Einstellung nix ausmacht - habe aber anderslautende Angaben gelesen.

    Auch Ausgabekonfiguration kann leider eine Rolle spielen. Ich habe "Optimiert" und Stereo Upmix aus. AC3 und DTS fähiger Receiver habe ich beides auf an.

    Wenn kein Ton kommt bei dir: hast du auch Mal das Lautsprecher-Symbol in der Tray-Area von Windows angeklickt? Hat sich dort vielleicht das Ausgabegerät verstellt oder die Lautstärke?

    Mit deinem Log kann ich nicht viel anfangen. Hilfreich könnte es sein, sekundengenau zu protokollieren, wann du was mit welcher Tonspur abgespielt hast, ob Ton kam oder nicht und wann du Einstellungen wie geändert hast. Befürchte aber, mir wird's nix nützen ... Vielleicht anderen, vielleicht sehen andere auch so schon gezielt, wo's klemmt.

    Noch ne Nebenbemerkung zu Infos im Log: In einfachen Konfigs sieht man normalerweise keine Passwörter. Man gibt leicht Privates von sich preis - naturgemäß sehen das verschiedene Forenteilnehmer unterschiedlich. Ich sah hier öfters private Email-Adressen, mutmaßliche Realnamen oder nur Vornamen, Wohnorte oder wo du halt Urlaub machst. Selbst gehe ich für mich mit sowas relativ locker um, aber andere mögen das nicht. Abhängig von installierten Addons kann noch mehr Info drin sehen wie private API-Schlüssel und auch Authentifizierungs-Informationen.

    EDIT: Noch eine Ergänzung. Wenn man mit den Audio-Einstellungen von Kodi rumspielt, scheint sich eine andere Einstellung normalerweise sofort auszuwirken. Hatte aber auch schon den Fall, dass nach Neustart von Kodi das Verhalten wieder anders war.