Ich dachte schon, das Problem gehört mit 14.2.x endlich der Vergangenheit an, aber mit 14.3 ist es jetzt wieder da. Gute Arbeit, Apple! Amazing!

Problem: wenn iTunes ein Musikvideo abspielen soll, startet Quicktime.
Wenn ich nichts tue, spielt das Video ganz normal. Sobald ich aber die Maus bewege, friert der Rechner komplett ein und reagiert auf nichts mehr. Ich muss ihn dann am Power-Button aus- und wieder einschalten.

Der Bug tauchte erstmalig mit Sonoma auf, was auch durch zahlreiche Einträge in den Apple-Foren bestätigt wird. Ich hatte dann alle Videos in iTunes deaktiviert, damit sie nicht zufällig abgespielt werden können.
Mit 14.2.x schien das Problem beseitigt; jedenfalls gab es da keine Probleme mehr als ich das mal getestet habe. Also habe ich meine Musikvideos wieder aktiviert. Heute wurde dann solch ein Video von iTunes random ausgewählt und fing an zu spielen, ich hatte zufällig die Maus bewegt – zack friert der Rechner sofort ein. Die Musik spielt weiter, das Video zeigt aber nur ein Standbild.

Nutzer haben schon vor Monaten den Fehler gemeldet, auch ich. Aber bei Apple scheint man sich entweder nicht zu interessieren oder die rechte Hand weiß nicht, was die linke tut.

Mac Studio Max
macOS 14.3

Mit VLC lassen sich die Videos problemlos abspielen, aber das kann man ja in iTunes nicht als Video.App auswählen.

Da hilft nur eines: Mehrjährige Haftstrafen ohne Bewährung, wenn Entwicklern Fehler nachgewiesen werden können.

Andere Berufsgruppen schaffen es ja auch, fehlerfrei zu arbeiten.

Sarkasmus????
Welche Berufsgruppe wäre(n) das?

Muss das bei meiner Aussage extra erwähnt werden? Ich verzweifle …

Wie kommst du darauf, das es ein Quicktime-Problem ist? Nur weil das Fenster des Videos aussieht wie früher das der QT-Player? Welches aktive Programm wird denn in der Menüleiste angezeigt?

VLC hat seine eigenen Engines, nutzt also weder "Core-Audio" noch "Core-Video", geschweige denn Quicktime...

Quicktime gibt es doch nicht mehr, oder? Es wurde doch mit MacOs 10.5 eingestellt.
Nur einige Programme verwenden noch Quicktime als Basis.

Läuft iTunes überhaupt auf Sonoma? Wenn das dein ernst ist, wäre das kein Wunder!

Mist, ich mache immer wieder den Fehler, das Ding immer noch iTunes zu nennen. Hat sich so ins Hirn gefressen.
Es ist natürlich die Musik.App.

Und wenn es nicht der QT-Player ist, was ist es dann, was die Videos abspielt?

Core Video.
Kommt wohl noch nicht mit allen Codecs und ihren Variationen zurecht.

Aber erst seit Sonoma, oder? Jedenfalls kenne ich diese Probleme aus der Zeit davor nicht.

Du verwechselst zwei Dinge, Quicktime und den QuickTime Player, der nicht das Allergeringste mit Quicktime zu tun hat. Die Namensverwandtschaft resultiert aus der Zeit, als Quicktime noch die Technologie war, mit der macOS Videos wiedergegeben hat. Quicktime war eine 32-Bit-Technologie, die als solche längst ausgedient hat und durch Core Video ersetzt wurde. Für die Abspiel-App behielt Apple aber den bei den Nutzern etablierten Namen QuickTime Player bei, auch wenn der natürlich längst Core Video verwendet, was seitdem immer wieder zu Verwirrung führt.

Dass da jetzt Dein Mac einfriert, ist natürlich ein Sonoma-Bug und hat nichts damit zu tun, dass Core Video, eine Technologie, die 2007 eingeführt wurde, bestimmte Codecs „noch nicht beherrscht”. Mit sowas hat man halt zu kämpfen, wenn man der Meinung ist, unbedingt die neueste macOS-Variante verwenden zu müssen. Ich kann davor nur immer wieder warnen: Wer mit seinem Mac arbeiten will, nutzt nicht die neueste macOS-Version, seit Apple diesen idiotischen Jahresrhythmus eingeführt hat.

