Řekl bych, že by to mohlo souviset s tím, že v novějších verzích OpenWrt proces minidlna běží pod svým vlastním uživatelem a nikoliv pod rootem jak bylo zvykem u starších verzích, což by mohlo být ono, ale je to jen teorie.
Je pravda, že u vlastníka souborů/videí vidím v 90% root a zbytek patří uživateli.
Bohužel ale netuším, zvláště běží-li miniDLNA pod svým vlastním uživatelem, jak tyto soubory pro miniDLNA zviditelnit.
Zkoušel jsem i Gerberu, ale ta pro Turris/OpenWRT 19.07 ustrnula navzdory existující v1.8.2 na verzi 1.4.0-4, která mne příliš nepřesvědčíla svou funkčností i stabilitou…
Existuje případně nějaké jiné jednoduché a robustní řešení DLNA pro Turris OS5? Děkuji za tip.
Dobrý den všem.
Dnes jsem manuálně přešel s Turrisem 1.0 na verzi HBS 5.2.7.
Jako zatím plná spokojenost ale DLNA se mi také nepodařilo rozhýbat.
Máte někdo v této věci posun?
1 Like
Včera mi proběhla automatická migrace na mém T1.1 na TurrisOS 5.3.1. A bohužel už řeším stejný problém. Skenování se zastaví a v logu jde vidět následující chybu:
Dec 2 10:03:36 turris kernel: [46428.727884] minidlnad[24263]: unhandled signal 4 at b619214c nip b619214c lr b6192144 code 1
Zkusil jsem si zprovoznit i Gerberu. A zdá se, že i u ní se skenování zasekne se stejnou chybou:
Dec 2 10:30:14 turris kernel: [48027.094748] gerbera[28977]: unhandled signal 4 at b60ea14c nip b60ea14c lr b60ea144 code 1
Zkusil jsem nastavit skenování jen pár vybraných složek u kterých jsem nastavil práva u všech souborů na “0777”, ale nepomohlo to.
Po marných pokusech se mi nepodařilo na Turris 1.0 rozjet miniDLNA ve verzi 1.3,
přitom na MOXu jede bez problémů.
Neřeší to ani práva, ani nastavení, ani jiné složky, názvy bez diakritiky, nic.
Jsem na tom uplně stejně… Po automatckém přechodu na TOS 5.3 minidlna 1.3.0 přestalo “vidět” většinu video souborů…
Tak jsem ten problém rozlousknul (nebo alespoň doufám). Rozběhl jsem si MiniDLNA na Raspberry Pi a hned poté jsem si všiml, že mi Turris nebyl schopný přidat do databáze filmy, které měly nějaký attachment (cover atd.). Napsal jsem si skript v powershellu, který mi u všech filmů ve složce za pomocí mkvpropedit.exe odebral všechny přílohy a poté se mi filmy přidaly do MiniDLNA databáze na Turrisu 
mkvpropedit.exe MOVIE.mkv --delete-attachment mime-type:image/jpeg
Vyzkouším to na celém disku i u dalších souborů a dám vědět, jak jsem dopadnul.
Tak se mi to potvrdilo Prohnal jsem celý disk skriptem, a MiniDLNA mi už zase sdílí 1000+ videí místo předchozích 25. Kdyby byl někdo chtěl, tak přikládám PowerShell skript:
$actualPath = $(get-location).Path;
Get-ChildItem -Recurse -Path $actualPath -Include *.mkv, *.mp4 | foreach {
Write-Host $($_.FullName)
& "$($actualPath)\mkvpropedit.exe" "$($_.FullName)" "--delete-attachment" "mime-type:image/jpeg"
}
Skript projde všechny podsložky a u všech MKV a MP4 souborů odebere attachment. Aby fungoval, je potřeba do stejné složky umístit mkvpropedit.exe, který je součástí sady MKVToolNix
Vyzkouším tvou metodu ale mně nechtěl indexovat ani 3 samostatné avi soubory, takže jsem trochu skeptický. Máš to vyzkoušené opravdu na Turris 1.x?
Ano. Turris 1.1. Dlouhou dobu jsem migraci na TOS 5 odkládal kvůli tomuhle problému. Ale je pravda, že avi soubory tam nemám.
Potvrzuji, že jsem si u sebe ověřil, že minidlna při indexovaní postupuje podle abecedy (složky i souboury dohromady) a zastaví se u souborů .avi nebo u .mkv s přílohou. Všechna videa podle abecedy předtím se načtou do databáze správně.
Nemůže být tedy problém např. s ffmpeg?
Mimochodem, po aktualizaci Turris 1.0 na TOS 5 řeším stejný problém.
Já jsem řešil to samý. Když jsem před několika měsíci provedl manuální upgrade na TOS5, tak mi přestalo minidlna úplně indexovat. Nakonec jsem se vrátil zpět na TOS3 a vše fungovalo jak má.
Teď nedávno jak proběhl automatický upgrade, tak mi vše “fungovalo”, teda až do včerejška, kdy jsem změnil v configu jaké adresáře má indexovat (jeden jsem odebral). V tu chvíli všechno zmizlo a z “poskytuje 270 audio, 3973 video a 326 obrázkových souborů” bylo rázem 0 audio, 0 video a 0 obrázkových. Teď jsem se vrátil na předvčerejší snapshot a mám zas 270 audio, 3973 video a 326 obrázků.
Minidlna běží dle HTOP pod rootem, přístup má ke všemu a všude, takže nechápu proč nechce fungovat. Až to zase přestane fungovat, tak nevím jak si budeme pouštět filmy v televizi…
Teď jsem ještě vyzkoušel, že se “starou” konfigurací indexování nových souborů funguje. Přidal jsem na disk dva *.mkv soubory a počet videosouborů se zvýšil na 3975
Tak se mi povedlo udělat na druhé SD kartě migraci z TOS3 s čistým (továrním+aktualizace) nastavením na TOS5 a metodou pokus omyl jsem dospěl k závěru, že MiniDLNA ve složce s hudbou naindexovalo všechny soubory. Ve složce s videem nic. Tak jsem celou složku s videi přesunul a začal laborovat, jestli vadí diakritika, nebo mezery v názvu a cestě - nevadí. Ale co mu vadí je jakýkoliv .AVI soubor.
Pokud do složky nahraju MKV, tak ho naindexuje. Pokud nahraju AVI, tak nic - respektive buď ho nenaindexuje a služba MiniDLNA běží dál, nebo se služba ukončí.
Fotky v JPG to naindexuje všechny, ale nesmí se mezi nimi vyskytnout video z foťáku ve formátu MP4, to pak naindexuje asi polovinu fotek (266 z 483)
Po nějaké chvíli zkoušení jsem ještě dospěl k tomu, že to nebude asi příponou video souboru, ale použitým kodekem videa.
Např AVI soubor s těmito parametry mi spolehlivě ukončí službu MiniDLNA
zatímco tento AVI soubor to v pohodě naindexuje
Uživatele pod kterým se má MiniDLNA spouštět lze definovat v /etc/config/minidlna
config minidlna ‘config’
option user ‘minidlna’
Ať je nastaven uživatel “root” nebo “minidlna” tak se to chová stejně…
V dmesg se mi objevuje
minidlnad[10290]: unhandled signal 4 at b657d14c nip b657d14c lr b657d144 code 1
a co mi hlava už vůbec nebere, tak na druhé SD kartě, kde se systém zmigroval automaticky a převzal si starý nastavení, tak to avi soubory normálně indexuje. Nebo možná je to má naindexovaný ještě z dob TOS3.
Tvoje snaha je chvályhodná, já dospěl skoro ke stejnému výsledku, jen ty kodeky jsem nezkoumal, připadá mi divné že by DLNA zkoumalo kodeky. Vyzkouším co popisuješ, já původně začal s třemi video soubory, ale jaká to byla data už nevím.
Zvláštní je, že stejná verze miniDLNA v MOXu běží bez problémů a modrák ty data nevezme.
Tak jsem ještě vyzkoušel Gerberu místo MiniDLNA a po přidání adresáře s videi Gerbera spadne se stejnou chybou jako MiniDLNA
Dec 24 08:49:00 turris kernel: [ 1505.317432] gerbera[9733]: unhandled signal 4 at b5c6614c nip b5c6614c lr b5c66144 code 1
takže problém asi nehledejme v MiniDLNA ale někde jinde
Zkoumal jsem fóra k OpenWrt a před několika lety lidé řešili podobný problém. Obrázky a hudba ano, videa ne (nebo omezeně). Na vině byla verze/kompilace ffmpeg. Bohužel, nenašel jsem žádné vhodné řešení pro aktuální situaci.
Já si také myslím že chyba bude někde při kompilaci nebo jiné verze dalšího sw, protože na jiném hw tato verze chodí. Nevím jestli zrovna ffmpeg, protože k chybě dojde už při indexaci a ne při přehrávání.
Napadlo mě zkompilovat starší verzi minidlna s aktuální verzí TOS.
Ale k tomu se dostanu po svátcích, snad budu mít v práci na to chvíli klid.
Hezký svátky.
1 Like
V práci?
Commare … a to přiznáváš zrovna před Ježíškem?
2 Likes
Já to měl do svátků fakt pekelný, teď bude klid, asi celý leden, tak bude čas na hrátky.
Šéf je tolerantní, dost mě pak zneužívá na svoje hw a sw problémy.
Ježíšek to snad neslyší. 
1 Like