1

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.

Dr_Bunsen
  • 498
  • 3
  • 11
artfulrobot
  • 353
  • 1
  • 3
  • 13
  • which version of minidlna? – Jaromanda X Feb 11 '20 at 05: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 – Jaromanda X Feb 11 '20 at 05:49
  • Oops, I meant stretch worked, buster doesn't. I'm on 1.2.1+dfsg-1+b1 – artfulrobot Feb 11 '20 at 07: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 – Jaromanda X Feb 11 '20 at 07:49
  • Maybe this: https://sourceforge.net/p/minidlna/bugs/325/ – artfulrobot Feb 11 '20 at 07:53
  • how many files does it index? is it exactly 100 each time as implied by your question? – Jaromanda X Feb 11 '20 at 07:56
  • no, it varies. Following a fairly random solution I've found can clear some of it, but I think it's probably certain files, or types of file, that kill it. I think that solution doesn't work, I think it just means the files are processed in a different order; I still have unindexed files. It's just super annoying that even 'debug' level logging doesn't show what's going on/which file it dies on. – artfulrobot Feb 11 '20 at 08:35

1 Answers1

0

  • 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

I HOPE THIS HELPS

Barhoumist
  • 1