Nein, kein Programm tut das mehr. Quicktime ist nämlich 32 Bit und würde daher auf keinem macOS nach 10.14 Mojave noch laufen.

Aha, danke für die Aufklärung.

Eigentlich bin ich vorsichtig mit Updates, aber auf der anderen Seite steht, dass Apple ja immer dringendst dazu rät, vor allem, wenn es sich um Sicherheitsupdates handelt. Außerdem hatte ich die Hoffnung, einige ärgerliche Bugs loszuwerden. Zumindest mit 14.3 und in Bezug auf InDesign hat das ja nun wohl auch geklappt.

Vom Jahresrhythmus gab es nur wenige Abwichungen (z.B. Übergang PPC zu Intel):
 10.0 („Cheetah“, 2001)
 10.1 („Puma“, 2001)
 10.2 „Jaguar“ (2002)
 Panther, 10.3 (2003)
 Tiger, 10.4 (2005)
 Leopard, 10.5 (2007)
 Snow Leopard, 10.6 (2009)
 Lion, 10.7 (2011)
 Mountain Lion, 10.8 (2012)
 Mavericks, 10.9 (2013)
 Yosemite, 10.10 (2014)
 El Capitan, 10.11 (2015)
 Sierra, 10.12 (2016)
 High Sierra, 10.13 (2017)
 Mojave, 10.14 (2018)
 Catalina, 10.15 (2019)
 Big Sur, 11 (2020)
 Monterey, 12 (2021)
 Ventura, 13 (2022)
 Sonoma, 14 (2023)

Unter welchen Umständen tritt das Phänomen denn auf?
Wenn der Fokus auf dem Videofenster liegt oder wenn der Fokus auf dem Desktop oder dem Fenster eines anderen Programms liegt oder unter all den genannten Umständen?

Natürlich rät Apple dringendst dazu – sie brauchen ja genügend Betatester für ihre halbfertigen Release-Versionen.

Sicherheitsrelevante Updates gibt es ja auch für die beiden Vorversionen. Davon mal abgesehen: an wie viele Forums-Hilferufe kannst Du dich erinnern wegen

• Problemen aufgrund eines unterlassenen Sicherheitsupdates
• Problemen aufgrund eines Bugs in der aktuellen macOS-Version

Eben.

Das stimmt nicht. Einen erklärten Jahresrhythmus gab es erstmals mit Mountain Lion 2012, also etwa zur Halbzeit der Existenz des modernen macOS (Mac OS X).

Die hektische Veröffentlichungsreihenfolge von 2001 bis 2003 (4 Versionen in 2 Jahren) gehorchte überhaupt keinem Rhythmus, sondern verdankte sich einzig der Tatsache, dass Mac OS X noch sehr unfertig war und Verbesserungen schnellstmöglich auf den Markt mussten. 2003 war mit Panther erstmals ein einigermaßen vollständiges System vorhanden und ab da pendelte sich der Veröffentlichungsrhythmus inoffiziell (verkündet wurde er nie) auf etwa 2 Jahre ein bis einschließlich Lion 2011. Ab da erfolgte erklärtermaßen die Umstellung auf einen Jahresrhythmus mit dem Veröffentlichungsdatum im Herbst.

Und mit der Tatsache, dass ein Jahresrhythmus „idiotisch“ ist, d.h. etwas weniger flapsig formuliert einer soliden Weiterentwicklung des OS alles andere als gut tut, hat das sowieso nichts zu tun.

Wenn ich z. B. in irgend einem Programm arbeite und im Hintergrund Musik läuft und die Musik.App zufällig ein Video auswählt, schiebt sich das Videofenster automatisch in den Vordergrund. Wenn ich dann die Maus bewege, friert der Rechner komplett ein. Eingaben, egal mit was, sind dann nicht mehr möglich.

Die Einstellung, dass Video in den Vordergrund kommt, kann man abwählen, wenn ich mich recht erinnere…

Nennt sich "Videowiedergabe immer im Vordergrund halten" und ist bei mir aber deaktiviert.

Dein Rechner "friert nicht komplett ein", denn wie Du weiter oben geschrieben hast, spielt die Musik ja weiter und auch andere Prozesse müssen weiter laufen. Wie ist Deine Maus und Deine Tastatur angeschlossen? Per Bluetooth oder per USB? Falls per USB würde es sich auf jeden Fall lohnen, das USB-Kabel der Maus/Tastatur abzuziehen und wieder einzustecken. Mit der Tastatur lohnt sich auch der Versuch mit Apfel-Tab zu versuchen, zu einer anderen Anwendung zu wechseln. So läßt sich die Ursache etwas eingrenzen.

