Minidlna fails with large media collection

N

noteboat

This is a follow-up from my post over in the ports and packages forum. I had originally thought that the pre-built package simply didn't have the change that fixed the problem I'm seeing, but after further investigation I think I was mistaken.

I installed the net/minidlna package on my FreeBSD 10.0-RELEASE machine. At startup, it is failing with the message:

Code: 
[2014/03/10 00:38:34] upnpevents.c:422: fatal: upnpevents_selectfds: file descriptor 1026 too big for select, limit is 1024

After some searching, I found this PR which appears to be about this basic problem, and which has a patch that added the error message I'm seeing: http://www.freebsd.org/cgi/query-pr.cgi?pr=185155

However, the code in that PR should have increased the limit to 8192, if I'm reading it correctly, and the error message is reporting 1024. It's almost as if the changes to upnpevents.c made it in, but the changes to minidlna.c didn't.

Is anyone else seeing this?
 
After a few kicks at the can, I am still getting this. Any idea how I could best troubleshoot this, or maybe I should file a bug report? Can someone send me a URL on how to properly submit a big report?

$ more /var/db/minidlna/minidlna.log
Code: 
[2015/04/19 13:58:20] minidlna.c:1029: warn: Starting MiniDLNA version 1.1.4.
[2015/04/19 13:58:21] minidlna.c:1077: warn: HTTP listening on port 8200
[2015/04/20 07:23:32] upnpevents.c:423: fatal: upnpevents_selectfds: file descriptor 1121 too big for select, limit is 1024
 
Rather than create a new thread I'll add my quick fix here, my initial visit to this thread a few days ago was my last hope of a fix funnily enough!

My own miniDLNA/ftp server was crashing with exactly the same issues stated above and was quite literally driving both myself and my children nuts with at least 5 crashes a day no matter what was being played; so minus half my scalp and with every other option exhausted I installed devel/libinotify and set
Code: 
kern.maxfiles="50000"
in /boot/loader.conf and to my great surprise, it worked.... now MiniDLNA automatically updates the media so it can be viewed without updating the database (which is a very lengthy task indeed) and has not crashed since.

Hope this helps anyone else who has this issue...


[edit] Well that showed me, after what seemed like a bullet proof last 2 days the upnpevents error popped up again. I am making an assumption that it may be inotify which is causing the error so I have set inotify=no in minidlna.conf and removed the libinotify port I installed in a last ditch attempt to see if it rectifies this annoying bug.

[edit2] inotify is the culprit according to the last comment on this page I have just found; if true I will have to rescan the database every time I add stuff to the media folders. Not a great outcome but while MediaTomb is broken it's the best that we can hope for...
 
I know this is an old post but after years of running miniDLNA and it automatically updating I too was bit by this issue and found that manually rebuilding the database every time I added new media was a pain. I wanted to share my method of automating this process which works if you use transmission to add media to your library and transmission is running on the same box as MiniDLNA.

In short I use monit to monitor /var/log/transmission.log and when the log reports a torrent download is complete it runs the below script.

/root/scripts/rebuilddlna.sh
Code: 
rm /var/db/minidlna/files.db
service minidlna restart

Make sure transmission has logging enabled by adding
Code: 
 transmission_flags=" -e /var/log/transmission.log"
to /etc/rc.conf and create the log with appropriate permissions.

Code: 
# touch /var/log/transmission.log
# chown transmission /var/log/transmission.log

install monit
Code: 
# pkg install monit

configure monit to monitor the newly created tranmission.log and run script when a download has been completed.

Code: 
nano /usr/local/etc/monitrc

###############################################################################
## Global section
###############################################################################
##
## Start Monit in the background (run as a daemon):

set daemon 30 # check services at 30 seconds intervals
with start delay 5 # optional: delay the first check by 4-minutes default 240
# # default Monit check immediately after Monit start)
#
#
## Set syslog logging. If you want to log to a standalone log file instead,
## specify the full path to the log file
#
set logfile /var/log/monit.log

