Why is the minidlna database not being refreshed?

Question

I am developing a MiniDLNA server to stream media over WiFi. Existing files are shown properly. However, when I add new files to media folders the changes are not updated across MiniDLNA clients. I have also tried to restart the server but it does not reflect the changes.

I changed inotify_interval = 60 but it's still not updating files.db which is the MiniDLNA media list database. If I delete this database and restart the server it shows the changes.

Does anyone know what the problem might be?

Inexactitude

I have the same problem. I use OpenMediaVault v3 and MiniDLNA v1.1.6 – Kareykari

Current version of MiniDLNA is 1.2 (or higher). If you can update it with your OMV v3. – Zoniazoning

Answer 1

$ minidlnad -h
    …
    -r forces a rescan
    -R forces a rebuild

In summary, the most reliable way to have MiniDLNA rescan all media files is by issuing the following set of commands:

$ sudo minidlnad -R
$ sudo service minidlna restart

Client-side script to rescan server

However, every so often MiniDLNA will be running on a server. Here is a client-side script to request a rescan on such a server:

#!/usr/bin/env bash
ssh -t server.on.lan 'sudo minidlnad -R && sudo service minidlna restart'

Metatarsus

With systemd, $ sudo service minidlna restart will become $ sudo systemctl restart minidnla.service. – Metatarsus

Actually I'd recommend against using sudo minidlna -R. This can and most likely will cause the files to be created/owned by root. A proper init script will run the server under its own user. An alternative which may be available on some systems is to issue a force-restart or force-reload to the init-script or systemd service. – Tobey

minidlna is named minidlnad on my setup – Schuck

Isn't there a way to get rescanned automatically, when new files are added? – Kareykari

I use minidlna in my openmediavault server (version 4.1.17). Updating my library works, but in one case it does not: I renamed some files and minidlna is unable to display the new names. I also copied those files later to check whether that will solve the problem. But still the files have an old name. So I wonder, if minidln has a database somewhere that is saving content for each file. In the sense that if the file itself (hash, time created or something else) does not change then minidlna will use an old version of info it created for this file. Can someone confirm this? – Zoniazoning

@Ben I would assume this is related to the files' inode. If you move or rename a file inside the same file system the file will keep it's inode, and minidlna will not recognize it. Try moving the file to another file system, and then back again. – Pearly

I'm using inotify and had some files and directories with incorrect permissions. I fixed the permissions, then moved those directories outside the monitored directories (same filesystem btw) and then back in, and now they are being added again. – Pearly

Flag "-R" forces database rebuild -> it will be erased and built again! This will lasts for a 3-4 hours (or even more). Very bad advice. – Lxx

If you installed minidlna as provided by Debian 10, it runs as a service under the minidlna user. If so, sudo minidlna -R will cause /var/cache/minidlna/files.db to be unmodifiable by minidlna since sudo does stuff as the root user. Therefore, be careful to run the minidlna -R command as the minidlna user, like so: sudo -H -u minidlna bash -c 'minidlnad -R (see askubuntu.com/a/294748/1073673 ). – Scalise

Answer 2

AzP already provided most of the information, but some of it is incorrect.

First of all, there is no such option inotify_interval. The only option that exists is notify_interval and has nothing to do with inotify.

So to clarify, notify_interval controls how frequently the (mini)dlna server announces itself in the network. The default value of 895 means it will announce itself about once every 15 minutes, meaning clients will need at most 15 minutes to find the server. I personally use 1-5 minutes depending on client volatility in the network.

In terms of getting minidlna to find files that have been added, there are two options:

• The first is equivalent to removing the file files.db and consists in restarting minidlna while passing the -R argument, which forces a full rescan and builds the database from scratch. Since version 1.2.0 there's now also the -r argument which performs a rebuild action. This preserves any existing database and drops and adds old and new records, respectively.
• The second is to rely on inotify events by setting inotify=yes and restarting minidlna. If inotify is set to =no, the only option to update the file database is the forced full rescan.

Additionally, in order to have inotify working, the file-system must support inotify events, which is not the case in most remote file-systems. If you have minidlna running over NFS it will not see any inotify events because these are generated on the server side and not on the client.

Finally, even if inotify is working and is supported by the file-system, the user under which minidlna is running must be able to read the file, otherwise it will not be able to retrieve necessary metadata. In this case, the logfile (usually /var/log/minidlna.log) should contain useful information.

Tobey

Well, I did specifically say "notice the lack of a leading 'i'", and say that it is used instead of inotify if inotify is disabled. – Crawley

@Crawley and that's one of the incorrect things you said. notify_interval is always used, regardless of whether inotify is on or off. This option has nothing to do with inotify. – Tobey

Ah ok, I misread that part of your answer. My main issue was with the inotify_interval part, I never stated there was one. – Crawley

And now I re-read the question, and saw that your comment was not regarding my answer, but the original question. I'm sorry for the downvote, fixing that now! (Doh! I'm unable to change my vote unless the answer is edited...) – Crawley