Naja, das ist das klassische Nadelöhr Windowserver. Auf der visuellen GUI-Ebene funktioniert nichts mehr, alles darunter läuft munter weiter. In der Regel ist eine kurzfristige Überlastung der GPU der Auslöser für so eine Windowserverblockade, insofern ist ein Bug im Video-Subsystem als Verursacher sehr stimmig. Beheben lässt sich das nur durch ein Killen des Windowserverprozesses und damit wird man aus seinem Nutzerkonto, in das man über die GUI eingeloggt ist, automatisch ausgeloggt (Logins auf Terminal-Ebene sind davon nicht betroffen). Zu retten ist da also nichts und ohne ssh-Zugang zum Rechner bleibt auch nur ein erzwungener Neustart.

Vielleicht sollte ich noch kurz erklären, was es damit auf sich hat.

In dem modernen, auf Unix und NEXTSTEP basierenden macOS sind die einzelnen Prozesse bekanntlich sehr gut voneinander isoliert. Wenn ein Prozess crasht, führt das in aller Regel lediglich zur Fehlfunktion der Aufgabe, mit der er betraut war, während der Rest von macOS völlig unbehelligt weiterläuft.

Aber es gibt zwei wichtige Ausnahmen:

Die eine ist der Kernel, der Betriebssystemkern, der die elementarsten Aufgaben des Betriebssystems ausführt und ohne den im wörtlichen Sinne gar nichts geht: Crasht der Kernel, startet der Mac urplötzlich neu, hängt der Kernel, regiert der Mac auf keiner Ebene mehr und muss zwangsneugestartet werden. Glücklicherweise ist der macOS-Kernel im Großen und Ganzen stabil (stabiler als der Rest jedenfalls) und Probleme gibt es nur selten.

Und die zweite Ausnahme ist eben der Windowserver. Das ist der Prozess, der für die visuelle Ausgabe der GUI zuständig ist, genauer gesagt, der sie koordiniert. Für die spezifische visuelle Ausgabe eines Programms ist natürlich das jeweilige Programm zuständig, aber es muss eine übergeordnete Instanz geben, die für die Programme Teilbereiche des Bildschirms zur Ausgabe freigibt oder eben auch nicht, denn es kann ja faktisch immer nur ein Programm eine ganz bestimmte Stelle des Bildschirm beschreiben, in aller Regel dasjenige, das an dieser Stelle ein Fenster im Vordergrund hat.

Bei der Audioausgabe ist das anders – es hört sich zwar dann meist schrecklich an, aber technisch ist es natürlich kein Problem, die Tonausgaben verschiedener Programme einfach zu überlagern und gleichzeitig wiederzugeben. Deshalb gibt es keinen „Audioserver“, der die Tonausgaben der Programme koordiniert, jedenfalls nicht technisch zwingend (es gibt einige Zusatzprogramme für macOS, die sowas optional machen und quasi als Mischpult für die Audioausgabe verschiedener Programme dienen).

Aber bei Video ist eine Koordination zwingend erforderlich – im Extremfall sieht man durch Transparenzeffekte noch das Fenster darunter durchscheinen, aber es muss prinzipiell für jede Stelle des Bildschirms klar sein, welches Fenster „oben ist“, d.h. welches Programm den Bildschirm beschreiben darf. Und das macht eben der Windowserver.

Das heißt, alle Programme müssen ihre visuelle Ausgabe „durch den Windowserver hindurch“ auf den Bildschirm ausgeben, der seinerseits keinem dieser Programme zugeordnet, sondern ihnen vorgeordnet ist. Deshalb ergibt es auch keinen Sinn, in einem bestimmten Programm den „Schuldigen“ zu suchen, durch dessen Neustart man Probleme mit dem Windowserver beheben könnte. Es kann zwar in dem Sinne einen „Schuldigen“ geben (oftmals einen Grafiktreiber), dass er den Windowserver durcheinander bringt; ist das aber einmal geschehen, spielt dieser „Schuldige“ keinerlei Rolle mehr; der Zustand lässt sich nur durch Killen des Windowserver-Prozesses beheben, und das bewirkt wiederum eine Zwangsabmeldung des Nutzers. Eine andere Lösung gibt es prinzipiell nicht.

