Pan.do/ra - nezobrazí se task při importu videa, nevím zda probíhá import #135

New Issue

2017-11-01T13:27:01+01:00

Podhorecky commented

2017-11-01 13:27:01 +01:00

(Migrated from git.spotter.cz)

Udělal jsem test zátěže při importu videa.

na media.spotter.cloud jsem přes noc poslal několik krátkých videí z YouTube do fronty.
videa proběhla OK.
pak jsem vložil odkaz na video z Vimeo. U něj se později přidal asset do databáze, ale video ještě není zpracované a těžko říct, zda někdy bude. Mělo jen několik minut. Nevím, zda tím úplně nezastavilo další zpracování.

Nevím jak z rozhraní vyvolat dialogové okno Tasks, kde by bylo vidět jaká videa jsou ještě ve frontě.

Další vložená videa z YT (vkládáno jako odkaz) už neumožnila zobrazit okno Tasks.
Po reloadu celé strany pan.do/ra se sice počet assetů zvýší, ale stejně netuším, zda probíhá konverze, nebo neprobíhá.

Zatím jsem nelezl do administrace virtuálního serveru na forpsi, možná by tam bylo vidět nějaké CPU zatížení (?)

Dotaz tedy zní:
Můžete prosím potvrdit / vyvrátit že komprese linkovaného videa z vimeo.com probíhá / neprobíhá?

Může na to mít vliv snížení počtu paralelních procesů, které jste udělal v zájmu SeedDMS (pochopil jsem to správně že to je na úrovni OS)?

celé toto moje zkoumání je o hledání stability provozu aplikace, takže nechci vás s tím obtěžovat u každého importu.

Pokud to je zapříčiněno tím, že výkon serveru je s jedním CPU jádrem a málo paměti mizerný, tak to pochopím.
Moje testy na virtuální image dokázaly s pan.do/ra využít CPU na 100% s více jádry podle toho, kolik uměl dát VirtualBox. Videa se spočítala bezchybně... takže spekuluji, že problem může být někde jinde, než v samotné kompresi videa.

Udělal jsem test zátěže při importu videa. na media.spotter.cloud jsem přes noc poslal několik krátkých videí z YouTube do fronty. videa proběhla OK. pak jsem vložil odkaz na video z Vimeo. U něj se později přidal asset do databáze, ale video ještě není zpracované a těžko říct, zda někdy bude. Mělo jen několik minut. Nevím, zda tím úplně nezastavilo další zpracování. Nevím jak z rozhraní vyvolat dialogové okno Tasks, kde by bylo vidět jaká videa jsou ještě ve frontě. Další vložená videa z YT (vkládáno jako odkaz) už neumožnila zobrazit okno Tasks. Po reloadu celé strany pan.do/ra se sice počet assetů zvýší, ale stejně netuším, zda probíhá konverze, nebo neprobíhá. Zatím jsem nelezl do administrace virtuálního serveru na forpsi, možná by tam bylo vidět nějaké CPU zatížení (?) Dotaz tedy zní: Můžete prosím potvrdit / vyvrátit že komprese linkovaného videa z vimeo.com probíhá / neprobíhá? Může na to mít vliv snížení počtu paralelních procesů, které jste udělal v zájmu SeedDMS (pochopil jsem to správně že to je na úrovni OS)? celé toto moje zkoumání je o hledání stability provozu aplikace, takže nechci vás s tím obtěžovat u každého importu. Pokud to je zapříčiněno tím, že výkon serveru je s jedním CPU jádrem a málo paměti mizerný, tak to pochopím. Moje testy na virtuální image dokázaly s pan.do/ra využít CPU na 100% s více jádry podle toho, kolik uměl dát VirtualBox. Videa se spočítala bezchybně... takže spekuluji, že problem může být někde jinde, než v samotné kompresi videa.

Podhorecky commented

2017-11-01 13:58:31 +01:00

(Migrated from git.spotter.cz)

pravděpodobně na to vzniká i chybové hlášení.

Podhorecky commented

2017-11-03 12:15:15 +01:00

(Migrated from git.spotter.cz)

