Příspěvky

196

Software / Re:Kazi se archivy 7z ?

« kdy: 05. 05. 2017, 21:23:07 »

Jine soubory pokazene nemam.

Jak to poznáš? Některé soubory mají uvnitř checksumy, ale u spousty na první pohled nějaký jeden bitflip uprostřed vůbec nepoznáš.

Jako že zkopíruješ funkční archiv a na kopii to řekne, že to není archiv? Porovnej SHA256 hashe těch souborů a pak to binárně diffni… (předtím se možná vyplatí zahodit pagecache, echo 3 > /proc/sys/vm/drop_caches)

Kdyz dam kontrolu vsech archivu, tak to hodi porad ty same chybne (pravdepodobne chybne od vytvoreni pred cca 2 roky). Kontrola archivu by mela chyby odhalit. Kdyz zkopiruju funkcni archiv, porad je funkcni a soubory se binarne nelisi.

Naopak archiv, ktery ma chybu, tak ma chybu i na jinych mistech (zalohy). Muselo dojit k chybe pred 2 lety, na jinem PC, pred presunem na externi disk.

Zaheslovani neni chyba, to proste 7z napise spatne heslo. Jinak pri rekurzivni kontrole 7z t slozka/ to bere jako archivy vsechny soubory, bez ohledu na priponu. Tedy kdyz se u archivu zmeni pripona na avi, stejne to pozna ze jde o archiv a testuje to jako archiv (mimo jine zmenou pripony archiv, byt zaheslovany se rovnez neda ukryt).

Naopak u souboru,ktere archivy nejsou se to snazi otevrit jako archiv a hodi to hlasku, chyba, soubor neni archiv, bezohledu na priponu.

Rekurzivni kontrolu umi jen novy 7z (z roku 2016) , starsi verze ne.

197

Software / Re:Kazí se archivy 7z?

« kdy: 05. 05. 2017, 21:08:52 »

Mohu-li se zeptat, jestli ta úspora byla tak významná, že to stálo za to komprimovat s tak extrémním slovníkem, že mohla dojít paměť.

Uspora je jak kdy, podle typu dat a rozsahu podobnosti. U velkeho mnozstvi souboru je uspora 1024 MB slovnik oproti 64 MB slovkik 10-30 %, vyjimecne i 70% u specifickych dat. V naproste vetsine pripadu je vysledny archiv mensi minimalne (1-5 %), u obrazku pod 1% . Ale pamet by dojit jen tak nemela, i kdyz v par pripadech asi ano, pricina muze byt i jinde. Hlavni chybou je nedumyslna kontola dat.

Ad. Lol Phirae spamer. Tazatel na dotaz nesere, jen su nevsiml, ktere prispevky jsou nove.

198

Software / Re:Kazí se archivy 7z?

« kdy: 05. 05. 2017, 11:21:18 »

7z a -t7z -m0=lzma -mx=9 -mfb=273 -md=1024m -ms=on JmenoArchivu.7z

Podle man lzma (viz CompMem; je to sice LZMA2, ale myslím, že to sedí i na 7z) je skutečná spotřeba paměti při kompresi asi desetinásobek velikosti slovníku -- určitě bylo na stroji, kde se to komprimovalo, 10GB RAM? Pokud ne, tak to po zkomprimování příslušně velké části vstupu (něco jako velikost RAMky děleno deseti) zhavarovalo na nedostatek paměti.

RAM je dostatek, LZMA pri tomto slovkiku vezme 10,7 GB RAM, LZMA2 o neco mene (rozdil je tusim jen okolo 100-200 MB), celkem cca 11x nasobek slovniku. K dispozici je 16 MB RAM nebo i 32 GB RAM tak se to vejde OK (pri 16 GB RAM to zabere 67%). K tomu se ale jeste pricte filelist, coz je okolo 1-2 GB na milion souboru. Az na par extremu se to vejde vzdy i do tech 16 GB.

199

Software / Re:Kazí se archivy 7z?

« kdy: 05. 05. 2017, 11:15:57 »

Proč by to nemělo jít poznat? Ať před nohup nebo ne, tak to vrací nějaký exit code:

Kdyz poustim nohup, tak je to proto, ze terminal-putty muzu zavrit a proces bezi dal. Pak se da vystup najit v nohup.out, pokud to nepresmeruji jinam (do /dev/null/)