Der Windowserver ist also die zweite Ausnahme, die das gesamte System (zumindest alles auf der Ebene eines grafisch eingeloggten Nutzers) in die Funktionsunfähigkeit führen kann. Crasht der Windowserver, findet man sich urplötzlich am Login wieder; hängt der Windowserver, geht visuell nichts mehr, obwohl auf allen anderen Ebenen alles unbehelligt weiterläuft. Dabei gibt es zwei typische Varianten:

• alles, einschließlich der Menüleistenuhr, ist eingefroren, aber der Mauszeiger lässt sich noch bewegen; klickt man mit der Maus irgendwohin, springt der Mauszeiger wild an eine völlig andere Bildschirmstelle
• wie oben, doch selbst die Maus bewegt sich nicht mehr

Hat man einen ssh-Zugang zum Mac, kann man den Windowserver killen, aber das bewirkt wie gesagt eine Zwangsabmeldung des angemeldeten Nutzers; sämtliche ungesicherten Daten in GUI-Programmen gehen verloren. Da ist es auch nicht viel schlimmer, wenn man den Mac gleich zwangsausschaltet.
Das alles ergibt wie gesagt keinen Sinn, denn das funktioniert ja alles und ist nur nicht sichtbar, da der Windowserver eingefroren ist.
Du hast eine völlig falsche Vorstellung von den Zeiträumen, um die es hier geht. Wenn Apple einem Bug hohe Priorität einräumt, kann man davon ausgehen, dass er innerhalb der nächsten beiden Betriebssystem-Versionen, also innerhalb der nächste beiden Jahre, gefixt wird, mit extrem viel Glück sogar noch in Sonoma. Aber ein paar verstrichene Monate bedeuten gar nichts.

Das macOS-Software-Team bei Apple ist zeitlich völlig unter Wasser. Bedankt Euch bei Tim Cook.

Das klingt für mich plausibel und verständlich. Danke.

Ja, die Probleme Apples, Bugs anzugehen, sind bekannt. Erst vor mehreren Wochen hatten sich ja Apples Entwickler beschwert, man räume ihnen zu wenig Zeit für die Behebung von Fehlern ein.

Mag sein, dass es für Dich keinen Sinn ergibt, weil für Dich festzustehen scheint, daß der Windowserver eingefroren ist. Ich halte das auch für sehr wahrscheinlich, aber nicht für zwingend gegeben.

Ich habe mich vage erinnert, dass ich einmal einen Fall hatte, wo der Windowserver durch Killen eines „Schuldigen“ doch wieder zum „Leben erweckt“ werden konnte und somit ohne Datenverlust weitergearbeitet werden konnte.
Also, wenn Du die Möglichkeit hast, auf Deinen Mac via ssh zuzugreifen (von einem zweiten Mac, einem iPad oder iPhone aus), könntest Du mal Folgendes probieren, wenn alles eingefroren ist:

In den Mac via ssh als Nutzer mit Administrator-Rechten einloggen, dann
Das listet Dir die 10 Prozesse auf, die am meisten CPU-Last verbrauchen.
Wenn Du Glück hast, findest Du einen Prozess, der 100% oder fast 100% CPU schluckt und irgendwas mit Video zu tun haben könnte. Wenn das der Windowserver ist, hast Du natürlich nix gewonnen. Wenn es aber ein anderer Prozess ist, notiere Dir die PID (Prozess-ID, 2. Spalte).
Angenommen, die PID ist 1234, dann
Hoch ist die Wahrscheinlichkeit nicht, aber mit viel Glück geht danach der Windowserver wieder.

Die Möglichkeit habe ich leider nicht, bzw. müsste das erst mal einrichten. Ich habe aktuell die Videos alle deaktiviert.

Du bist jedenfalls nicht allein. Mir geht's wie dir:
In dem Moment wo ich ein Video mit dem Quicktime Player abspielen will ODER ein Video in YouTube auf Bild-in-Bild stellen will ODER ein in eine Website eingettetes YouTube-Video full screen stellen will, gibts einen kompletten System-Freeze. Man hört noch den Ton weiter, aber das Bild und das gesamte System friert ein. Dann hilft nur noch, den Einschaltknopf des Macs so lange gedrückt zu halten, bis er sich ausschaltet.

