I set up a fresh install of 18.04.6 x86 architecture and configured minidlna just to test before a definitive install on a A4001N. My goal would be to run minidlna pointing a folder mounted over cifs under vpn(zerotier). Using x86 all went ok and run better and faster than expected, so I repeated the install on 1A4001N hardware, configs and packets installed are the same, but when the x86 minidlna shows correctly all files in target folder and subfolders and in general works very well, A4001N does not. Only the files in the root target directory are shown also adding subfolders as specific target directories in config file, and often after many minidlna reload not all files in root folder directory are found (subfolders are never shown). It seems as ffmpeg give up his job or does'n see all files when they are correctly shown listing them in ssh shell. Is it possible that minidlna, or some dependencies, are compiled differently from an architecture to another?
Thanks in advance for helps.
It sounds like you're running out of memory. Can you share your logs?
I don't know the device and haven't investigated yet. Still, ffmpeg/minidlna require quite a lot of memory, sometimes even a half of a GB or more. Without enough memory and without swap, the system will kill the process before it gets somewhere.
I think it's not a out of memory problem, after some other comparisons with the x86 I founded that on x86 executing /etc/init.d/minidlna restart or stop and after start act always as a reload recreating the files.db also starting directly minidlna -f configurationFile.conf do the same, in fact every start of minidlna do a rebuilt of database.... not normal.
After the rebuilt the files shown, as already told, are without subfolders but regularly playable, no leak of memory.
Thanks for your reply, I'll post logs.
I agree with @NoTengoBattery, i used to have a Linksys ea3500 that had twice the ram (64mb) as the 1a4001n (32mb if the openwrt data page is correct) and had the same problem. What i used to do was make a folder for log and database on the drive i was using and then use my wrt1200 which has plenty of memory to create the minidlna database, then i would just point the ea3500 minidlna log and database to that folder which was laready created. Here's another way if you'd like to try it also.
Because the same remote target directory is already scanned locally by another server with minidlna, my first attempt was to use that db already made, x86 would works fine, 1a4001n one wants to rebuilt always, no way to force it to use intact
Which version of openwrt was?
I did that on 15.05 through 18.06. Another thing you might check is that the disk name is the same on x86 and 1a4001n, meaning if it created on x86 under /dev/sda1 it needs to be /dev/sda1 on 1a40001n also, and the mount points also need to be the exact same such as /mnt/storage/minidlna on both devices.
Yes at first attempt I used the same amount point, as usual x86 accepted the db, mips32 not, but the really strange is the different behaviour, the mips32 reload at each start, also without -R option, meaning that's impossible to use an already make db.
Thanks for the support, so reading logs happens that runs out of memory ( in fact a very few memory) scanning a particular file, without that file the scan continue and subfolders appears....than particular files need so much memory to be scanned (for that device). But a step back... My first attempt since x86 was to point to a remote cifs mounted directory, avoiding the scan using the db already made up by another minidlna running locally (contained in the same scanned directory). So I mounted my cifs on top of directories made to set up the same path used by the local minidlna, as you also suggested. But minidlna wants to rebuild db compulsory ignoring that already made. The path is the same also 'date' show the same time for the two hardware, just the mounting way is different one locally on a block file the other by cifs. What could minidlna looks for in the db to mark as outdated?
Is another subfolder created when doing that by chance? That would be my only guess, in my experience everything has to be exactly the same when using the same db between devices, disk name, mount point, even number of subfolders, anything different will cause it to rebuild like you're seeing.
I think solution is found, just to test and write down some rows of script to make things go.
After a long read, not exhaustive, of minidlna source files, my very poor comprehension of c drive me to believe that the check on db at minidlna start is about sql version and if is present where conf file declare.
I tried to copy the db into the router, not important where (I tried two path, now in/tmp), conf file pointing to that db file and start minidlna.... goal!
No rescan at all and the system goes up with all files served onto dlna in a few seconds.
It seems it isn't a matter of path the rejecting of an external db.
Last in this experience:
Copying the db in a local position and after starting minidlna prevent a new rescan (if the db is reasonably fresh).
Using instead the original db in the remote position triggers a rescan maybe for latency reason.
My mips hardware is a bit low in ram so with a copied db, a cifs mount, and minidlna running works good just with a bit of free ram.
As above but with the zerotier client also running a out of ram occurs when a movie is played by the render o triggered by the dlna client.
I'm now trying to substitute cifs with ftp.... any suggestions?
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.