soudím, že jsem server nějak přetížil, komprese v Pan.do/ra neprobíhá. Celé je to líné.
ve statusu pod seznamem píše, že objem 29 videí je 2,74 GB. Předpokládám že to by se ještě mohlo vejít na server. (víc jsem toho importovat ani nechtěl) Možná je problém s odkládacím místem, nebo odkládacím prostorem.

podobně i u SeedDMS nelze uploadovat nové dokumenty, vzniká chybová hláška, navíc se nerenderují náhledové obrázky k některým dokumentům.

Forpsi
Login: 171102vn
Heslo: K2bDKQ2

Forpsi cloud
https://admin.dc3.forpsicloud.cz/Login.aspx
Login: FCZ-71987
Heslo: mJGdI226-m

soudím, že jsem server nějak přetížil, komprese v Pan.do/ra neprobíhá. Celé je to líné. ve statusu pod seznamem píše, že objem 29 videí je 2,74 GB. Předpokládám že to by se ještě mohlo vejít na server. (víc jsem toho importovat ani nechtěl) Možná je problém s odkládacím místem, nebo odkládacím prostorem. podobně i u SeedDMS nelze uploadovat nové dokumenty, vzniká chybová hláška, navíc se nerenderují náhledové obrázky k některým dokumentům. Forpsi Login: 171102vn Heslo: K2bDKQ2 Forpsi cloud https://admin.dc3.forpsicloud.cz/Login.aspx Login: FCZ-71987 Heslo: mJGdI226-m

Disassembler commented

2017-11-04 09:03:08 +01:00

(Migrated from git.spotter.cz)

Jojo. Disk už nenaloží ani blechu. SeedDMS sežralo 3,4 GB a Pandora 12 GB. K tomu 1.5 GB systém a 2 GB swap a jsme nadoraz.

Myslím, že jste narazil na problém, kterému jsem se snažil předejít v issue #19 navržením "vysoké kvality" pouze jako 720p. Vidím v datech video e7/e7/c4/4034fb0db5 jehož zdroj má cca 635 MB, ale milá pandora z jej upscaluje na 1080p H.264, které zabírá 2,5 GB. Také by to asi vyřešila featura, kterou navrhujete v issue #57, kdy by Pandora mohla identifikovat maximální rozlišení videa a zbytečně jej neupscalovat.

Vymazal jsem data upscalovanému videu, tj. soubor pro 1080p existuje s nulovou velikostí, což by mělo stačit pandoře k tomu, aby jej znovu nevytvářela. Nicméně doporučuji zkontrolovat všechny akce a pokusy o akce, které byly provedeny po zaplnění disku, protože integrita dat byla narušena.

Jojo. Disk už nenaloží ani blechu. SeedDMS sežralo 3,4 GB a Pandora 12 GB. K tomu 1.5 GB systém a 2 GB swap a jsme nadoraz. Myslím, že jste narazil na problém, kterému jsem se snažil předejít v issue #19 navržením "vysoké kvality" pouze jako 720p. Vidím v datech video `e7/e7/c4/4034fb0db5` jehož zdroj má cca 635 MB, ale milá pandora z jej upscaluje na 1080p H.264, které zabírá 2,5 GB. Také by to asi vyřešila featura, kterou navrhujete v issue #57, kdy by Pandora mohla identifikovat maximální rozlišení videa a zbytečně jej neupscalovat. Vymazal jsem data upscalovanému videu, tj. soubor pro 1080p existuje s nulovou velikostí, což by mělo stačit pandoře k tomu, aby jej znovu nevytvářela. Nicméně doporučuji zkontrolovat všechny akce a pokusy o akce, které byly provedeny po zaplnění disku, protože integrita dat byla narušena.

Disassembler commented

2017-11-04 09:03:08 +01:00

(Migrated from git.spotter.cz)

closed

Podhorecky commented

2017-11-04 09:22:58 +01:00

(Migrated from git.spotter.cz)

ok, je to jasné. media smažu, imho komprese probíhá ok, pokud je místa dost. další pokusy budu dělat jen s minimem medií. díky

Podhorecky commented

2018-04-01 00:23:21 +02:00

(Migrated from git.spotter.cz)

changed milestone to %1

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Spotter-Cluster/Spotter-VM#135