• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

Minidlna fails with large media collection

noteboat

New Member


Messages: 9

#1
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?
 

PacketMan

Aspiring Daemon

Thanks: 107
Messages: 777

#2
Yes I am getting this now that I have loaded in all of my media collection.
 

PacketMan

Aspiring Daemon

Thanks: 107
Messages: 777

#3
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
 

j7j3

New Member

Thanks: 6
Messages: 17

#5
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...
 

timypcr

Member

Thanks: 2
Messages: 20

#6
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: