Wenn es mit einer anderen Distribution nicht auftritt, weiß ich, dass es wahrscheinlich an meiner openSUSE-Installation liegt, d.h. nicht zwingend an openSUSE selbst, aber an meiner spezifischen Installation. OK, guter Punkt. Wenn es allerdings auftritt, kann ich nicht sicher wissen, ob es an SW und/oder HW liegt. Dann müsste ich immer noch weiter testen. — Und vor allem, wie lange sollte ich dafür mit der anderen Distribution warten? Ich habe ja geschrieben, dass es selten (d.h. ca. alle 3 Wochen) auftritt. D.h. ich kann ja nicht mal alternativ ein System an einem Wochenende booten.
Hier kommt als einzelner Punkt noch einmal das letzte Argument vom vorhergehenden Punkt. Natürlich könnte ich mal ein anderes System booten oder gar installieren. Aber bisher zeigt sich der Fehler selten (d.h. ca. alle 3 Wochen). Da ist dieses Vorgehen zur Fehlersuche nicht praktikabel.
je nachdem, wie es bei openSUSE in Zukunft mit Leap weitergeht (ich persönlich habe das noch nicht wirklich so ganz verstanden, nur dass einiges bei SUSE und openSUSE anders werden soll — aber nicht, wie sich das für privat und Desktop konkret auswirkt…), werde ich ja in ca. 1 bis 2 Jahren innerhalb von openSUSE neu installieren oder sogar auf ein anderes Modell wechseln — oder eventuell ganz den Anbieter wechseln (ich habe es bisher nicht vor).
Und was mir noch einfällt, was theoretisch auch sein könnte:
Ich habe mein System (HW + openSUSE Leap) bereits seit mehreren Jahren.
Ich kann mich mittlerweile nicht mehr daran erinnern, ob das Problem quasi schon seit immer besteht. Oder z.B. erst beim Upgrade von Leap 15.n auf 15.(n+1) gekommen ist. Ich beschäftige mich halt erst seit Frühling dieses Jahres intensiv damit. Aber es könnte sein, dass es früher mal anders (d.h. besser) war.
Ich nutze Mozilla Firefox und Thunderbird inkl. einiger Add-ons. Bei manchen davon schreibe ich auch Bug-Reports. (Es sind i.d.R. echte Bugs, die dann auch gefixt werden.) In einem solchen Fall hatte ich mal eine Kommunikation mit dem Add-on Entwickler und einem Mozilla Entwickler (Thunderbird, aber er kennt damit auch Firefox besser als andere Leute, er kennt halt die Infrastruktur insgesamt recht gut). Ich hatte gefragt, was der signifikante Unterschied zwischen einem historisch gewachsenen Profil (bei Firefox oder Thunderbird) oder einem neu angelegten und dann entsprechend wie das alte eingerichtetem Profil (es wird also ein Profil komplett neu angelegt, dann aber nach bestem Wissen wieder so eingerichtet wie das bisherige) ist. Ich hätte vermutet, dass die beiden i.W. ziemlich ähnlich sein müssten (bis auf irgendwelche IDs etc. und so Sachen wie Cache halt). Aber der Entwickler hat geschrieben, dass es durchaus sein kann, dass es signifikante Unterschiede geben kann (weil eben das bisherige Profil historisch und organisch gewachsen ist und sich so bestimmte Artefakte angesammelt haben können). So etwas Ähnliches könnte ich mir hier rein prinzipiell auch vorstellen: Ich installiere mein System noch einmal neu, aber wieder in der Art wie bisher, und richte es auch nach bestem Wissen wieder so ein wie bisher. Und der Fehler tritt dann nicht mehr auf. Das würde ich nach der Erfahrung bei Mozilla (es war Thunderbird und ein dortiges Add-on) durchaus für möglich halten (es war eine ziemlich aufwändige Suche und ziemlich aufwändiges Nachstellen, um den Fehler auf verschiedene Weise auf verschiedenen Systemen explizit zu provozieren…)
Du hast ein Problem geschildert und um Rat gefragt.
Ich habe Dich auf eine, aus meiner Sicht mögliche Ursache für Dein Problem hingewiesen und Dir auch einige Sachverhalte (z.B. Ersetzen von Systempaketen durch ungetestete Pakete aus eingebundenen Factory-Repositories, Factory-Pakete werden gegen Factory-Pakete gelinkt, …) genannt, auf denen sich meine Vermutung gründet.
Du bist der Meinung, dass die von mir genannte Ursache nicht für Dein Problem verantwortlich sein kann und “belegst” das mit Argumenten wie
Nun, es ist Dein Problem und somit auch Deine alleinige Entscheidung wie Du es lösen willst/kannst.
Allerdings verstehe ich nicht so richtig, warum Du hier um Rat fragst, wenn Du doch ohnehin schon genau sagen kannst, was nicht die Ursache Deines Problems ist …
Das habe ich so nicht geschrieben. Ich schließe es nicht aus! Ich habe lediglich Argumente angeführt, die teilweise dagegen sprechen. Aber ich habe es nicht generell ausgeschlossen. Ja, ich schränke aus meiner Sicht die Wahrscheinlichkeit ein. Aber ich schließe es nicht aus.
Dann noch einmal so:
Ich will jetzt nicht ein komplett neues System aufsetzen. Aber ich wäre bereit, testweise (nachdem der Fehler das nächste Mal aufgetreten ist — bisher läuft es), die Factory-Repos auf das Nötigste zu begrenzen. D.h. Security wäre weiterhin enthalten, mit Prio>99, da ich veracrypt benötige. TeXstudio würde ich auch behalten, da ich hier nun wirklich keinen Einfluss sehe. Aber ja, ich würde Mozilla und LibreOffice und Xfce herausnehmen und somit wieder auf Standard setzen. Dann hätte ich bei Xfce (Thunar) wahrscheinlich kein WebDAV mehr (außer es wurde dort innerhalb des Standards gefixt), aber nun gut. Dann bleibt noch VLC. Was ist damit? Für einen gescheiten Betrieb muss PackMan oder VideoLAN eingebunden sein, wobei ich VideoLAN als weniger invasiv ansehe.
Ich schätze Deinen Rat ja. Ich wollte hier keinen Krieg losbrechen. Oder als Querulant auftreten. Aber aus meiner Sicht kann am Ende vieles verantwortlich sein. Wie gesagt, so viele Systempakete sind nicht ersetzt. Und nur weil (irgend-)ein Paket gelinkt wurde: wenn da nichts Betreffendes läuft? Oder verstehe ich da jetzt was falsch? — Am Anfang war ich ja von Firefox als Ursache ausgegangen. Und ja, ich habe das Mozilla Repo mit Prio<99. Aber wenn Mozilla beim Auftreten des Problems gar nicht läuft? (Das Problem ist ja schon mal mit Digikam (aus Flatpak) und einer anderen Anwendung (die ich nicht mehr weiß) vorgekommen.)
Aber ja, wenn es wieder auftritt, kann ich die Repos reduzieren. Mit den Anmerkungen (fragend) von oben.
Und dann noch einmal eine Verständnis-Frage zu den OBS Repos wie Mozilla (ich weiß es bisher einfach nicht…): ich wähle doch extra das Repo für Leap (in meinem Fall 15.6). Also nicht Tumbleweed (oder Slowroll, Factory, was manchmal angeboten wird, oder eins der alten Leaps oder ein ganz anderes). Müsste das dann nicht korrekt sein? Ich frage ganz naiv… Außerdem — wenn ich tatsächlich Leap statt Tumleweed (oder eventuell Slowroll) benutze — muss ich teilweise solche OBS Repos zumindest zusätzlich einbinden, weil ich gerne Pakete wie veracrypt hätte, die bei Leap im Standard nicht enthalten sind.
(Ich hoffe, wir vertragen uns wieder. Dein letzter Beitrag klang recht aufgebracht. Ich wollte Dich nicht ärgern.)
Das sind alles factory Repos, d.h. neuere Versionen eines Paketes, welches gegen neuere libs gebaut ist und diese evt. auch benötigt.
Beispiele:
multimedia:apps baut gegen mulutimedia:libs daher kann es sein, das ein Paket aus multimedia:apps auch ohne das multimedia:libs Repo funktioniert, muss aber nicht sein.
multimedia:libs beißt sich wiederum mit Packman, ebenso Videolan mit Packman, wobei ich Packman wegen der größeren Paketauswahl bevorzuge.
Packman wird dann übrigens gegen Leap oder Tumbleweed gebaut und sollte eigentlich keine Probleme bereiten, was aber nichts heisst.
Kleines Beispile mit einem in meinem /home Repo gebauten gimp 2.10.38:
Ich versuche jetzt mal libgegl aus dem OSS Repo zu installieren:
zypper in -f libgegl-0_4-0-0.4.46-150600.2.37
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...
Installation von 'libgegl-0_4-0-0.4.46-150600.2.37.x86_64' aus Repository 'OSS' wird erzwungen.
Paketabhängigkeiten werden aufgelöst...
Problem: 1: das installierte libgimp-2_0-0-2.10.38-lp156.3.2.x86_64 erfordert 'libgegl-0_4-0 >= 0.4.48', aber diese Anforderung kann nicht bereitgestellt werden
Lösung 1: Folgende Aktionen werden ausgeführt:
Herabstufung von libgimp-2_0-0-2.10.38-lp156.3.2.x86_64 auf libgimp-2_0-0-2.10.30-150400.3.11.1.x86_64
libgimp-2_0-0-2.10.30-150400.3.11.1.x86_64 von Hersteller SUSE LLC <https://www.suse.com/> installieren
und libgimp-2_0-0-2.10.38-lp156.3.2.x86_64 von Hersteller obs://build.opensuse.org/home:Sauerland ersetzen
Herabstufung von gimp-2.10.38-lp156.3.2.x86_64 auf gimp-2.10.30-150400.3.11.1.x86_64
gimp-2.10.30-150400.3.11.1.x86_64 von Hersteller SUSE LLC <https://www.suse.com/> installieren
und gimp-2.10.38-lp156.3.2.x86_64 von Hersteller obs://build.opensuse.org/home:Sauerland ersetzen
Herabstufung von gimp-lang-2.10.38-lp156.3.2.noarch auf gimp-lang-2.10.30-150400.3.11.1.noarch
gimp-lang-2.10.30-150400.3.11.1.noarch von Hersteller SUSE LLC <https://www.suse.com/> installieren
und gimp-lang-2.10.38-lp156.3.2.noarch von Hersteller obs://build.opensuse.org/home:Sauerland ersetzen
Herabstufung von gimp-plugin-aa-2.10.38-lp156.3.2.x86_64 auf gimp-plugin-aa-2.10.30-150400.3.11.1.x86_64
gimp-plugin-aa-2.10.30-150400.3.11.1.x86_64 von Hersteller SUSE LLC <https://www.suse.com/> installieren
und gimp-plugin-aa-2.10.38-lp156.3.2.x86_64 von Hersteller obs://build.opensuse.org/home:Sauerland ersetzen
Herabstufung von libgimpui-2_0-0-2.10.38-lp156.3.2.x86_64 auf libgimpui-2_0-0-2.10.30-150400.3.11.1.x86_64
libgimpui-2_0-0-2.10.30-150400.3.11.1.x86_64 von Hersteller SUSE LLC <https://www.suse.com/> installieren
und libgimpui-2_0-0-2.10.38-lp156.3.2.x86_64 von Hersteller obs://build.opensuse.org/home:Sauerland ersetzen
Lösung 2: libgegl-0_4-0-0.4.46-150600.2.37.x86_64 nicht installieren
Lösung 3: libgimp-2_0-0-2.10.38-lp156.3.2.x86_64 durch Ignorieren einiger Abhängigkeiten brechen
Wählen Sie aus den obigen Lösungen mittels Nummer oder brechen Sie (a)b [1/2/3/a/d/?] (a): a
Wie du siehst, benötigt gimp 2.10.38 explizit diese lib in Version:
zypper se -si libgegl
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...
S | Name | Type | Version | Arch | Repository
---+---------------+-------+------------------+--------+--------------
i+ | libgegl-0_4-0 | Paket | 0.4.48-lp156.1.1 | x86_64 | Sauerland-OSS
Diese lib hat aber unter Leap 15.6 nicht mehr gebaut.
Damit wäre dann gimp irgendwann auch für Leap nicht mehr gebaut worden.
rpm -q --changelog libgegl-0_4-0
* Mo Sep 16 2024 Stephan Hemeier <Sauerlandlinux@gmx.de>
- add revertleap.patch to get gegl build on older ffmpegs
Du möchtest Dein System, so wie es momentan besteht, möglichst unverändert weiter analysieren, um die Ursache für das von Dir beschriebene Problem zu finden.
Ich würde zunächst verifizieren ob das, was “laut Spezifikation” fehlerfrei arbeiten müsste, auch tatsächlich funktioniert und dann, ausgehend vom Ergebnis, weiter analysieren.
Welches Vorgehen das “richtige” ist und/oder zum Erfolg führt, kann ich jedoch nicht sagen.
Allerdings sehe ich keine Möglichkeit, wie ich Dich bei der von Dir gewählten Vorgehensweise weiter unterstützen könnte, denn
Und da nicht ausgeschlossen werden kann, dass Dein Problem hardware-bedingt ist, scheidet - meines Erachtens - die Verwendung einer virtuellen Maschine dafür aus.
Erschwerend kommt hinzu, dass das von Dir beschriebene Problem nur sporadisch aufzutreten scheint; d.h. jeder der Dir helfen will muss nicht nur ein vergleichbares System aufbauen, sondern es ggf. auch noch über einen längeren Zeitraum hinweg aktiv verwenden.
Es tut mir leid, aber das übersteigt schlicht meine Möglichkeiten.
Ich habe jetzt nur das Problem, dass einige meiner Videos in VLC “flackern” und “teilweise grüne Flecken haben”.
Z.B.:
gunnersson@tulicube:~/Videos/Unterhaltung/Poetry Slam> mediainfo Jan\ Philipp\ Zymny\ -\ Schule\ machen\ dumm.mp4
General
Complete name : Jan Philipp Zymny - Schule machen dumm.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : isom (isom/iso2/avc1/mp41)
File size : 169 MiB
Duration : 11 min 48 s
Overall bit rate : 2 005 kb/s
Frame rate : 23.976 FPS
Writing application : Lavf57.56.100
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4
Format settings : CABAC / 3 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 3 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 11 min 48 s
Bit rate : 1 873 kb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Variable
Frame rate : 23.976 (24000/1001) FPS
Minimum frame rate : 23.974 FPS
Maximum frame rate : 23.981 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.038
Stream size : 158 MiB (93%)
Codec configuration box : avcC
Audio
ID : 2
Format : AAC LC
Format/Info : Advanced Audio Codec Low Complexity
Codec ID : mp4a-40-2
Duration : 11 min 48 s
Bit rate mode : Constant
Bit rate : 126 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 44.1 kHz
Frame rate : 43.066 FPS (1024 SPF)
Compression mode : Lossy
Stream size : 10.6 MiB (6%)
Default : Yes
Alternate group : 1
Ich habe einige Videos, die das betrifft. Ich habe jetzt nicht überall die Codec-Info gecheckt, ob die gleich oder unterschiedlich sind. Hier jedenfalls mal als exemplarisches Beispiel für einen Fehlerfall. Ich weiß nicht, ob ich nun extra ein neues Topic dafür aufmachen soll. Vielleicht ist es ja mit 1, 2 schnellen Tipps getan. Vorher mit der alten, aber von mehreren Usern kritisierten und dann von mir geänderten Konfig, ging es ja noch. (Aber um den ursprünglichen Fehler mit seinem Potenzial zu minimieren habe ich ja nun endlich Euren Rat befolgt.)
So, ich habe meine Video Sammlung geprüft: so viele Videos mit Artefakten beim Abspielen sind es nicht.
Außer dem bereits genannten noch ein weiteres mit gleichen Codec-Angaben.
Außerdem:
gunnersson@tulicube:~/Videos/Unterhaltung/Konzerte> mediainfo \(2014\)\ Apocalyptica\ -\ WOA.mp4
General
Complete name : (2014) Apocalyptica - WOA.mp4
Format : MPEG-4
Format profile : Base Media / Version 2
Codec ID : mp42 (isom/mp42)
File size : 1.29 GiB
Duration : 1 h 17 min
Overall bit rate mode : Variable
Overall bit rate : 2 378 kb/s
Frame rate : 25.000 FPS
Encoded date : 2014-08-01 22:18:54 UTC
Tagged date : 2014-08-01 22:18:54 UTC
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L3.1
Format settings : CABAC / 3 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 3 frames
Format settings, GOP : M=4, N=33
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 1 h 17 min
Bit rate : 2 248 kb/s
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 FPS
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.098
Stream size : 1.22 GiB (95%)
Encoded date : 2014-08-01 22:18:54 UTC
Tagged date : 2014-08-01 22:18:54 UTC
Color range : Limited
Codec configuration box : avcC
Audio
ID : 2
Format : AAC LC
Format/Info : Advanced Audio Codec Low Complexity
Codec ID : mp4a-40-2
Duration : 1 h 17 min
Bit rate mode : Variable
Bit rate : 125 kb/s
Maximum bit rate : 151 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Frame rate : 46.875 FPS (1024 SPF)
Compression mode : Lossy
Stream size : 69.7 MiB (5%)
Encoded date : 2014-08-01 22:18:54 UTC
Tagged date : 2014-08-01 22:18:54 UTC
Diese 3 Videos haben vorher problemlos abgespielt. Ich hatte sie erst vor kurzem noch angesehen. Die anderen Videos in der Sammlung machen mit der neuen Konfig keine Probleme. Die meisten sind MP4, ein MOV, ein WEPM, ein FLV.
Vor kurzem habe ich ausführlich die Hardware getestet mit Hardwaretestsoftware toolstar®testLX von toolhouse DV-Systeme GmbH. Zusammen mit den Hardware-Tests von früher schließe ich ein Hardware-Problem zwar nicht völlig aus, halte es aber mittlerweile für unwahrscheinlich.
Damit bleibt das System, meine openSUSE Leap 15.6 Installation mit Repositories siehe oben. Die Installation selbst orientiert sich größtenteils am Standard, allzu viele Einstellungen sind nicht verändert oder explizit gesetzt.
Weil ich immer Mozilla Firefox in Verdacht hatte, aber ich nun dort mal die Hardware-Beschleunigung deaktiviert.
Ich kann mich nicht mehr genau erinnern, wann dieses Problem erstmalig aufgetreten ist. Mittlerweile ist das System Leap 15.6 und Kernel 6.4.0-150600.23.25-default. Ich meine, dass das Problem bei Leap 15.4 (Leap 15.5? — wohl eher doch 15.4…) und Kernel 5.x noch nicht existierte… Jedenfalls habe ich diesen Desktop PC jetzt seit ca. 5 Jahren und die ersten Jahre waren noch fehlerfrei.