200

Software / Re:Kazí se archivy 7z?

« kdy: 04. 05. 2017, 18:45:12 »

A kdyz to jede prez nohup, neni poznat nic.

Proč by to nemělo jít poznat? Ať před nohup nebo ne, tak to vrací nějaký exit code:

No jo, kdyz uz si clovek myslel, ze skript funguje OK a presmeroval nohup dp /dev/null . Bez presmerovani jde vystup do nohup.out . On je ten soubor nekdy i docela velky a presmerovani do /dev/null setri systemove prostredky.

Mozna tam i nohup.out byl, ale pak jsem ho smazal s tim, ze vse je OK. Malokdo si zalohuje vystupy z terminalu.

201

Software / Re:Kazí se archivy 7z?

« kdy: 04. 05. 2017, 16:45:41 »

kdyz komprimuje, tak pise do stejne pojmenovaneho, ale rozpracovaneho nedokonceneho souboru nebo ma pracovni jmeno? jestli jo, tak to bude nepoznatelny, kdyz to zabije oom, tak to neni vada 7zip, ale spravce.

Pravdepodobne to bude cele reseni. Pri vytvareni archivu nejak dosla pamet, coz se muze stat nahlym spustenim jineho procesu navic, i kdyz by pamet dojit nemela. &z pak pri vycerpani RAM padne. A nekdy se nesmaze rozpracovany nedodelany archiv,i kdyz by mel. A kdyz to jede prez nohup, neni poznat nic.

Rozpracovany archiv ma stejne jmeno a neni poznat ze je nedokoncen. Nektera data k  archivu (filelist, typ komprese pod.) se pravdepodobne ukladaji az na konec archivu.

Pri kontrole ve Win32 s nedostatkem pameti (Pri 1024 MB slovniku je potreba je na kontrolu okoko 2,2 GB +Filelist) napsal 7z ze nestaci pamet, a tak jsem archiv ignorovoal, coz byla chyba. Dva zkazene archivy maji okolo milionu suboru, ale dalsi zkazene archivy tolik souboru nemaji.

Opravovat ma smysl mozna jeden archiv, ale asi by to vubec nebylo jednoduche, co jsem hledal.

202

/dev/null / Re:Co je to svet 4.0?

« kdy: 02. 05. 2017, 22:03:56 »

Uz ted se projevuji vazne bezpecnostni chybu (zejmena ze strany uzivatele) a pak nam tu chytre zarovky, kamery, meteostanice, rychlovarne konvice predstavuji silny bootnet.

Co teprve potom.

203

Software / Re:Kazí se archivy 7z?

« kdy: 02. 05. 2017, 21:59:33 »

Konverze CRLF/LF?

O zaheslovane archivy se nejedna. U tech se zepta na heslo, v pripade nohup napise jako chybu spatne heslo (pri nohup neceka na vstup).

204

Software / Re:Kazí se archivy 7z?

« kdy: 02. 05. 2017, 21:57:30 »

ByCzech

To prave spis ne ne - naopak spis zdechne v prubehu. Pamet VIRT si alokuje na zacaatku, a neresi moc, jestli je dostatek. Pamet RES az v prubehu a jak pamet RES stoupa, nekdy v prubehu komprimace proste zdechne.

Taky jsem to vyzkousel, a prave az po urcite dobe, kdy presahne pamet RES volne misto v RAM, to zdechne. Tedy v pripade, ze potrebna pamet je priblizne stejne velka, jako pamet, co je k dispozici. A to jak u stare, tak i nove verze. Hlaska k tomu je uplne stejna.

Kdyz je ale velikost slovniku o dost vetsi, nez co se vejde do RAM. tak to 7zip pozna a zahlasi hned na zacatku, proces se zastavi.

Takze vlastne jak kdy.

Právě jsem to vyzkoušel. Když to přeženu s velikostí slovníku, skončí to hned při startu na tuhle chybu:

Kód: [Vybrat]

ERROR: Can't allocate required memory!

205

Software / Re:Kazí se archivy 7z?

« kdy: 02. 05. 2017, 20:14:17 »

Trumbera

Rozbaleno i zabaleno v p7zip v terminalu. Hacky, carky, mezery a dalsi zvladal dobre. Stejne tak i dost dlouhe nazvy souboru.

Pozkozene archivy maji min. nektere stejne jen alfa-numericke znaky a podtrzitko v nazvu. Nazvy a cesty moc dlouhe nejsou.

Podle vseho chybu odhalil  youarefired

206

Software / Re:Kazí se archivy 7z?

« kdy: 02. 05. 2017, 20:10:53 »

ByCzech

To prave spis ne ne - naopak spis zdechne v prubehu. Pamet VIRT si alokuje na zacaatku, a neresi moc, jestli je dostatek. Pamet RES az v prubehu a jak pamet RES stoupa, nekdy v prubehu komprimace proste zdechne.

207

Software / Re:Kazí se archivy 7z?

« kdy: 02. 05. 2017, 20:08:22 »

 youarefired

Vzdycky skript archiv rozbalil, po rozbaleni byl archiv zkoprimovan a pak byl stary archiv smazan. Data znova zkomprimovany prikazem:

7z a -t7z -m0=lzma -mx=9 -mfb=273 -md=1024m -ms=on JmenoArchivu.7z

Nikdy jsem nezapioval do jiz vytvoreneho archivu jakozto aktualizace archivu, to je relativne riziko.

Chyba spravce to muze byt (server jsem zpravcoval ja).

Jestli psal do stejne pojmenovaneho rozpracovaneho souboru, to tezko rict ted. Ale mozna i ano. Kdyz se proces komprimace ukonci, vetsinou tam zadny soubor nezbyde - stihne ho 7z smazat. (a ne prikazovem radku can't allocate required memory), ale pokud se proces nahle ukonci, muze tam zbyt nedokonceny archiv se stejnym jmenem jako dokonceny (a kdyz poustis prez nohup, tak se to nedozvis).

Takovou chybu by mela odhalit kontrola stejne, i kdyz kontrola zase na Widlich mohla ignorovat souboury s prilis velkym filelist (Widle byli 32-bit)

208

Software / Re:Kazí se archivy 7z?

« kdy: 02. 05. 2017, 19:40:31 »

Jine soubory pokazene nemam. Jsou to jen 7z archivy, moc jich neni.

Na chybu disku to nevypada, protoze jak prekopirovani souboru jinam, tak cteni a zipis na disk jde velice svizne bez problemu. I inkriminovane archivy jde presunout z disku externiho na systemovy disk do home. Presunuti jde bez jakychkoliv zaseku, ale pak pri pokusu otevrit/rozbalit/zkontrolova archiv to zahlasi, ze se nejedna o 7z archiv.

Vse je 64 bitove, proto take lze pouzit velky slovnik. V tom to nebude. Navic takovou chybu by to zahlasilo jako "Can't allocate required memory"

Na jiny disk, pocitac soubory byly presouvany po vytvoreni. Pak ale byl disk zkontrolovan windowsackym 7zipem. Od doby kontroly soubory presouvany nebyli.

Vsechny chybne archivy maji ale jednu vec spolecnou. Byly vytvoreny ve Windows na jinem stroji a pak presunuty do home v linuxu pomoci winscp. U techto souboru ale doslo k rozbaleni a komprimaci v Linuxu s vetsim slovnikem. Takze v tom by byt problem nemel. Ne vsechny archivy puvodne z Widli to delaji, jen par ma chybu.

Navic ze serveru pak byly prez WinSCP vsechny soubory presunuty na externi disk. A to archivy jak puvodne vytvorene na serveru, tak archivy puvodne vytvorene ve windows a predelane v Linuxu. Ted je zase disk zase pod Linuxem.

Zkousel jsem jeden archiv i ze zalohy od jinud, a stejny problem. Na obou mistech pozkozeny ten samy archiv. Aktualnim diskem to nebude.

209

Software / Kazí se archivy 7z?

« kdy: 02. 05. 2017, 12:11:10 »

Zdravim

Zkousel jsem otevrit po delsi dobe (2-4 roky) 7z archiv s vetsim mnozstvim sourobu. 7zip ale zahlasi, ze se nejedna o archiv. Kdyz jsem daval kontrolu cele slozky s velkym mnozstvim 7z archivu, par jich to naslo zkazenych. Jednotli zkazene archivy jsem zkousel otevrit-rozbalit, ale zahlasili mi to, ze se nejedna o archiv.

Pouzivam verzi 7z 16.02 (nove rekurzivni kontrolu cele slozky z archivy, omezila se i zbytecna delka vypisu pri praci). Faktem je, ze uroven komprese pri stejnem nastaveni je u nove verze mensi. Archily byly vytvareny ale starsi verzi 7z-p7zip z roku 2010.

Veskere zkazene archivy byli nejperve vytvoreny ve Windows, pak v Linuxu rozbaleny a zabaleny s vetsim slovnikem.

Divne na tom je, ze i pred lety, v dobe vytvoreni, jsem daval kontrolu archivu. Kontrola probehla uspesne tenkrat a zadnou chybu to nenaslo (tenkrat umel rekurzivni kontrolu jen GUI 7z ve Widlich).

Moznost opravy archivu tady je, i kdyz muze byt pomerne slozita. Vzhledem k slozitosti bude jednodussi vytvorit data znova (tedy az na jeden archiv, se kterym mozna zkusim neco udelat).

================================================================

Stava se vam take obcas, ze 7zip archiv nejde otevrit, hlasi to, ze se nejedna o archiv (tim nemyslim chybu "Can't allocate required memory" kdyz se slovnik nebo filelist nevejde do RAM) ?

Tedy pouceni - obcas se  hodi archivy s dulezitimi daty prekontrolovat a mit vic verzi archivu.

210

Software / Re:Vytvoření AVI videa z obrázků

« kdy: 27. 04. 2017, 16:08:37 »

Vyzkouseno bylo velm mnoho kombinaci, nez jsm dosel k reseni.

Ruzne prejmenovani obrazku, pridani, odebrani casti nazvu a pod. Take byl ruzne zkousen format seznamu, list souboru, file "file" i file 'file'. Zkouseny byly ruzne formaty videa. I byl zkousen convert prez concat i linkovani prmo seznamu obrazku. Zkouseny ruzne datasety.

Pokud se dobre napsali parametru v poradi, vytvareni videa se rozbehlo, casto to ale zkoncilo chybou kvuli poradu parametru. Ale video se vzdy vytvorilo neuplne, po 7-30% poctu obrazku zkoncilo z neznameho duvodu. Kolik obrazku bylo zpracovano, to zavisi jen, jakse soubory v seznamu jmenuji. Jen cislo.png (nejdo po 1), IM_cislo.png IM_Cislo_dalsinazev.png, pokazde byl pocet zpracovanych obrazku jiny.

zkousel jsem to prez pipe,

Kód: [Vybrat]

cat *.png | ffmpeg -f image2pipe -i
ale tam to hned skoncilo chybou Argument List too long. (obrazku je cca 60 000), podle vseho nesmi byt argument list (pocet znaku) vetsi nez 1 MB, nebo 2na20.

Reseni, kdy mi to vzalo vsechny obrazku, je tzv. Glob pattern *:

Kód: [Vybrat]

ffmpeg -framerate 30 -pattern_type glob -i '*.png' -c:v h264 -s 2000x1000 -x264-params crf=0 OutputFile.mkv

Pravda, nepodarilo se mi tam zadat format yuv420p, misto toho je tam deafultne yuv444p. Zabralo to RAM: VIRT 3173 M RES 1,1 G a cpu to zabralo k 1000% (kolisa 800-1100%), tedy10 vlaken z 16 soucasne. Rychlost 36fps, tedy 1,2 nasobek rychlosti prehravani. Velikost videa 5689 M a cas videa 00:34:24,57, 30 fps, 2000x1000. Obrazky byly prejmenovany na cislo.png, kde cisla jsou vzdy 9-mistna, jako seq -w (000000001.png a pod), zmena cisla nejdou po 1, ale se stejnym krokem. Abecedni seznam je totozny se seznamem datumu-modifikace.

TAK SNAD VYRESNO.

Otazkou je, zdali to vzalo obrazky v poradi spravnem. Jak obrazky prejmenovat na Obr000001.png, Obr000002.png Obr000003.png, to se zatim nepodarilo.

Vysledne hlaseni:

Kód: [Vybrat]

ffmpeg version 3.1.3-static http://johnvansickle.com/ffmpeg/  Copyright (c) 2000-2016 the FFmpeg developers
  built with gcc 5.4.1 (Debian 5.4.1-1) 20160803
  configuration: --enable-gpl --enable-version3 --enable-static --disable-debug --enable-libmp3lame --enable-libx264 --enable-libx265 --enable-libwebp --enable-libspeex --enable-libvorbis --enable-libvpx --enable-libfreetype --enable-fontconfig --enable-libxvid --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libtheora --enable-libvo-amrwbenc --enable-gray --enable-libopenjpeg --enable-libopus --enable-libass --enable-gnutls --enable-libvidstab --enable-libsoxr --enable-frei0r --enable-libfribidi --disable-indev=sndio --disable-outdev=sndio --enable-librtmp --enable-libmfx --enable-libzimg --cc=gcc-5
  libavutil      55. 28.100 / 55. 28.100
  libavcodec     57. 48.101 / 57. 48.101
  libavformat    57. 41.100 / 57. 41.100
  libavdevice    57.  0.101 / 57.  0.101
  libavfilter     6. 47.100 /  6. 47.100
  libswscale      4.  1.100 /  4.  1.100
  libswresample   2.  1.100 /  2.  1.100
  libpostproc    54.  0.100 / 54.  0.100
Input #0, image2, from '*.png':
  Duration: 00:34:24.57, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: png, pal8(pc), 2000x1000 [SAR 72:72 DAR 2:1], 30 fps, 30 tbr, 30 tbn, 30 tbc
No pixel format specified, yuv444p for H.264 encoding chosen.
Use -pix_fmt yuv420p for compatibility with outdated media players.
[libx264 @ 0x558e4e0] using SAR=1/1
[libx264 @ 0x558e4e0] using cpu capabilities: MMX2 SSE2Fast LZCNT
[libx264 @ 0x558e4e0] profile High 4:4:4 Predictive, level 4.0, 4:4:4 8-bit
[libx264 @ 0x558e4e0] 264 - core 148 r276 3f5ed56 - H.264/MPEG-4 AVC codec - Copyleft 2003-2016 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x1:0x111 me=hex subme=7 psy=0 mixed_ref=1 me_range=16 chroma_me=1 trellis=0 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=0 chroma_qp_offset=0 threads=24 lookahead_threads=4 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc=cqp mbtree=0 qp=0
[matroska @ 0x5546d40] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead.
Output #0, matroska, to 'OutputFile.mkv':
  Metadata:
    encoder         : Lavf57.41.100
    Stream #0:0: Video: h264 (libx264) (H264 / 0x34363248), yuv444p, 2000x1000 [SAR 1:1 DAR 2:1], q=-1--1, 30 fps, 1k tbn, 30 tbc
    Metadata:
      encoder         : Lavc57.48.101 libx264
    Side data:
      cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: -1
Stream mapping:
  Stream #0:0 -> #0:0 (png (native) -> h264 (libx264))
Press [q] to stop, [?] for help
frame=61937 fps= 36 q=-1.0 Lsize= 5825753kB time=00:34:24.53 bitrate=23116.4kbits/s speed= 1.2x   
video:5825243kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.008758%
[libx264 @ 0x558e4e0] frame I:248   Avg QP: 0.00  size:262235
[libx264 @ 0x558e4e0] frame P:61689 Avg QP: 0.00  size: 95641
[libx264 @ 0x558e4e0] mb I  I16..4: 95.3%  0.0%  4.7%
[libx264 @ 0x558e4e0] mb P  I16..4:  4.9%  0.0%  0.0%  P16..4: 29.0%  8.8% 10.6%  0.0%  0.0%    skip:46.8%
[libx264 @ 0x558e4e0] 8x8 transform intra:0.0% inter:31.7%
[libx264 @ 0x558e4e0] coded y,u,v intra: 50.6% 50.4% 48.3% inter: 32.3% 31.8% 31.7%
[libx264 @ 0x558e4e0] i16 v,h,dc,p: 33% 67%  0%  0%
[libx264 @ 0x558e4e0] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 41% 40% 11%  1%  1%  1%  1%  1%  3%
[libx264 @ 0x558e4e0] Weighted P-Frames: Y:0.0% UV:0.0%
[libx264 @ 0x558e4e0] ref P L0: 63.5%  0.0% 23.5% 13.0%
[libx264 @ 0x558e4e0] kb/s:23113.99