I used to have this running happily under Raspbian stretch but under Raspbian buster it gives up with no error after a few files.

  • I've checked that the minidlna user has access to all the files.
  • I've enabled debug level logging
  • I've tried running with the -R option
  • I've tried deleting /var/cache/minidlna/*
  • I've checked file ownership of /var/cache/minidlna/* (as suggested here)
  • I've tried with and without ionotify
  • I've tried removing the dir that it stops at; then it just stops at the next one.

It serves the files it indexed OK. I just can't figure out why it stops where it does! It's like it has a limit of 100 files or something.

  • which version of minidlna? Commented Feb 11, 2020 at 5:40
  • 2
    raspbian stretch minidlna version is 1.1.6 - I remember having nothing but problems with it. So I downloaded the source code and compiled version 1.2.1 - and have had no issues ... note: latest raspbian, buster, has version 1.2.1 - so perhaps upgrade to latest raspbian Commented Feb 11, 2020 at 5:49
  • Oops, I meant stretch worked, buster doesn't. I'm on 1.2.1+dfsg-1+b1 Commented Feb 11, 2020 at 7:32
  • I would suggest you edit the question to make that clear - I have NOT updated my media server to buster yet, so perhaps something in buster is broken Commented Feb 11, 2020 at 7:49
  • Maybe this: sourceforge.net/p/minidlna/bugs/325 Commented Feb 11, 2020 at 7:53

1 Answer 1

  • I had the same issue above: minidlna stops scanning the files after an exact number of files and I had the following warning in /var/log/minidlna/minidlna.log: "monitor.c:218: warn: WARNING: Inotify max_user_watches [8192] is low or close to the number of used watches [327] and I do not have permission to increase this limit. Please do so manually by writing a higher value into /proc/sys/fs/inotify/max_user_watches."

  • After I tried everything is settings etc, my issue was actually solved quite easily: I checked at which folder the scanning actually stops and noticed that I added a new .m4a file there

    • I removed this new file and voila, the scan continues
    • the file causing the issue is not mentioned in the log --> I have no idea why this is as my library has other .m4a that are not causing any trouble but may be you can check for any new files you might have added and remove them to test


Not the answer you're looking for? Browse other questions tagged or ask your own question.