Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Michal Šmucr

Stran: [1] 2 3 ... 36
1
Hardware / Re:Zvukovka Behringer 1820 se 7.1 na Kubuntu 24.10
« kdy: 21. 03. 2026, 13:53:14 »
Není vůbec zač.

Jen jak to teď po sobě čtu, tak se musím ještě opravit. Jak jsem psal o tom, že plughw:HDSPMxcb26e5 zařídí konverzi formátu a počtu kanálů přes plugin, tak ten zápis bez konverze je samozřejmě hw:HDSPMxcb26e5 a ne jen HDSPMxcb26e5, překlep - omlouvám se.

Ještě dodám, že vícekanálová virtuální PCM zařízení, co si takhle definujete v .asoundrc, jdou případně používat ve většině aplikací, které mají přímo výstup přes ALSA rozhraní.
Jen se typicky neukazují v těch rozbalovacích seznamech v UI. Takže se musí většinou přímo specifikovat v příkazu, nebo napsat do nějakého configu aplikace.
Další zádrhel, co se týká hlavně obecných přehrávačů, je v tom, že to směruje přehrávané audio podle metadat s kanály (L, R, C, Ls.. atp.), které u těchhle virtuálních rozhraní nejsou.. Za normálních okolností tohle dodá PipeWire nebo PulseAudio.
Podobně pak, když je těch kanálů ve wavu víc a nesedne to přehrávači heuristikou do žádného známého layoutu (5.1, 7.1 atp.).

Takže třeba u VLC bych to přehrál asi takhle. To 4967 není počet kanálů, ale jeho interní ID pro layout 7.1, je tam enum, a hodnoty se dají zjistit, když pustím vlc -H.

cvlc -A alsa --alsa-audio-device virtual --alsa-audio-channels 4967 ./audio-8ch.wav

U mpv je pak volba --alsa-ignore-chmap, co to pak vypne mapování podle logických kanálů a pustí to tam 1:1.

mpv --audio-device=alsa/virtual --audio-channels=auto --alsa-ignore-chmap ./audio-8ch.wav

Zmiňuji tyhle přehrávače proto, že se je někdy hodí použít i pro podobné účely jako u vás.
Třeba pro automatizované přehrávaní videí nebo zvuků, kdy to můžete řídit z venku.
Oba zmíněné přehrávače mají možnost povolit rozhraní na posílání příkazů.. ať už přes unix socket nebo named pipe na Windows, případně u VLC je tam i TCP server s telnet like rozhraním.
Takže se dají spustit jako služba a pak z nějaké řídící aplikace (napsané např. v Pythonu) posíláte jen příkazy pro ovládání playlistu, přehrávání atp.

2
Hardware / Re:Zvukovka Behringer 1820 se 7.1 na Kubuntu 24.10
« kdy: 20. 03. 2026, 01:39:47 »
Nejjednodušší varianta je k tomu přistupovat přímo přes konkrétní ALSA zařízení.
Bude to fungovat i na nějakém minimálním headless RPi bez grafického rozhraní, stačí mít nainstalovanou knihovnu ALSA libasound2 a alsa-utils + přímé závislosti.

Pokud to zkoušíte na nějakém stroji s DE (KDE, GNOME), bude nad tím sedět ještě pravděpodobně další vrstva - PipeWire (audio server) spolu s WirePlumber (nástroj pro její dynamickou konfiguraci). Pokud nějaká typická GUI aplikace (VLC, prohlížeč, DAW) používá audio zařízení, tak ve výchozím stavu přistupuje na právě přes PipeWire server. Buď nativním rozhraním nebo přes emulaci (PulseAudio, JACK, emulované ALSA rozhraní).
Za normálních okolností to ale to, že je to zařízení mimo ALSU napřímo přístupné také přes PipeWire, nemusí vůbec vadit. Protože pokud v tu chvíli nebude mít žádná aplikace zařízení aktivně otevřené (přehrávání, nahrávání) přes PipeWire, tak je normálně použitelné  rovnou přes ALSU.
V nejhorším se dá také udělat pravidlo ve WirePlumberu, kde se zařízení pro PipeWire kompletně zakáže. Ale jak jsem zmiňoval, nebývá to nezbytně nutné a v případě headless RPi, tam tyhle další vrstvy vůbec nemusíte mít.

