Jinak ChatGPT říká:

If the stuttering MKV file is PAL region TV content, it's almost certainly encoded at 25 fps, which can stutter on displays running at 60Hz — very common in laptops and monitors outside PAL countries.

Je to možný? Notas je z US a video je český film (25 fps).

Zajímavé je, že to video co blbne je encodovane na 25 fps. Teď jsem v rychlosti zkoušel pustit 30fps video a zatím to vypadá ok. Mohlo by v tom hrát roli, že používám scaling 120%?

DANIELSOFT: To podle mně na Waylandu (Plasma 6.3.) právě nejde nebo to alespoň nemůžu najít.

DANIELSOFT: Vypnout compositing pod Waylandem?

DARUMA: možná střelím od boku, ale dá se vypnout compositing v DE, videa můžou běžet rychleji, zkus, kdyžtak můžeš setnout zpátky

MA747: jakou knihovnu, neco jako jemalloc nebo tcmalloc?

Ahoj, měl bych dotaz. Mám Lenovo Carbon X1 12th s procesorem a grafikou od Intelu. IPS displej 60hz. Fedora 42 KDE (Wayland). Systém up to date, ovladače a kodeky taky. Všechno šlape bezvadně, akorát včera jsem pouštěl video ve VLC (flatpak) a během přehrávání docházelo k občasnému zadrhnutí obrazu. Zkoušel jsem mpv player a tam se to dělo taky. Youtube videa v prohlížeče jedou ok. Nemáte někdo nějaký tip jak tohle troubleshootovat? Díky.

JANFROG: ne, nepoužívá. Resp. volá jednu knihovnu a do té nevidím.
CASTER: přesně o tom jsem také přemýšlel, že by si dělal cache, ale pokud si dobře pamatuji, není k tomu důvod. A po ukončení zátěže paměťové nároky zůstanou stejné. Ještě si projdu kód a zkusím počkat, jestli se paměť nezmění.
JANFROG: stoupají i ostatní, co jsou v htop vidět.

Díky za reakce.

Dělám teď nový instal a přemýšlím nad dělením disku na /; /home; /data s tím že hudbu,dokumenty, fotky atd si budu házet do /data, kdybych dělal pak nějaký reinstal,tak udělám jen formát / a /home s /data mi zůstanou, jen připojím. No a kdybych chtěl čistý reinstal, tak zformátuju / a /home - dokumenty obrázky mi zůstanou v /data , je ta úvaha špatná?

HOWKING: tak se neboj a zkus tu experimentální větev, nebo se zbav nvidie...

B3TL: Mám stable až na grafárnu.

HOWKING: Mas stable větev, nebo experimental?

Pred casem jsem se tu ptal na zalohovani, popripade verzovani a synchronizaci dotfiles a configu ruzne po systemu. Par tydnu jsem se v tom vrtal a hledal asi dokonale reseni bez prace nebo tak neco a pak se rozhodl to udelat rucne z git repa pomoci symlinku a scriptu co je po systemu bezpecne rozdistribuuje. Nakonec jsem s tim celkem spokojeny https://github.com/manihindrich/dotfiles/ casem to prepisu do pythonu, ted jsem takhle spoko. Treba se nekomu bude hodit

MA747: VIRT ukazuje i "non-commited" memory, takze to muze znamenat jen ze si program tu pamet rezervuje ale nepouziva.

MA747: Pouziva ten program mmap + MAP_ANON?

MA747: valgrind apod pozna, kdyz program nikdy neuvolni alokovanou pamet, protoze k ni ztrati pointer atd. Kdyz ji pri korektnim ukonceni vsechnu uvolni, tak to znamena, ze pointery zjevne neztratil a leak nebyl. Ale nemuze ophalit treba pripady, kdy si program cachuje nejaka data a ma tu cache prubezne uvolnovat / drzet na nejakem mnozstvi cachovanych dat, a tohle z nejakeho duvodu nefunguje.
Nesouvisi to s tou zatezi, kdyz je to server? Kdyz se zatez vypne, nespadne taky vyuziti pameti serverem?
Dalsi co me napada, je, ze se to po letech kompiluje/spousti na novejsi glibc, kde muze byt zmena v implementaci malloc/new aby to lip skalovalo (per-thread areny atd) coz ale znamena vetsi vyuziti pameti v porovnani se starou glibc.

