56

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?

Stickers
  • 75,527
  • 23
  • 147
  • 186
Dipen
  • 821
  • 2
  • 8
  • 13

7 Answers7

61
$ 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'
Serge Stroobandt
  • 28,495
  • 9
  • 107
  • 102
  • 3
    With **systemd**, `$ sudo service minidlna restart` will become `$ sudo systemctl restart minidnla.service`. – Serge Stroobandt Feb 12 '15 at 22:05
  • 4
    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. – unode Jul 14 '15 at 15:53
  • 4
    `minidlna` is named `minidlnad` on my setup – Bryce Guinta May 25 '17 at 00:00
  • 2
    Isn't there a way to get rescanned automatically, when new files are added? – klor Aug 19 '18 at 12:52
  • 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? – bomben Jan 19 '19 at 15:48
  • 1
    @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. – sastorsl Jan 11 '21 at 15:21
  • 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. – sastorsl Jan 11 '21 at 17:50
  • 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. – Eddy_Em Nov 02 '21 at 13:17
  • 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 https://askubuntu.com/a/294748/1073673 ). – baltakatei Jan 08 '22 at 19:19
39

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.

unode
  • 9,321
  • 4
  • 33
  • 44
  • 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. – AzP May 07 '14 at 09:38
  • 3
    @AzP 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`. – unode May 07 '14 at 13:12
  • Ah ok, I misread that part of your answer. My main issue was with the `inotify_interval` part, I never stated there was one. – AzP May 09 '14 at 12:32
  • 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...) – AzP May 09 '14 at 12:50
  • 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? – Astaar Feb 18 '16 at 09:33
  • To be clear, I want to copy from my Windows client which has a mounted share on the server, where the files are. – Astaar Feb 18 '16 at 09:34
  • 1
    @Astaar 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 http://unix.stackexchange.com/q/84351 . Check also the resources linked there. – unode Feb 18 '16 at 16:47
  • 3
    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](https://ubuntuforums.org/showthread.php?t=2073540)) and running `sysctl -p`. After a `service minidlna restart` everything worked fine (Ubuntu 16.04)! – der Michi Sep 28 '17 at 20:46
7

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.

AzP
  • 1,081
  • 1
  • 16
  • 27
  • I have enabled inotify=yes, but still doesn't automatically rescan the files, but /var/cache/minidlna/files.db is not changed. – klor Aug 19 '18 at 12:59
  • @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? – AzP Aug 20 '18 at 14:25
  • 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. – klor Aug 22 '18 at 18:31
  • @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. – AzP Aug 28 '18 at 11:45
2

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.

  • 1
    Did you get anywhere with this problem? – frak Dec 26 '16 at 17:38
  • 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. – sastorsl Jan 11 '21 at 15:23
1

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

user1226230
  • 381
  • 1
  • 3
  • 11
1

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
madmb
  • 11
  • 2
  • 1
    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](/help/how-to-answer). – Community Jul 27 '22 at 01:05
0

Resolved with crontab root

10 * * * * /usr/bin/minidlnad -r
DavidW
  • 29,336
  • 6
  • 55
  • 86
  • 5
    This answer would be a lot more useful if you said what this does and why it helps. – DavidW Oct 12 '19 at 18:00
  • Not a great answer, agreed: ```-r forces a rescan``` – EightyEight Jan 16 '21 at 03:20
  • 1
    @EightyEight 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. – theking2 Aug 04 '21 at 18:12
  • 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) – duketwo Dec 20 '21 at 06:56
  • 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. – Nate Jul 12 '22 at 18:50