So einen brutalen Bug hab ich in den knapp 3 Jahrzehnten in denen ich jetzt mit Macs arbeite noch nicht erlebt.
Hab extra nicht sofort auf Sonoma upgedatet, sondern erst Anfang Jänner.
Werde wohl oder übel ein Downgrade auf Ventura machen.
Das ist aus meiner Sicht schon eine schwere Niederlage für Apple.

Wenn das gesamte System einfrieren würde, könntest Du auch keinen Ton hören. Das System läuft wunderbar weiter, nur die gesamte Bildschirmausgabe ist eingefroren.
Das ist immer noch viel zu früh bei der momentanen Softwarequalität von Apple. Ich würde immer erst upgraden, wenn die nächste macOS-Version draußen ist, sprich ein Jahr später.

Vielen Dank für diese Spitzfindigkeit, das hilft ungemein weiter. Doppelter Daumen nach oben!
Niemand weiß, ob diverse Bugs überhaupt behoben werden, wenn sie keine signifikant hohe Zahl an Benutzern betrifft. Es gibt zu diesem Bug diverse Google-Treffer, aber nicht wahnsinnig viele. Es ist also nicht davon auszugehen, dass es einen hohen Prozentsatz an Nutzern betrifft. Insofern hätte es uns also auch nach einem Jahr treffen können.

Das ist keine Spitzfindigkeit. Da das System noch läuft, kannst Du dich via ssh einloggen, nach dem Schuldigen suchen, den ggf. killen, aber zuallermindest das System ordentlich herunterfahren, statt einen Hard Reset am Einschaltknopf des Mac zu machen. Das hilft also sehr.
Natürlich. Es geht hier aber um Wahrscheinlichkeiten. Und die Wahrscheinlichkeit, von einem solch bösen Bug getroffen zu werden, ist nach 12 Monaten eben deutlich geringer als nach 3. Das sagt nichts über den Einzelfall, aber hilft gleichwohl, eine insgesamt vernünftige Entscheidung zu treffen.

Das System ordentlich runterfahren funktioniert ja leider (in meinem Fall) nicht, da der Rechner auf keinerlei Eingaben mehr reagiert. Ich nehme an, das wird bei macuser96 ähnlich sein.

Der Rechner reagiert auf keinerlei Eingaben über die GUI mehr, weil die blockiert ist.

Über ssh funktionieren Eingaben problemlos (garantiert jedenfalls, wenn es so ist, dass Du noch Ton hörst). Aber dazu braucht man eben einen ssh-Zugang. Das ist ja keine Hexerei. In den Systemeinstellungen → Freigaben → Entfernte Anmeldung (oder wie auch immer das jetzt unter Sonoma heißt) einschalten und sich einloggen entweder von einem anderen Mac aus via Terminal oder aber von iPhone oder iPad aus mit einer der vielen Terminal-Apps für kleines Geld.

Klar, das Terminal darf einem nicht unheimlich sein. Aber zumindest
einzugeben, um den Rechner sauber neu zu starten, sollte jeder fertigbringen, und ein wenig weiterführende Kommandos habe ich ja oben genannt.

Nutzern, die nicht auf die Kommandozeilenebene gehen wollen, hilft das natürlich nichts. Aber daraus zu folgern, ein Einfrieren der GUI sei gleichzusetzen mit einem Einfrieren von macOS insgesamt, ist schlicht und einfach falsch. Da ist ein erheblicher Unterschied, auch in praktischer Hinsicht.

Es ist halt nur keine Lösung für das eigentliche Problem. Es ist ein Weg, um einen hard reset zu vermeiden.
Den vermeide ich aber schon alleine dadurch, in dem ich die erwähnten Szenarien vermeide, die das "Blockieren der GUI" auslösen.

"https://discussions.apple.com/thread/255164877?sortBy=best"
iTunes laufen, werden nicht unterstützt, ab BigSur bis Sonoma nicht.

Nein, natürlich nicht. Das habe ich aber auch nicht behauptet.

Also ich werde es für mich anders lösen:

Nicht auf Ventura downgraden, sondern anstelle des QuickTime Players einen alternativen Player als Standard-Mediaplayer nehmen (teste gerade Elmedia Player, schaut okay aus) und anstelle von Safari entweder Firefox oder Opera. Damit funktioniert alles, was bei QT und Safari zum Einfrieren der GUI führt.