Kaffeine kein Bild kein Ton

Ich benutze auch Kontact. Nur: Für eine private Anwendung ist das Programm viel zu aufwendig. Das wäre Mal eine echte Alternative auch für gewerbliche Kunden gewesen. Kaputt gemacht. Das Problem an OpenSource ist, dass ganz häufig sich Leute engagieren, die das als Studienprojekt oder ähnliches brauchen. Und ist das Studium zu Ende, wenden wir uns neuen Aufgaben zu. Es ist doch irgendwie ganz "lustig", dass z. B. Xine immer noch weiter entwickelt wird - obwohl es Technik aus den 90ern ist und keiner das Programm mit einer völlig albernen Benutzeroberfläche braucht. Nicht umsonst funktionierte Kaffeine erst wieder, als es auf die VLC-Libraries umstellte. Auch den MPlayer braucht keine Sau. Auch dessen Benutzeroberläche ist retro und einfach nur sch..ße! Bis heute gibt es xawtv, braucht niemand, bindet bei der Entwicklung völlig sinnlos manpower. Nehmen wir KOffice. Das war Mal ein schlankes Programm, dass für den heimischen Briefeschreiber gedacht war, der den ganzen Kram, den die klassischen Schreibprogramme bieten, zu Recht rausschmiss. Den ursprüngliche Entwickler, der das Ganze - sinnvoll - begonnen hatte, wurde abgesetzt, indem man einen Fork - calligra - gründete. KOffice konnte Silbentrennung, Calligra kann es bis heute nicht. Es gibt auch unter KDE keine sinnvolle Planung und Steuerung der Projekte. Das ist unter Gnome schon ein wenig anders!

Zur Behebung des Problems würde ich folgenden Weg gehen

falls der vorhergehende Kernel mit Kaffeine die gleiche Problematik zeigt:

Diesen hier:

https://opensuse-guide.org/codecs.php

@ MA

Auch ich hätte einiges zu meckern - aber einem geschenkten Betriebssystem schaut man nicht ins Maul

und da reagieren einige allergisch drauf nach dem Motto: "Mach' selbst!" Und irgendwie haben die Recht.

Aber wenn der screen nach einem Kernel-Update zweimal innerhalb von vier Monaten abranzt, weil komplette

AMD-Grafikkarten nicht korrekt bedient werden, dann kann ich einen Windows User schlecht von Linux,

speziell OpenSuSE überzeugen. Noch nicht mal Textkonsole geht mit dem *60er Kernel und klar kann man

sich helfen, weil Linux transparent ist und log-files ausführliche Hilfe zur Selbsthilfe leisten. Dazu braucht man

nur einen zweiten Rechner und ssh-Zugriff. Wie man allerdings an das log-file des vorher fehlgeschlagenen Boots

kommt nachdem man danach mit dem funktionierenden Kernel bootete weiß ich immer noch nicht - dann das wäre

der einfachere Weg. Da kann man die Konfigurationsdateien für dmesg umstellen und dann soll das funzen -

eingestellt ist das Vorab aber nicht.

Auf Bugzilla sollte ich das Logfile dmesg des funktionierenden Kernels liefern, des nicht funktionierenden

Kernels und von hwinfo. Als ich das endlich hinbekam, war jemand anderes schon schneller und wies darauf

hin, dass der kernel-Bug schon mal aufgetreten ist. Das hatte ich eingangs auch gleich und auf die Nummer

hingewiesen - aber man ist ja höflich und das auf englisch.

Ja - Hilfe bekommt man und alle sind sehr nett ...

aber irgendwie habe ich den Eindruck mit SuSE geht das den Bach 'runter, was das Debugging betrifft.

Wäre jammerschade!

Ist nur meine Meinung - bitte nicht böse sein.

Ich will hier eigentlich nur helfen falls ich es kann.

Recht haben will ich nicht ... ich habe wie gesagt nur eine subjektive Meinung.

Gruß ...

Zitat von Hidalgo

Ist nur meine Meinung - bitte nicht böse sein.

Du darfst schon Deine Meinung haben, wir sind hier im freien Land

Was ich aber nicht verstehe? Wenn der neue Kernel nicht geht dann kannst Du noch immer mit dem alten Kernel booten.

Zitat von Hidalgo

Wie man allerdings an das log-file des vorher fehlgeschlagenen Boots

kommt nachdem man danach mit dem funktionierenden Kernel bootete weiß ich immer noch nicht

Um auch vorherige Boots / Shutdowns via Logfiles auswerten zu können, muss eine kleine Änderung vorgenommen werden in:

/etc/systemd/journald.conf

In diesen zwei Zeilen die "#" entfernen und folgende Änderungen vornehmen:

Storage=persistent

SystemMaxUse=100M

Zur Erklärung:

Storage=persistent (Dauerhaftes Speichern der Logfiles ermöglichen)

SystemMaxUse=100M (Logfiles sollen jedoch eine Größe von 100MB nicht überschreiten)

Danach funktioniert:

journalctl -b -1 -p err

oder

journalctl -b -2 -p err

u.s.w.

Wenn du ....-p err weglässt, bekommst du alle Meldungen.

-p err (bedeutet, dass nur Meldungen mit Prio Error oder sogar schlimmer angezeigt werden)

-b -3 (zeige mir alle Meldungen aus dem drittletzten Boot / Shutdownvorgang)

Zitat von Heinz-Peter

Du darfst schon Deine Meinung haben, wir sind hier im freien Land

Was ich aber nicht verstehe? Wenn der neue Kernel nicht geht dann kannst Du noch immer mit dem alten Kernel booten.

Ja - habe ich ja auch gemacht.

Inzwischen läuft ja auch der ***60er Kernel mit dem AMD Treiber,

siehe Thread: "Nach Sicherheitsupdate Leap 15.2 startet Grafik nicht mehr".

Trotzdem ist es ein gravierender Fehler, der nun zweimal auftrat.

Beim ersten Mal als das auftrat, wurde allerdings - sicher durch meinen Fehler auch

wenn ich Anweisungen befolgte - der vorherige Kernel wegen eines Korrekturversuchs überschrieben

und nun lief nichts mehr.

Über ssh installierte ich über yast damals dann zwar den alten Kernel, aber die Grafik wurde

wegen inkompatibler Grafikeinstellungen nur im Vesa-Modus angezeigt. Da war einiges kaputt

gegangen.

Über das BTRFS-Filesystem machte ich ein "Rolling Back" und schon war alles wieder klar -

natürlich mit altem Kernel.

Dann kam einen Monat später der korrigierte Kernel bis nun das Spiel wieder von vorn losging.

Nun habe ich die "wasweissich.conf" - war es zypp.conf (?) so geändert, dass die letzten fünf Kernel

behalten werden - sicher ist sicher und auf der SSD ist genug Platz.

Ja - man lernt dazu, aber man macht das ja nicht jeden Tag

Zitat von sterun

Um auch vorherige Boots / Shutdowns via Logfiles auswerten zu können, muss eine kleine Änderung vorgenommen werden in:

/etc/systemd/journald.conf

In diesen zwei Zeilen die "#" entfernen und folgende Änderungen vornehmen:

Storage=persistent

SystemMaxUse=100M

Zur Erklärung:

Storage=persistent (Dauerhaftes Speichern der Logfiles ermöglichen)

SystemMaxUse=100M (Logfiles sollen jedoch eine Größe von 100MB nicht überschreiten)

Danach funktioniert:

Code

journalctl -b -1 -p err

oder

Code

journalctl -b -2 -p err

u.s.w.

Wenn du ....-p err weglässt, bekommst du alle Meldungen.

-p err (bedeutet, dass nur Meldungen mit Prio Error oder sogar schlimmer angezeigt werden)

-b -3 (zeige mir alle Meldungen aus dem drittletzten Boot / Shutdownvorgang)

Alles anzeigen

Ganz hervorragend! Danke - das werde ich bei mir gleich ändern.

Gruß ...

PS:

journalctl kann auch Kernel-Meldungen anzeigen (wie dmesg) mit "-k".

Ein Beispiel des drittletzten Boot / Shutdown:

journalctl -k -b 3 | grep -Ei "error|fail|crit"

-b 3 (boot) - zeigt alles aus dem drittletzten Boot / Shutdown

-k (kernel) - zeigt alle Meldungen (wie dmesg)

Um was ging es in dem Thread hier eigentlich?