Mám problém na androidu který nedokážu pobrat, proč to jednou je naprosto ok experience bez problému dokonce i v 10násobné náročnosti a jinde je stojí za starou bačkoru.

Jsem Připojen k wifině (na linkové rychlosti 150 Mb/s, z routeru stahuji třeba i reálně 104 Mb/s). Takže jen pro ilustraci, v rychlosti není problém

Chci si přehrát video(pro informaci, 7Mbps), které je uložené na tom routeru. Mohu Dvěma způsoby:

1. Přes http(s) protokol v aplikaci chromium pro android to jde ** Naprosto OK ** , dokonce i když vyberu jiný (96 Mbps soubor v 4K, akorát to na začátku trochu bufferuje ale 2 sekundy). Není problém dát seek a prakticky hned mi to hraje od dané pozice

2. Přes protokol "Sdílení souborů v síti microsoft" - zprovozněné v androidu přes "aplikaci CIFS documents provider" (samotné aplikace jen umožní pár voleb a definovat cílové servery s názvy/ip/login údaji), samotný obsah se otevírá normálně přes správce souborů - levé menu - poslední třetí sekce (Galerie,Trasování,zprávy o chybách CIFS Documents).

Jenže když to otevřu takto (furt aplikace je správce souborů, ale rozhraní je jako videopřehrávač), nastane CHAOS. dlouhou se čeká , data proudí, pak to NĚKDY začne hrát. Seeek je prakticky nemožný, jako kdyby to stahovalo celý soubor pokaždý od začátku. SEká se to, někdy to spadne. Když přehrávání ukončím, data dál proudí ještě několik sekund

Z jakého důvodu je to takhle "zohavené"? Mám pocit, jako kdyby byl problém v (ne)cachování souborů a propojením mezi CIFS protokolem architekturou rozšíření správce souborů.

Z logiky věci bych očekával že přes SMB to bude mnohem stabilnější než přes HTTP(S)



KDe je problém? Existuje nějaká jiný stabilní konektor pro přístup k SMB (a v jiném režimu než document provider, je li víc možností?)
Samozřejmě při zkopírování do lokál. úložiště( nebo i přes flasku přes OTG) TO JE OK bez problému.

PRoč to řeším a nezůstanu u HTTP a browseru, protože http "Exporty" jsou limitované a "výpis souborů" má tragický frontend, kromě toho přes CIFS provider vidím přímo strukturu disku a taky nepracuji jen s videosoubory a obrázky ,ale i generickými soubory, které kopíruji tam a zpět. A především že file-systém emulace je "uživatelsky" víc nativní než nějaká prezentace výpisu souborů v html stránce.

Jen malá rada. Nechceš se se svými četnými dotazy přesunout do Poradny? Tady ti na tvoje specifické dotazy stejně nikdo neodpovídá a tam by mohla být větší šance..
https://www.zive.cz/poradna/sc-20/defau ... tegory=100

HTTP se ale na stream A/V hodi daleko lepe.

No vidíš, to jsou mi novinky...
1. Měl jsem za to , že poradna je ušpiněná, zatímco fórum je pro elitu. navíc jsem zvyklý na "lůk" fór než poraden (vizuál) a objektivně tam jsou nulové možnosti úprav,citací, vkládání kódů atd, už se těším až sem někdo napíše radu jaký konfigurační soubor v /data změnit a vloží ho do CODE.

2. SMB mi přišlo lepší v tom, že to je na úrovni souborů práce a taky že browser by to potenciálně mohl prznit než integrovaný přehrávač videí, ale doba se mění... I když technicky HTTP s podporou range je vlastně i jednodušší možná než protkol smb.... Jen mi to přišlo z pohledu uživatele, že smb přísup bude mít méně problematických míst (vrstev) než přes browser: program brouser: http, zatímco galerie: otevřu "mountnutý soubor"

3. Mimochodem, jak v browseru otevřu soubor přes samba??? opravdu půjde do adresního řádku \\srv@slo\soubor.mp4?


-> Desktopový browser ano, dokonce to převede na file:// a obrátí lomítka
ale v mobilu s tím nepochodím(Bromite,FF) - CO CHROMIUM? Ale to se už dostáváme do testování vedlejších věcí (i když to odhalí slabinu SMB přístupu možná)