A teď jak tam přehrávat vícekanálový wav.

Nejdřív si vypíšu názvy ALSA hw zařízení přes příkaz: aplay -l

mám např. vícekanálovou PCIe zvukovku, která má název: HDSPMxcb26e5

card 2: HDSPMxcb26e5 [RME AIO_cb26e5], device 0: RME AIO [RME AIO]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Dá se použít i index (v mém případě: 2), ale název je lepší, protože se nemění při různém pořadí zavádění modulů, připojování USB zařízení atp.

Teď základní test.
speaker-test -D plughw:HDSPMxcb26e5 -c 16

Program pouští testovací šum postupně do všech kanálů v zařízení, v počtu specifikovaném pomocí parametru -c.. (já mám 16 kanálovou zvukovku, a takhle bych otestovat všechny kanály, ale může otestovat klidně jen třeba první 4). Při testu to vypisuje aktuální číslo kanálu.
Důležitý parametr pak je -D, kde se zadává název zařízení. Pokud bych tam zadal pouze HDSPMxcb26e5, tak bych musel mít přesný počet výstupních kanálů a sample formát, který konkrétní zvukovka vyžaduje (např. S32_LE, S24_3LE, jak zmiňoval Redustin atp.).
Ale tím, že jsem před to napsal plughw:, tak se tam automaticky vřadí ALSA plugin, který sample formát převede a počty kanálů automaticky upraví podle výstupního zařízení.

Pokud jsem s tím v pohodě, můžu zkusit zahrát ten vícekanálový (poly) wav. Řekněme, že by měl třeba 8 kanálů..
aplay -D plughw:HDSPMxcb26e5 ./multichannel.wav

Tohle by mi mělo zahrát wav tak, že bude mapování kanálů 1:1. Tzn. zahraje mi to z prvních osmi kanálů na zvukovce (moje má 16), v těch zbylých bude ticho.
Což je jeden ze způsobů, jak k tomu přistupovat. Pokud mi nebude vyhovovat pořadí, můžu si to proházet přímo při přípravě toho wavu (v DAW) a nebo přepojit ty výstupní TRS jacky na zvukovce :)

Pokud bych to chtěl někam posunout (hrát např. z posledních osmi) nebo proházet pořadí, tak to bude vyžadovat vytvoření virtuálního ALSA audio zařízení s dalším pluginem na směrování audio kanálů.

To udělám v souboru ~/.asoundrc (pro aktuálního uživatele), kam přidám např. takovéhle sekce.

Kód: [Vybrat]
pcm.virtual1 {
  type route
  slave {
    pcm "plughw:HDSPMxcb26e5"
    channels 16
  }
  ttable.0.1 1
  ttable.1.0 1
  ttable.2.2 1
  ttable.3.3 1
  ttable.4.4 1
  ttable.5.5 1
  ttable.6.6 1
  ttable.7.7 1
}

V definici slave se přes pcm odkážu na fyzickou zvukovku, úplně stejně jako v předchozích případech.
A následně např. prohodím první dva kanály přes tabulku.
Tam je fomát: ttable.in-channel.out-channel gain
Přičemž gain je jako float multiplikátor (tzn. 1 = beze změny).

Kód: [Vybrat]
pcm.virtual2 {
  type route
  slave {
    pcm "plughw:HDSPMxcb26e5"
    channels 16
  }
  ttable.0.2 1
  ttable.1.3 1
  ttable.2.4 1
  ttable.3.5 1
  ttable.4.6 1
  ttable.5.7 1
  ttable.6.8 1
  ttable.7.9 1
}

V tomhle druhém případě jsem to posunul o dva výstupy.

Když to pak chci zahrát, tak použiju např.

aplay -D virtual1 ./multichannel.wav nebo aplay -D virtual2 ./multichannel.wav