HOWKING: Tak po skoro měsíci se v MacOS nekousl. Udělal jsem experiment. Jednak jsem nainstaloval celý Debian od nuly znova, abych vyloučil nějaký můj renonc a pak jsem NMVe zakázal v biosu a provozoval jsem to jen na SATA disku. A kousl se po jednom dni znova. Diskem to nebude. Sere mě, že ostatní distra tak plýtvají výkonem. Debian je na stejném železe o 10% na CPU rychlejší jak jakékoli jiné distro (a už jsem zkoušel i Fedoru). Možná je chyba v tom, že do Debianu strkám ty aktuální ovladače grafiky.

SUK:
==39487==
==39487== HEAP SUMMARY:
==39487== in use at exit: 0 bytes in 0 blocks
==39487== total heap usage: 9,794,483 allocs, 9,794,483 frees, 264,131,598 bytes allocated
==39487==
==39487== All heap blocks were freed -- no leaks are possible
==39487==
==39487== For lists of detected and suppressed errors, rerun with: -s
==39487== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Tak jsem z toho poněkud zmatený. Proč tedy roste VIRT, RES?

BTW kompilace s -g; valgrind --leak-check=yes ./a.out

MA747: valgrind byl?

Poradil by mi někdo prosím, jak detekovat memory leaks? Mám napsaný program v C++, TCP/IP server, threads, několik let starý, tenkrát mi běžel v pohodě bez memory leaks, ladil jsem jej přes electric fence, běžel mnoho dnů v masivním zatížení. V noci jsem jej zkompiloval, přes noc pustil zátěž a ráno jsem v htop viděl, jak narostla virt mem. Zkoušel jsem znovu electric fence (kompilace -lefence a potom gdb a.out) a nic, teď jsem zkoušel memleax a po ukončení programu hláška: "no expired memory blocks". Díky.

DANIELSOFT: ještě bych přidal do pléna, může to být problém s SQLite.

je to pracovní stanice Dell a šlapal jak švýcarský hodinky, jen poslední dobou ten FF: dvakrát se stalo, že zmizely ikonky u bookmarků a teď tohle

možná čas na novou mašinu

jinak mám to z debu, který je v oficiálním mintovém repozitáři a FF byl už nainstalovaný hned při instalaci OS

taky ten počítač je z roku 2016 a možná už blbne disk (scan zkusím) díky efektivitě Linuxu jsem nebyl nucen upgradovat HW :)

ZBYNEK: vždycky to zatím bylo když jsem ho pustil po startu PC

zkusím lsof, díky

DANIELSOFT: Ani jednou za ta léta, FF mám jako primární browser (ruční "instalace", binárka u mě v home; žádný snap ani deb)

Podíval bych se přes lsof, jaké procesy čtou z profilového adresáře...
Je to po staru počítače, po pádu FF, nebo po korektním ukončení předchozí instance?

DANIELSOFT: to je spis bug... me podobne obcas "zahapruje" Feedbro addon (RSS ctecka) s tim, ze si mysli, ze se pousti v privatnim okne. Zabit dotycny tab a pustit znovu to fixne. Nemel jsem naladu se s tim vic dal crcat :)

asi sem: už cca třikrát se mi stalo, že když jsem nastartoval Firefox na Linuxu (Mint), nebyly tam bookmarky, ani ty nejpoužívanější, které mám v liště a napsalo to, že se k nim nemůže dostat, protože je má otevřené nějaký jiný proces

mám se obávat malwaru? nebo je to bug ve Firefoxu na Linuxu?

až se to znovu stane, udělám screenshot, zapomněl jsem