Beiträge von Hidalgo

Zitat von Suelkun

lieber Jürgen,

das ist meiner Meinung nach mit Sicherheit kein Hardwareproblem.

Wie man so etwas ausschließen kann, wenn sich der Rechner beim Hochfahren ausschaltet, ist für mich nicht nachvollziehbar.

So kann z.B. der Rechner unter Windows problemlos laufen, weil das RAM unter Windows wesentlich "gemächlicher" beansprucht wird. Obwohl ein Speicherbaustein defekt ist, läuft er unter Windows weil das schlichtweg nicht auffällt bzw. auffallen muss.

Linux nutzt jedoch die Hardware effizient - und das erwarte ich auch von einem anständigen BS: Es soll das maximale Mögliche an Leistung aus der Hardware kitzeln. Genau dann fallen allerdings auch erst Defekte in der Hardware auf.

Unterschiedliche Versionen einer Linux Distribution bedeuten unterschiedliche Effizienz in der Software. Da können minimale Unterschiede schlechte Bauteile entlarven.

Vor allem auf den Speicher würde ich fokussieren: Nur ein falsches Bit beim Hochfahren lässt den Rechner durchaus abnippeln!

Memtest machen - dann weiter sehen.

Zitat von negatron

Mit den Maßnahmen in Post #39 und #41 laufen Videos in VLC störungsfrei (sowohl Bild aus als Ton). Vielen Dank!

Ich habe außerdem gerade ein 6-minütiges Video auf YouTube angesehen, ebenfalls störungsfrei.

Danke ebenfalls! Ist auch für mich eine nachhaltige Erfahrung darüber, wie man sich bei suboptimal funktionierender Software - Hardware Zusammenarbeit in bestimmten Fällen behelfen kann. Wir haben dein Problem über ein Zeitfenster so weit nach "hinten verschoben", dass es nicht mehr auftritt.

Dann muss man eben auch noch für Audio-Abarbeitung den Puffer erhöhen.

Soll so gehen:

mkdir -p ~/.config/pipewire/pipewire.conf.d/

In dem erstellten Ordner die Datei custom.conf erstellen und darin eingeben:

context.properties = {

default.clock.min-quantum = 1024

default.clock.max-quantum = 2048

}

Danach den Soundserver neu starten:

systemctl --user restart pipewire pipewire-pulse

Die Werte für min-quantum und max-quantum kann man bei Bedarf noch verdoppeln. Aber für Audio sollte das eigentlich so ok. sein.

Auch den Vivaldi-Browser kannst du im Cache anpassen. Vielleicht magst du da selbst recherchieren im Netz, denn ich verwende kein Vivaldi.

Zusätzlich nach Durchführung von #38 bitte nochmal die Audio-/Videowiedergabe ausprobieren,

nachdem Leap 16 mit mit fast allen Codecs - Audio und Video betreffend - aktualisiert wurde. Die kamen gerade herein!

Erst dann:

Bitte folgende Einstellung im VLC vornehmen:

Einstellungen anzeigen - unten links - auf alle Einstellungen anzeigen

auf Eingang/Codecs gehen, ganz rechts nach ganz unten scrollen, dort den Datei-Cachewert verfünffachen, also bei Voreinstellung 1000ms auf 5000ms einstellen.

Auch im MPV kannst du den Cache aktivieren, indem du die Datei

~/.config/mpv/mpv.conf

erstellst oder editierst falls vorhanden und dort:

cache=yes

demuxer-max-bytes=500MiB

demuxer-max-back-bytes=100MiB

einfügst.

Ansonsten bin ich eigentlich durch mit allem, was man aus der Ferne machen kann und auch mit dem, was ich für vernünftig halte. Da die Ruckler auf deinem Asus-Lapo nach einer gewissen Verzögerung auftreten, vermute ich ein Problem mit dem Leap 16 Subsystem (Audio u. Video) und deiner Asus Hybridgrafik. Da läuft etwas zu langsam bei der Abarbeitung (entweder Audio oder Video), so dass die Synchronisierung stockt. Vielleicht kann man das Problem mit dem höheren Cachewert entschärfen.

Kann man im Bios deines Asus-Lapos versuchsweise die Nividia-Karte deaktivieren?

Wir konzentrieren uns auf die Intel-Grafik, weil die unter Linux problemlos ist. Deine ist auch viel leistungsfähiger als meine.

In deiner Ausgabefür

inxi -Gxx

kann ich keine Unwägbarkeiten entdecken.

Hatten wir schon

journalctl -f

ausprobiert? Dort sollten dann genauere Fehlermeldungen erscheinen, wenn die Audio-Videoausgabe ruckelt. Da wird alles protokolliert, was die Eingrenzung auf Aussetzer und kongruente Fehlermeldungen nicht leicht macht - aber etwas besseres fällt mir momentan nicht ein. Die Codecs sollten ja von Packman ok sein - aber wie ist es mit den Mesa Treibern?

Die sollten doch mit:

