• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    FROORaspberry Pi - miniaturní počítač za 35$
    RAINBOF
    RAINBOF --- ---
    SPM: me napadla jedna vec, mrkni do /proc/id procesu/fd zda se ti tam nezvetsuje pocet odkazu.
    SPM
    SPM --- ---
    SUK: To je zajímavej nápad. Vnuklo mi to jednu myšlenku. Jak jsem zkoušel, tak to přehrávání obrázků umí vyloadovat i ten můj notebook, když těch kamer otevřu X... Takže to schválně zkusím, protože tímhle bych si mohl to stahování obrázků vyrobit na nějakém lepším hardwaru, kde mám i slušný CPU a do maliny stahovat už jenom video stream, který bude akcelerovaný. (A alespoň uvidíme, jestli se mi ten memory leak objeví někde jinde :-D )
    SUK
    SUK --- ---
    SPM: co takhle mplayerem prehravat stream، ktery bude tvorit ffmpeg z tech stahovanych obrazku?
    SPM
    SPM --- ---
    Díky všem, jdu se tím postupně nějak prokousat, jestli se mi u něčeho z toho zadaří něco najít. Samotné googlení na mplayer nepřineslo nic zajímavého. (Zatím jsem jako quickfix přepsal ten script tak, že to pouští mplayer v cyklu a cron to jednou za hodinu killne... což je prasárna hrozná, ale přijde mi to v tuhle chvíli lepší, než aby ty lopaty z toho natvrdo tahaly napájecí kabel).
    RAINBOF
    RAINBOF --- ---
    Hele, mrkni na nastaveni swapu, swapiness hodnoty a oom_adj.
    Zrat by ti mohla grafika.
    DURDIN
    DURDIN --- ---
    SPM: napadá mě, že si to mplayer ukládá do nějaké cache, zkus se kouknout na nastavení (-cache/-cache-min). A ještě můžeš zkusit místo mplayeru mpv.
    RUSTU
    RUSTU --- ---
    SPM: Chytat takhle leaky v cizim softwaru a jeste na maline asi nebude snadny. Muzes zkusit testovaci run s valgrindem, jestli se ti ho podari na RPi rozbehat.
    MA747
    MA747 --- ---
    SPM: jen výstřel od boku: hledal bych okolo libjpeg
    SPM
    SPM --- ---
    SPM: jo, zapomněl jsem dodat, že když jsem s nima přehrával ten videostream, tak to tohle nedělalo. Běželo to klidně několik týdnů v kuse, bez problémů. Paměť to začalo žrát až při tom přehrávání jpg obrázku.
    SPM
    SPM --- ---
    Mám takový divoký problém... který asi ani není úplně do tohohle audítka, ale nevím kam s ním jinam :-) Mám na RPi4 postavený zobrazovač kamer. Tedy televize namontovaná někde u stropu, RPi na tom přehrává 9 kusů kamer, je to bezobslužné. Bohužel se ukazuje, že kamery jsou úplně dementní (jenom dopředu dodávám, že to není žádný čínský šmuk, ale je to prosím pěkně pekelně drahá značková kamera) a neumějí posílat žádný videostream. Teda umí, ale všechny videostreamy, co jsem zkoušel, mají asi tak 10 sekund zpoždění a obsluze se to úplně nelíbí (zpoždění na tom streamu mám, ikdyž to pustím z normálního železa). V rámci debuggingu, kdy se tam kolegové furt snaží prosadit nějaký windowsí sráč, protože s originálním klientem to funguje úplně bez problémů, jsem začal pátrat, jak funguje originální klient a/nebo webxicht té kamery, kde ten obraz se chová taky normálně. Mno, tak při otevření v chromu to přehrávání funguje tak, že chrome periodicky stahuje jpg obrázek s aktuálním pohledem a ten zobrazuje. Pokud je tam nastaveno 20fps, tak ho prostě stahuje 20x za sekundu... Ani se pak nedivím, že kameře už nezbývá výkon na to, aby posílala třeba video...

    No nic, rozhodl jsem se adaptovat na tohle debilní přehrávání a přesvědčovat mplayer, aby taky stahoval obrázky. Až jsem dospěl k tomuhle příkazu, který funguje docela hezky:

    player -msglevel all=-1 -loop 0 -fps 1 -idle -fixed-vo -mf type=jpg -x 640 -y 360 -zoom -geometry 0:0 http://ip_kamery/obrazek.jpg

    Problém je, že asi tak druhý den nějaká kamera "spadne"... Když se mi konečně povedlo jim zakázat to natvrdo restartovat, abych zjistil, co s tím je, tak spadnutí vypadá tak, že mplayer zabije OOM killer, protože na malině dojde paměť. A bohužel pohled do topu ukazuje, že za a) mplayery žerou hrozně CPU (ale nevím, možná je to normální, když takhle blbě stahuju obrázky na kalkulačce... to bych tomu prominul, stíhat to jinak stíhá), ale taky že za b) žerou fakt hodně paměti a časem boptnají... Takže ta 2GB verze je asi po 24 hodinách out of memory, u té 4GB se to tak rychle nestane, ale o pár dní později ji to dostihne také.

    No a teď ještě ta divnější věc: pustil jsem si schválně jednu kameru na notebooku, stejně. A tam mi ten mplayer prostě neboptná, paměť nežere skoro žádnou. Schválne přikládám screeny z aktuální maliny (ráno rebootnuto, takže takhle to vypadá po ~ 8 hodinách běhu... před restartem byly už 2 mplayery zabité OOM killerem a paměť se "swapem" plná) a z notebooku, kde mi to běželo asi 3 hodiny. Abych nekecal, tak na notebooku jsem zapomněl ten parametr -msglevel all=-1 (bez něj se na RPi, jak je to puštěné z ~/.xsession, ten výpis mplayeru ukládal do syslogu a za chvíli tomu došlo místo na kartě); nicméně pustil jsem to teď chvíli z něj a prostě v topu to pořád bere +- stejně, nevypadá, že by to rostlo...

    Čímž mi nějak dochází nápady, proč mi to na RPi žere paměť a na normálnim PC ne... Někdo nějakej nápad? :-)

    TR1
    TR1 --- ---
    TR1
    TR1 --- ---
    NYRLEM:
    Ja mel to stesti, se ty UUgeary jsou skladem. Me spis slo o to, ze majitel firmy se fakt snazi a slogan "reklamace vyresime do tri pracovnich dnu" nejsou jenom prazdna slova, jak to mnohdy vidime jinde. Bohuzel spousta HW je nedostatkove zbozi a s tim asi majitel uz mnoc neudela.
    NYRLEM
    NYRLEM --- ---
    TR1: ja cekam na rpi400 co nebootuje z karty uz mesic..
    TR1
    TR1 --- ---
    Musim pochvalit rpishop.cz. Ve stredu zjisten vadny UUgear, elektronicky vyplnena reklamace a na ctvrtek objednan svoz. Dnes je utery a novy UUgerar prave pristal na stole. Kez by vetsina veci sla tak rychle a hladce.

    Jeste pridam tohle, pokud to nekoho minulo:
    Nadupaný malinový server. Malá deska obsahuje šest Raspberry Pi a pojme stejný počet SSD – Živě.cz
    https://www.zive.cz/clanky/nadupany-malinovy-server-mala-deska-obsahuje-sest-raspberry-pi-a-pojme-stejny-pocet-ssd/sc-3-a-218002/default.aspx
    RAINBOF
    RAINBOF --- ---
    TOOMIX: ted aby to bylo bezne dostupny a nemuselo se to obednavat pri mesicku z nejakeho special eshopu mimo EU
    MIKESHCZ
    MIKESHCZ --- ---
    Ahoj, nevíte někdo náhodou kde sehnat CM4 s WiFi? Velikost úložiště a paměti je jedno. Nebo nemáte asi někdo nevyužitý v šuplíku?
    HARVIE
    HARVIE --- ---
    QWWERTY: zadnej opensource jsem nenasel. a uz vubec nic co by fungovalo s androidem i applem. i kdyz na apple jsem mel uxplay co docela makalo, jenze se mi nedarilo to pustit zaroven s kodi, ktery si drzi vyhradni pristup ke zvukovce a prekonfigurovat raspbian na pulse/pipewire se mi nepodarilo, tak jsem to odlozil na pristi update. i tak to ale neni nahrada chromecastu.

    GitHub - FDH2/UxPlay: AirPlay Unix mirroring server
    https://github.com/FDH2/UxPlay
    QWWERTY
    QWWERTY --- ---
    btw zkousel jste nekdo replikovat chromecast?
    ted jsem testoval raspicast, zvladne to castovat obsah z maliny a z telefonu, ale zaboha to nemuzu dokopat, aby castoval i youtube
    monza souvisi s toouhle issue https://github.com/HaarigerHarald/raspicast/issues/4


    normalne bych asi koupil chromecast, protoze mensi srani se s tim, ale zajimalo me, jak moc je to technicky mozny
    takze spis jenom ze zvedavosti, jestli jste to nekdo zkousel taky
    TR1
    TR1 --- ---
    TR1:
    Tak tohle mi hlava nebere, nakonec za nefunkcni lan nemohla zadna aktualizace. Problem zpusobyl odchazejici UUGear, ktery jsem jeste nez uplne chcipnul, stihl prekopirovat na klasickou mSD. Zivotnost UUGearu je tedy pomerne zklamani, mel jsem ho priblizne 9 mesicu a zrovna tenhle kousek nebyl pouzivan nijak casto. To jsem zvedavej, jak dlouho vydrzi druhy UUGear, ktery bezi nonstop s kontinualnim zapisem.
    CERMI_FOX
    CERMI_FOX --- ---
    ZBYNEK: nemá PoE, musel bych použít externí splitter, ale tomu bych se rád vyhnul, chci to mít jako jednu kompaktní krabičku
    ZBYNEK
    ZBYNEK --- ---
    CERMI_FOX: odroid?
    Kliknutím sem můžete změnit nastavení reklam