#
#
## Set the location of the Monit lock file which stores the process id of the
## running Monit instance. By default this file is stored in $HOME/.monit.pid
#
set pidfile /var/run/monit.pid


check file transmission.log with path /var/log/transmission.log

if match "Complete" then exec "/bin/csh -c /root/scripts/rebuilddlna.sh"

set permissions for monitrc
Code: 
chmod 700 /usr/local/etc/monitrc
enable monit to run at boot
Code: 
 # sysrc monit_enable=yes
start monit
Code: 
# service start monit
Another trick I found to speed this up is under the “set this to the directory you want scanned” option in /usr/local/etc/minidlna/minidlna.conf the order in which the directories are listed will be the order that they are scanned and become available on the server, so if you want video’s to be first the settings should look like this
Code: 
# set this to the directory you want scanned

media_dir=V,/location/of/videos

media_dir=A,/location/of/music

media_dir=PV,/location/of/photos.
That should do it.

I had read in a stack exchange that since miniDLNA version 1.2.0 you can simply run minidlna -r to update the database rather than rebuild it from scratch which sounds like it has the potential to speed up this process, but I could never get it to work, if you have better luck with -r you could modify rebuilddlna.sh for a more speedy solution.
 
Last edited:
Just a quick update on this but the original issue "file descriptor 1026 too big for select, limit is 1024" appears to have been resolved with 11.1- release; has anyone upgraded and still having this issue?
 
Yep, I have been running 11.1 for a few months now and still get the issue. I have to comment out sections of my media library in the /usr/local/etc/minidlna.conf file so it would keep running stable. I've tried to nail down the offending files so I could delete them. I love MiniDLNA so I will try to offer what support I can.

less /var/log/minidlna.log | grep 1024
Code: 
[2017/12/03 12:26:13] upnpevents.c:423: fatal: upnpevents_selectfds: file descriptor 1122 too big for select, limit is 1024
[2017/12/03 18:23:32] upnpevents.c:423: fatal: upnpevents_selectfds: file descriptor 1103 too big for select, limit is 1024
[2017/12/04 10:02:14] upnpevents.c:423: fatal: upnpevents_selectfds: file descriptor 1096 too big for select, limit is 1024
[2017/12/20 18:44:07] upnpevents.c:423: fatal: upnpevents_selectfds: file descriptor 1131 too big for select, limit is 1024
[2017/12/22 17:14:39] upnpevents.c:423: fatal: upnpevents_selectfds: file descriptor 1130 too big for select, limit is 1024
[2018/02/24 16:52:44] upnpevents.c:430: fatal: upnpevents_selectfds: file descriptor 1177 too big for select, limit is 1024
[2018/03/18 09:07:06] upnpevents.c:430: fatal: upnpevents_selectfds: file descriptor 1175 too big for select, limit is 1024
[2018/03/23 21:07:56] upnpevents.c:430: fatal: upnpevents_selectfds: file descriptor 1173 too big for select, limit is 1024
[2018/03/24 12:52:54] upnpevents.c:430: fatal: upnpevents_selectfds: file descriptor 1173 too big for select, limit is 1024
[2018/03/27 18:31:12] upnpevents.c:430: fatal: upnpevents_selectfds: file descriptor 1177 too big for select, limit is 1024
[2018/04/11 20:34:43] upnpevents.c:430: fatal: upnpevents_selectfds: file descriptor 1174 too big for select, limit is 1024
[2018/04/13 23:49:21] upnpevents.c:430: fatal: upnpevents_selectfds: file descriptor 1170 too big for select, limit is 1024
[2018/04/27 19:27:48] upnpevents.c:430: fatal: upnpevents_selectfds: file descriptor 1171 too big for select, limit is 1024
 
They only support I can provide for this is what I had posted on December 21st its a crude work around but does the trick
 
I wrote the maintainer ages ago, but dont think I heard back. May a few of us should write him/her again. I more interested in having a port that works, rather than trying workarounds.
 
You must log in or register to reply here.
Back
Top