Quick question if I may. You say "Additionally, in order to have inotify working, the file-system must support inotify events, which is not the case in most remote file-systems." What if the file system is local but I copy to it from a CIFS share? Would this trigger the inotify event? – Salesroom

To be clear, I want to copy from my Windows client which has a mounted share on the server, where the files are. – Salesroom

@Salesroom The point about remote systems is only valid if the location being monitored by minidlna is a remote disk (NFS, Samba, ...). If it's on the local disk, it should generate an event regardless where the file is being transferred/copied/moved from. More at unix.stackexchange.com/q/84351 . Check also the resources linked there. – Tobey

After examining /var/log/minidlna.log I found a warning about Inotify max_user_watches [8192] is low or close to the number of used watches ... and increased the max_user_watches by editing my /etc/sysctl.conf, adding fs.inotify.max_user_watches=524288 (a value bigger than 65536) and running sysctl -p. After a service minidlna restart everything worked fine (Ubuntu 16.04)! – Sneaky

Answer 3

MiniDLNA uses inotify, which is a functionality within the Linux kernel, used to discover changes in specific files and directories on the file system. To get it to work, you need inotify support enabled in your kernel.

The notify_interval (notice the lack of a leading 'i'), as far as I can tell, is only used if you have inotify disabled. To use the notify_interval (ie. get the server to 'poll' the file system for changes instead of automatically being notified of them), you have to disable the inotify functionality.

This is how it looks in my /etc/minidlna.conf:

# set this to no to disable inotify monitoring to automatically discover new files
# note: the default is yes
inotify=yes

Make sure that inotify is enabled in your kernel.

If it's not enabled, and you don't want to enable it, a forced rescan is the way to force MiniDLNA to re-scan the drive.

Crawley

I have enabled inotify=yes, but still doesn't automatically rescan the files, but /var/cache/minidlna/files.db is not changed. – Kareykari

@klor, are you sure that inotify is enabled in your kernel? You can verify it in the .config file related to your current kernel. Have you also restarted minidlna since enabling inotify? – Crawley

I use OpenMediaVault v3, which is based on Debian 8. I think Debian 8 should have inotify enabled by default. I restarted minidlna several times, but only when files.db is deleted, then new files appears. – Kareykari

@klor, have you checked the read/write permissions on your files.db, and whether MiniDLNA is running as that user? Can you see anything in the minidlna.log? What if you start MiniDLNA using a command instead of automatically, can you see any output? You can also try starting it using the -R flag, forcing a re-scan of your library. That might output some error message. – Crawley

Answer 4

I have recently discovered that minidlna doesn't update the database if the media file is a hardlink. If you want these files to show up in the database, a full rescan is necessary.

ex: If you have a file /home/movies/foo.mkv and a hardlink in /home/minidlna/video/foo.mkv, where '/home/minidlna' is your minidlna share, you will have to do a rescan till that file appears in the db (and subsequently your dlna client).

I'm still trying to find a way around this. If anyone has any input, it's most welcome.

Invitation

Did you get anywhere with this problem? – Range

I think this is related to that hard linked files share the same inode and minidlna seem to store the inode, not the name (my guess...). Since you see the same types of issues when moving or renaming files. – Pearly

Answer 5

There is a patch for the sourcecode of minidlna at sourceforge available that does not make a full rescan, but a kind of incremental scan. That worked fine, but with some later version, the patch is broken. See here Link to SF

Regards Gerry

Marvamarve

Answer 6

I have solved it with a small script:

Every 15 seconds it checks the size of the directory (/media/seriesPI). The service is restarted if there are changes

 #!/bin/bash

 function sizeFiles(){
    for i in $(du /media/seriesPI/ | awk '{print $1}')
    do
            cad+=$i
    done 
 }

 sizeFiles

 #first size
 first=$cad
 cad=''

 while [ true ]
 do
    sizeFiles

    echo "$first != $cad"

    if [ "$first" != "$cad" ] ; then

            echo "Directory size has changed!"
            echo "Restart service MiniDLNA"

            sudo service minidlna restart              

            #update new size
            first=$cad
    else
            echo "There are no changes in the directory"
    fi

    echo "waiting 15 seconds..."
    sleep 15
    cad=''
done

Steven

As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center. – Tangy

Answer 7

Resolved with crontab root

10 * * * * /usr/bin/minidlnad -r

Milli

This answer would be a lot more useful if you said what this does and why it helps. – Bunns

Not a great answer, agreed: -r forces a rescan – Submarine

@Submarine I don't understand your answer either. And don't see how it helps. If you like to add an answer click answer and be a bit more elaborate. – Hau

This does not work: "minidlna.c:1030: fatal: MiniDLNA is already running. EXITING." Adding "-r" to the init.d service script should do the the trick however. Then you can crontab the service restart. (Yes you can restart the service without causing problems to any active streams) – Bureaucrat

I also had the "MiniDLNA is already running" error, but when I stopped it I got an error "fatal: Bad user 'minidlna'". This was fixed by commenting out the "user" line in minidlna.conf. Then the database was created just fine. – Uriisa