sudo zypper install intel-media-driver libva-intel-driver vaapi-intel-driver

auch die korrekten sein? Ansonsten bitte anstoßen, dass das geschieht. Irgendetwas harmoniert da nicht die Codecs sind nicht alles, auch die Treiber sind von SuSE und Packman unterschiedlich ... glaube ich!!!

Danke - habe es gerade gesehen: Nothing to do

Bei Eingabe in der shell wird bei mir angezeigt:

mathias@linux:~> inxi -Gxx
Graphics:
  Device-1: Intel Xeon E3-1200 v2/3rd Gen Core processor Graphics
    vendor: ASRock driver: i915 v: kernel arch: Gen-7 ports:
    active: HDMI-A-1 empty: DP-1, DP-2, DP-3, HDMI-A-2, HDMI-A-3,
    VGA-1 bus-ID: 00:02.0 chip-ID: 8086:0152
  Display: wayland server: X.org v: 1.21.1.15 with: Xwayland
    v: 24.1.6 compositor: kwin_wayland driver: X: loaded: modesetting
    unloaded: vesa alternate: fbdev,intel dri: crocus gpu: i915
    display-ID: 0
  Monitor-1: HDMI-A-1 res: 1920x1200 size: N/A
  API: EGL v: 1.5 platforms: device: 0 drv: crocus device: 1
    drv: swrast gbm: drv: crocus surfaceless: drv: crocus wayland:
    drv: crocus x11: drv: crocus
  API: OpenGL v: 4.5 compat-v: 4.2 vendor: intel mesa v: 24.3.3
    glx-v: 1.4 direct-render: yes renderer: Mesa Intel HD Graphics
    2500 (IVB GT1) device-ID: 8086:0152 display-ID: :1.0
  API: Vulkan v: 1.4.309 surfaces: xcb,xlib,wayland device: 0
    type: integrated-gpu driver: N/A device-ID: 8086:0152

und bei Dir?

Es dreht sich speziell um die Ausgabe Display .... X: loaded: modesetting

(dort könnte bei dir auch intel dri: ... i915 stehen

und

API: Ob dort der intel mesa treiber werkelt

Dass wir die Nvidia GPU außen vor lassen, ist ok - wir beziehen uns alleine auf die interne Grafik, das reicht vollkommen aus.

Außerdem führe bitte folgendes Kommando in der Shell aus

sudo zypper install intel-media-driver libva-intel-driver vaapi-intel-driver

Unter OpenSuSE Leap 15.6 läuft die Grafik einwandfrei. Unter Wayland fast gar nicht und unter X11 mit Stottern.

Mit "hardware-accelerated" gar nicht.

Richtig?

Dann wäre das doch ein Zeichen, dass die Kommunikation zwischen dem Kernel-Modul (i915 für Intel oder Nvidia) und der Grafikbibliothek (Mesa) noch nicht stabil genug läuft.

Leap 16.0 basiert auf der neuen openSUSE ALP (Adaptable Linux Platform), d.h. der Grafik-Stack ist deutlich moderner als bei 15.6. Dein Asus nutzt aber eine ältere Broadwell-Architektur, für die die neuen Treiber einfach noch nicht passen. Das sollte dann aber zukünftig behoben werden.

Das Einzige was mir momentan dazu einfällt: Kannst Du deinen Asus Laptop im Netzbetrieb hinsichtlich des Power-Managements mal auf "volle Pulle" stellen? Auf "Performance" oder so ähnlich? Vielleicht wird nach einiger Zeit Videogucken das Asus unter Leap 16 zu stark gebremst, weil das Power-Management unter Linux zu restriktiv greift?

Zitat von JSC

Oder im Boot-Menue einfach Pfeil-Taste nach unten drücken, das stoppt den Timer und warten, ob das Netzteil aussteigt.

Jupp!

Des Weiteren kann man auch ins UEFI-Menü booten und sich dort die einzelnen Versorgungsspannungen anschauen. Nicht nur ein paar Minuten beobachten, sondern länger und auf Konstanz achten. Auch kann man mit Knoppix o.ä. einen Speichertest: memtest starten und wenigstens einen Volldurchlauf durchführen lassen.

Wenn du mit einem USB-Stick ein Rettungssystem bzw. ein Live System - z.B. Knoppix - startest, bleibt der Rechner dann an?

Falls der sich dann auch ausschaltet, liegt m.E. ein Hardware-Defekt vor, z.B. schwächelndes Netzteil.

Dann suchen wir eben weiter.

Weil selbst meine alte Mühle (Intel-Zweikerner mit integrierter eher schwachbrüstiger Grafik) auch ohne Hardware gestützte Dekodierung alles an Videos und Sound ruckelfrei abarbeitet, schaue doch mal bitte in den Systemmonitor. Welche Auslastung kannst du dem entnehmen? Bei mir sind es im Leerlauf (es läuft immer etwas im Hintergrund) und eben nur mit laufendem Systemmonitor im Mittel: Um die 2% maximal.