Takže to je v kostce asi všechno. aplay se dá zavolat z Python programu normálně jako systémový příkaz přes modul subprocess.
Možná kdyby to mělo být hezčí, tak bych se asi poohlédnul po nějakém modulu, co umí s ALSA zařízeními pracovat přímo z Pythonu, třeba jako pyalsaaudio (v podstatě wrapper okolo libasound, ale dýl jsem to neviděl).
Čtení PCM wavů je přímo ve standardní knihovně Pythonu.
Udělat z toho nějakou přehrávací funkci, kterou pak můžu volat například z vláken. Což se zas může hodit, jestli to má dynamicky reagovat na nějaké řídící eventy z toho MQTT.. minimálně se to dá nějak zamykat, synchronizovat, lidsky zastavovat přehrávání atd.
Ale samozřejmě, jestli je to nějaká jednorázovka s opravdu základním spouštěním, nemusí to dávat smysl.

3
Jo tohle může být trochu problematický setup se splitterem a dvěma zobrazovači, co neumí stejný režim.
Pokud se to nepřerazí manuálně v nastavení, tak systém většinou použije maximální (resp. preferované) rozlišení a refresh podle EDIDu, co si vyčte z připojeného displeje.
A tam právě nastává obecný problém s těmi splittery, protože se to podle konkrétního kousku pak může chovat různě.
Např. vždy pošle EDID z prvního downstream portu, nebo vždy pošle EDID z prvního zařízení, které je ready nezávisle na portu. Záleží to i na firmware v tom splitteru. Takže se to může chovat trochu nepredikovatelně.
Asi bych s tím trochu zaexperimentoval, třeba otočil mezi sebou výstupy do redukce (do projektoru) a LCD montor.
Případně to zapojoval v určitém pořadí a díval se, jak se to bude chovat.

Ale k dotazu.
Novější verze GNOME (výchozí DE na Fedoře) mají nástroj gdctl, kterým se dají měnit rozlišení a frekvence připojených monitorů, layout u více monitorů atp. z terminálu nebo skriptu. Ovládá to přímo Mutter.

ukázat režimy (přečtené z EDIDu)
gdctl show --modes   

nastavit monitor na fyzickém výstup HDMI-1 (příklad, nevím jak se to tváří u vás)
gdctl set --logical-monitor --primary --monitor HDMI-1 --mode '800x600@60.000'

viz
https://gitlab.gnome.org/GNOME/mutter/-/blob/main/doc/man/gdctl.rst

4
Sítě / Re:SSH nelze připojit přes SOCKS5 proxy
« kdy: 28. 02. 2026, 21:20:30 »
Netcat může být v distribucích ve více variantách. Ten port z OpenBSD, pak GNU netcat, další je z projektu Nmap a jmenuje se Ncat a nakonec třeba implementace v Busyboxu.

Ve Fedoře, RHEL atp. je to právě ten zmíněný Ncat
Ten má pro proxy odlišné parametry:
--proxy host:port
--proxy-type socks5


5
Software / Re:Hardwarový video decoding na Firefoxe
« kdy: 20. 02. 2026, 19:10:49 »
Už jste si na to vše v podstatě přišel.

NVIDIA používá své NVDEC API, ale Firefox i Chrome/Chromium based prohlížeče používají VA-API. Takže musí být v systému nainstalovaný wrapper.
Např. ve Fedoře se ten balíček jmenuje libva-nvidia-driver a samotná knihovna je v /usr/lib64/dri/nvidia_drv_video.so.
Další překážka je, že ve Firefoxu je to nějakou dobu ve výchozím stavu na blacklistu (lze přerazit přes media.hardware-video-decoding.force-enabled).
Třetí překážka je, že Firefox pouští separátní dekódovací proces v sandboxu, co se na to nedostane, dokud se nenastaví proměnná MOZ_DISABLE_RDD_SANDBOX.
To by mělo zabrat ve standardním Firefoxu.

U Flatpak verze (většinou ji používám na distribucích, co mají v systému starou ESR verzi) je tam pak ještě další zádrhel.
Firefox z Flathubu je sestaven proti runtime z branche 24.08, kdežto dostupný runtime s wrapperem (org.freedesktop.Platform.VAAPI.nvidia) je jen v branchi 25.08.
Dá se to obejít tak, že se zkopíruje knihovna wrapperu ze systému, aby ji flatpak našel.

např.
Kód: [Vybrat]
# zkopírovat ten VA-API wrapper do adresáře, kam může Flatpak
mkdir ${HOME}/.var/app/org.mozilla.firefox/data/dri/
cp /usr/lib64/dri/nvidia_drv_video.so ${HOME}/.var/app/org.mozilla.firefox/data/dri/nvidia_drv_video.so

# přenastavit proměnné flatpaku
flatpak override --user --env="LIBVA_DRIVER_NAME=nvidia" --env="LIBVA_DRIVERS_PATH=/home/${HOME}/.var/app/org.mozilla.firefox/data/dri" --env="MOZ_DISABLE_RDD_SANDBOX=1" org.mozilla.firefox

ve Firefoxu pak nastavit v about:config
media.ffmpeg.vaapi.enabled=true
media.hardware-video-decoding.force-enabled=true

Pro rychlou kontrolu, jestli to běží, se stačí podívat do about:support, případně spustit třeba HEVC video
https://lf-tk-sg.ibytedtos.com/obj/tcs-client-sg/resources/video_demo_hevc.html#main-bt709-sample-11
a podívat se na nvidia-smi:
nvidia-smi dmon -s u
Jestli je to aktivní, tak to ukáže nějaké vytížení ve sloupci "dec".


6
Server / Re:TrueNAS CE se náhodně restartuje
« kdy: 03. 02. 2026, 01:01:42 »
Omlouvám se, ale v tom mailing listu Debian Bugs jsem přehlédl, že se ta odpověď s verzemi vztahuje k jinému bugu.. moje blbost, když jsem dal "Next by thread" a nezkontroloval si číslo :(

Stran těch možností, co vyzkoušet za kernel parametry. Popravdě těžko říct, protože víceméně všechno, co se vztahovalo k souvisejícím hlášením, kde byly celé backtracy, už víceméně vyzkoušel tazatel z vlákna, co odkazoval RDa.
https://forums.truenas.com/t/hp-proliant-microserver-gen8-instable-on-v25-ok-on-v24-and-debian12-kernel-issue/52905
Jsou tam pokusy s vypínáním iommu, max cstate na 1 i blokováním modulu hpwdt (iLO NMI watchdog ovladač).. A evidentně mu nic nezabralo.

Jinak, trochu jsem si osvěžil aktuální verzi TrueNAS CE instalací do virtuálu. Viděl jsem jen verze pár let zpět.
U té 25.10 (Stable) je skutečně 6.12.33..
Z 25.10 (a nejspíš i 25.04) se dá poměrně snadno dostat na aktuální vývojový snapshot, kde je jádro 6.18.
Buď se dá stáhnout ISO z https://download.truenas.com/truenas-scale-halfmoon-nightly/ nainstalovat na jiný disk a natáhnout uloženou konfiguraci.
Nebo to umí i inplace upgrade, co se chová velmi mravně.
- stačilo v Updates přepnout kanál aktualizací na Developer, hned se nabídla aktualizace.
- dál jsem nastavil v Settings > Boot, aby vždy nechal stávající Boot Environment (Keep) a nikdy to nemazal.
- pro jistotu jsem si ještě zastavil všechny testovací virtuály, aplikace a udělal ručně snapshoty z té datové části.
- pak proběhl relativně rychle update, který tu dev verzi nainstaloval do nového BE a restartoval server.
- tvářilo se to v pohodě, notifikaci o možné aktualizaci s novými ZFS feature flags jsem ignoroval, kvůli návratu zpět.
..
Cvičně jsem zkusil revert, v Settings > Boot jsem jen nastavil ten BE s předchozí verzí jako aktivní.
Opět reboot, byl jsem zpátky se systémem i všemi službami. Snapshoty té datové části nebyly vůbec třeba.

Takže to je asi nejjednodušší cesta jak případně vyzkoušet vývojovou verzi s novým jádrem.. Byť samozřejmě netuším, jestli tam ta regrese pořád je a jak se to bude u vás chovat. Ale možná to za pokus stojí, přinejhorším se vrátíte.

7
Server / Re:TrueNAS CE se náhodně restartuje
« kdy: 02. 02. 2026, 14:23:47 »
Nema nikto v prevadzke nejaky HP gen8 s nejakym novsim debianom a nestretol sa s podobnym problemom?

Bohužel, to se omlouvám, vždycky jsem na těch Microserverech měl jen FreeBSD nebo RHEL klony. Oboje bylo stabilní a víceméně bez problémů.
Také tenhle poslední kus, co je v provozu, tam má jiné CPU (Celeron místo Xeonu), takže nevím do jaké míry by ten případný test průkazný.

Citace
Ako otestujem s minimalnym usilim, ze ten problem pod Proxmox nebude? Dam Proxmox na ine ssd a nepripojim tie disky na ten SAS controller? Pri FreeBSD problemy neocakavam, len to by som si dal najskor do nejakeho virtualu na desktope, aby som si to nejako poskusal, lebo nechcem mat dlhy vypadok NASu. Este je moznost "prezit" nejakym sposobom do aprila, kedy vyjde TrueNAS 26.04, ten by mal mat jadro 6.18.

Jak jste posílal to vlákno z debian bugs ML, tak vypadá, že to je skutečně nějaká regrese.. předchozí 6.1 mu nemrzlo. A u Debianu to vypadá, že by tam měl být fix od 6.12.41 dál.
https://lists.debian.org/debian-amd64/2025/08/msg00015.html

Jestli už tohle jádro také je v TrueNASu, nedokážu teď rychle zjistit. Ale dá se předpokládat, že by to tam někdy mělo doputovat.
Možná by se dala dohledat i konkrétní změna u Debianu, a pak prohrabat nějaké committy u TrueNASu. (mají všechno ve větvích na GitHubu)
https://github.com/truenas/linux

Jinak jak jste se ptal, tak minimální úsilí by za mě asi bylo udělat zmíněný zfs export v TrueNASu. Odpojit původní SSD a odložit ho, vzít nějaké plonkové SSD na test a nainstalovat na něj PVE (nebo třeba novější Ubuntu se ZFS modulem, pokud vám jde jen o jinou verzi jádra). Ty pooly pak přes zfs import připojit v jiném systému.
Nastavit v Sambě nějaké základní sdílené složky pro základní použití (třeba bez virtuálů zatím, jestli bez nich chvíli vydržíte) a počkat ten cca týden, jestli se to bude také restartovat.
Případně se pak můžete vrátit zas k TrueNASu.. (opět zfs export, import).

Jinak ještě mě napadlo s tím FreeBSD, co tam předtím chodilo. Standardně to nepoužívá vyšší c-states než 1 (do hlubších to nejde, musí se explicitně povolit přes sysctl). Podobně to nemá frequency scaling, pokud se explcitně nezapne služba, powerd_enable="YES" v rc.conf. Jestli tenhle problém nějak souvisí s power managementem u Intel CPU, jak nadhazovali v tom vlákně, tak je klidně možné, že ve FreeBSD to prostě vůbec není zapnuté.. Ale to je jen teď taková rychlá úvaha.

8
Server / Re:TrueNAS CE se náhodně restartuje
« kdy: 02. 02. 2026, 12:50:00 »
Ahoj, zmíněný Gen8 taky někde mám, a můžu potvrdit ten problém s eMMC u iLO. Je tam asi 6 let, krom té periodické chybové hlášky a nemožnosti aktualizace FW to nemá bohudík žádný vliv na stabilitu serveru.. provozuju to už roky bez jiných problémů s čistým FreeBSD jako NAS.

Ta nemaskovatelná přerušení jsou divná, pokud by to byl skutečně symptom nějakého HW problému např. s deskou, pak by se to mělo projevovat víceméně úplně stejně napříč všemi systémy.
Pokud se výsky dá vysledovat čistě po přechodu na TrueNAS scale, je tam samozřejmě i určitá pravděpodobnost nekompatiblity případně nějaké regrese u které by pak dávalo smysl vyzkoušet jinou verzi jádra, jestliže to projede nějakým HW stress testem.

Jak TrueNAS Scale, tak Proxmox VE staví na Debianu 13 Trixie, ale mají odlišné základní verze jader. U Scale je to LTS kernel 6.12 u PVE pak aktuálně 6.17.
Jedna z možností je tedy, co píše RDa. Tzn. rozběhnout v Proxmoxu virtuál s TrueNASem a poslat do něj celá blok. zařízení s těmi ZFS pooly.
Osobně bych se tomuhle vrstvení spíš vyhnul a radši bych využil ZFS modul v Proxmoxu a nechal si ho spravovat ARC a přímo přistupovat na ta zařízení.
Sdílet pak data ven (NAS část) jde pak u PVE více způsoby, ale prakticky připadají v úvahu dvě varianty. Buď si přímo do hlavního systému doinstalovat Sambu, WSDD, NFS server atp. nebo si rozjet systémový LXD kontejner na sdílení a poslat do něj přímo ty ZFS datasety.
Preferuji tu druhou variantu, která sice není tak přímočará jako přidat pár balíčků do Debianu, ale umožňuje to mít oddělené nastavení, verze jaké chci, můžu to celé verzovat apd. a zároveň to má jako kontejner úplně minimální overhead. Takže prakticky klidně třeba minimální kontejner s Alpine Linuxem a pár službami. Akorát si pak člověk musí dát pozor na to, jak má namapovaná UID a GID mezi hlavním systémem a kontejnerem, když řeší třeba přístupová prává a nastavování ACL (na ZFS datasetu v hlavním systému). Podobně se tam dá rozjet třeba i další kontejner s DLNA serverem atd.
Jinak ty pooly by se měly dát v pohodě vyexportovat (zfs export) v TrueNASu a pak bez ztráty kytičky připojit jako další úložiště v PVE, možná jen při importu upravit mountpoint.
Podobně pak s trochou úsilí použít existující zvoly s disky od virtuálů a připojit je do nově vytvořených virtuálů v PVE. V nejhorším případě to u dvou virtuálů zkusit ručně přetahat přes externí image a nějaké živé distribuce do nově vytvořených VM.

Nakonec je tu určitě i další varianta.. dá se použítvat úplně standardní FreeBSD 15. Jen samozřejmě s tím, že se to spravuje přes konzoli bez UI. Pooly to naimportuje, Samba, DLNA atp. je v balíčcích. Virtuály s Ubuntu a UI kontrolerem se s trochou úsilí dají rozjet s byhve.

9
Hardware / Re:Nový mobil: OnePlus 13 vs. 15 vs. Pixel 10 Pro
« kdy: 11. 01. 2026, 16:26:40 »
stari iP napr jako 15, bys nechtel ? on ten prechod te bude bolet :D

Přesně tak, osobně pokud bych neměl nějaký specifický důvod pro změnu platformy a byl bych víceméně spokojený až na starší hardware, zůstal bych na iOSu, už třeba jen kvůli oblíbeným koupeným nebo vestavěným aplikacím od Apple.
Pokud člověk vyloženě nespěchá nebo mu to není jedno, tak se často objeví možnost koupit buď minulý model nebo vrácený/lehce používaný kus. Zrovna u iPhonů se to docela točí a starší modely nebývají moc problémové kvůli solidní době podpory. Jinak z iPhone 11 může být v pohodě upgrade i na 16e (v podstatě nástupce SE), který je lacinější i nový.

Osobne kupujem len Moto a Pixel fóny. S oboma mám pozitívnu skúsenosť.

Taky tak, dobrá zkušenost s oběma výrobci. Za posledních pár let téměř všichni z rodiny okolo, co měli Androidy, přešli na Moto, a víceméně spokojenost. Pixel taky fajn.

Akoze iphone ma nasral uz viackrat, od kopirovania suborov, fotiek, odpajanie od pc (windows), prestali chodit z kalendara notifikacie, ktore mam nastavene raz rocne.

Obě platformy mají aspekty, co dokážou naštvat. Ale koneckonců uvidíte sám.
S nárazovým kopírování fotek do PC přes USB kabel do Windows (s iTunes a službami, co zjeví DCIM složku v průzkumníku) jsem zrovna na žádný problém nenarazil, ale upřímně to moc nepoužívám, protože se pohybuju i mezi spoustou různých počítačů s Linuxem. Kabel používám víceméně jen na nabíjení.
Fotky pak stahuju přes webové rozhraní iCloudu a pak to z něj zároveň vyčistím (mám jen základní free tarif). Nebo když jsem v domácí síti, tak se prostě připojím přes WiFi na SMB share z vestavěné aplikace Files a překopíruju si z a do telefonu, co chci.
Notifikace také fungují (ve vestavěném kalendáři mám zrovna všechny narozeniny). Schůzky atp jdou z jiného Google účtu a další appky.

10
Software / Re:Conky monitoring teploty CPU a GPU
« kdy: 10. 01. 2026, 23:40:42 »
Není zač, mám také radost, jestli jste to rozchodil. Mějte se.

11
Software / Re:Automatické přehrávání videí v prohlížeči
« kdy: 10. 01. 2026, 16:49:34 »
U Chromu/Chromia je to celé komplikovanější, je tam heuristika, kdy se vyhodnocuje i to, jestli má element nastavený mute na zvuk (pak se blokování autoplay neaplikuje), případně se tam ještě řeší MEI (Media Engagement Index), kdy se bere dál v potaz ještě velikost videa, interaktivita uživatele, jestli už na té stránce předtím byl a něco pustil..
https://developer.chrome.com/blog/autoplay
Popravdě u Edge nevím, jestli si tohle všechno zdědil z Chrome/Chromia, nebo tohle chování nějak upravili.

Když jsem to před pár lety někde řešil, tak za mě se k tomu mnohem líp postavili v Mozille a u Firefoxu, když se nastaví v about:config
media.autoplay.default = 5 (automaticky blokuj pokus o spuštění audia i videa)
media.autoplay.blocking_policy = 2 (musí se explicitně kliknout na spuštění)
Tak to fungovalo v pohodě, resp. tak jak jsem čekal.
V nastavení je pak ještě i whitelist, třeba pro YouTube, Spotify (nebo kde to člověk všude naopak chce povolit).

12
Software / Re:Conky monitoring teploty CPU a GPU
« kdy: 10. 01. 2026, 13:03:08 »
Zkusil bych k těm parametrů z hwmon přistupovat ne přes číslo toho modulu, které se může měnit podle pořadí zavádění, ale podle jména toho modulu.
viz https://conky.cc/variables#hwmon

Tzn. počítám, že jméno modulu bude v tomhle případě nejspíš thinkpad.
Pak bych to upravil na "${hwmon thinkpad temp 1}°C"
Jména modulů se pak dají jednoduše zjistit, u mě tohle pak hodí např.:
Kód: [Vybrat]
msmucr@msmucr-desktop:~> cat /sys/class/hwmon/*/name
amdgpu
acpitz
coretemp
Tzn. mám AMD grafiku, standardní ACPI sensory a Intel CPU přes zmíněné moduly. Který senzor z daného modulu pak chci, určím tím indexem za typem (fan, vol, temp).

Třeba to klapne, nemám Thinkpad.. :)

13
Sítě / Re:Wi-Fi pro dvoupatrový dům
« kdy: 06. 01. 2026, 13:11:09 »

Dá se to manageovat vzdáleně, ale přes tu zmíněnou appku, která pak komunikuje to přes TP-Link cloud a dají se případně delegovat další přihlášení (TP-Link účty). Unifikovaná appka pro celou řadu Deco je prakticky jediný způsob nastavování, tzn. žádné web gui mimo základního statusu. Chápu, že pro někoho může být tenhle aspekt konečná.

Appka nieje jediny sposob nastavovania.
Deco ma aj web gui. Mal som v rukach viacero podobnych mesh systemov a vsetky mali aj web gui, len rovnako ako Tp-Link to nikde nepropagovali.

https://www.tp-link.com/us/support/faq/2641/

Nevím, jestli se něco nezměnilo v posledních firmwarech, nicméně moc bych na to nesázel.
V nižších řádách E a M to web UI nebylo vůbec a u Xka, když jsem to onehdá zkoušel po nějakém FW updatu, tak to moc k ničemu nebylo. Dostal jsem se na to z nějakého důvodu pouze v router modu (dobře to mohl být nějaký úvodní bug, nicméně já to měl všude v AP modu).
Navíc tam byl víceméně pouze zmíněný status, aktuální klienti na síti a FW update.
Viz https://community.tp-link.com/en/home/kb/detail/412520

Takže za mě je pro správu Deco řady prostě vždy potřeba zmíněná appka.
Ta s ním komunikuje z venku přes cloud, z WiFi sítě nejspíš přes nějaké discovery a neveřejné API, na úvodní nastavení přes Bluetooth.

TP-Link má vyšší Omada řadu APček, které jsou pro podnikové použití a ovládáním je to podobné třeba Ubiquity nebo ostatním podobným systémům. Kontroler běží jako služba na serveru nebo na jejich dedikovaném hardware v síti (krabička).
U Deca je to v rámci zjednodušení redukované na appku. Jak jsem psal, pokud tohle někomu vadí, nejspíš to nebude ideální volba. Mě to na uvažované, domácí použití nepřišlo za ty peníze úplně zásadní a zatím to dobře slouží.
V době, kdy jsem to řešil (okolo Covidu a následně když se spoustě známým rozjely HO, takže chtěli lepší domácí WiFi), tak to byla jedna z mála dostupných a funkčních voleb pro roaming, dobré pokrytí a ideálně s jednoduchým ovládáním (spousta lidí s to rozběhla sama, aniž by měli nějaké zásadnější znalosti o síťování).
Ubiquity bylo dražší, vyžadovalo kontroler. Mikrotik byl peklo na nastavení a spousty funkcionality bylo vázané na jejich nové hw platformy (Wifiwave2, wifi-qcom), pro které zdaleka neměly tolik dostupných produktů.
Teď už je toho samozřejmě mnohem víc.

14
Sítě / Re:Wi-Fi pro dvoupatrový dům
« kdy: 06. 01. 2026, 02:11:24 »
Ja si totiž kdysi rád hrál, ale teď na to nemam čas. Kolegové sice lejou prachy do domácích sítí, ale mě to nebere.

Asi to dopadne, že vezmu z Alzy ty deco x55.

Dá se to managovat vzdáleně?
Dá se to managovat přes web GUI nebo musí ten výrobce do nekonečna aktualizovat mobilní apku?

Dá se to manageovat vzdáleně, ale přes tu zmíněnou appku, která pak komunikuje to přes TP-Link cloud a dají se případně delegovat další přihlášení (TP-Link účty). Unifikovaná appka pro celou řadu Deco je prakticky jediný způsob nastavování, tzn. žádné web gui mimo základního statusu. Chápu, že pro někoho může být tenhle aspekt konečná.

Osobně tohle pro podobné domácí sítě v pohodě zkousávám a furt mi přijde, že to má velmi dobrý poměr cena/výkon, chodí to pro tohle použití dobře a cca od r. 2020 jsem zatím s žádnou sadou (cca 5 míst) neměl zásadnější problémy,  další lidé, kterým jsem to doporučoval, také nic nehlásili. Appka jak pro iOS, tak Android je poměrně často aktualizovaná, chodí na ní pořád i nejstarší řady.

15
Software / Re:MP3 editor/katalog/tagger pro Linux + Windows?
« kdy: 21. 12. 2025, 23:40:43 »
Jo, to vypadá slibně. Zkusil jsem na jednom vánočním albu, a chytlo se to. (V podstatě jsem jen změnil "Weinachten" na "Christmass", protože němčinou nevládnu.)

Bohužel podobné automatické překlady jako všechny Vánoce na Christmas to přímo nepodporuje.

Ale je tam možnost automatického výběru přeloženého jména umělce, pokud existuje v databázi.
Je to v nastavení Metadata -> Translate artist names.. následně tam jdou i případně vyloučit určité abecedy, tzn. např. nedávej přeloženou verzi, pokud bude jméno umělce latinkou.. (jinými slovy přelož pokud bude azbukou, hanghulem, katakanou atp.)
V podstatě to pak použije aliasy z metadat.. např.
https://musicbrainz.org/ws/2/artist/519dd32e-8f30-4380-8826-7aa99169e1bb?inc=aliases

Citace
Pokud už tam máte nějaké částečně tagy, tak pokud tam hodíte např. desítky adresářů, použijete funkci Cluster (aby se vám to spojilo do alb) a následně by pro většinu měl zabrat čistě Lookup.
Asi půjdu zhruba stylem album po albu. Obávám se, že větší balíky bych nebyl schopen ohlídat.

Toho bych se nebál i ve větším množství. Pokud to nic nenajde, alba zůstanou jen nepřiřazené v levé části. Pokud přiřazené album označíte, tak jsou tam vždycky vidět původní a nové (ještě neaplikované) tagy z db. A nic se neděje, dokud přiřazená alba neoznačíte a nezmáčknete ctrl+s.
Navíc to má vestavěný přehrávač, v pohodě se to dá ověřovat i takhle.

Stran: [1] 2 3 ... 36