Minidlna / ReadyMedia
What is minidlna?
Minidlna is a multimedia content provider on Linux using UPnP to advertise itself on you LAN. An Netgear employee developed it and can be found on many NAS devices of various brands. It has now been renamed ReadyMedia and is opensource. You get the latest version here on SourceForge.
Minidlna scans your storage in user configured maps for pictures, music and movies and also extracts media meta info. It stores it in a mySql database, together with a folder containing thumbs of the files if present, like front.jpg etc.
A media renderer like your TV can find the Minidlna service on your LAN and browse, search and play them.
Related file of minidlna are:
/usr/sbin/minidlna
/etc/minidlna.conf
/var/cache/minidlna/files.db
/var/cache/art_cache/*
/var/log/upnp-av.log
Configuration
There is one configuration file that cab be found in /etc/minidlna.conf that can be changed to your needs. If you have a NAS you manage it from the GUI on your NAS. But not all settings can be changed from the GUI.
For minidlna 1.1.4 possible settings are:
port=
network_interface=
media_dir=
merge_media_dirs=
friendly_name=
db_dir=
log_dir=
log_level=
album_art_names=
inotify=
enable_tivo=
strict_dlna=
presentation_url=
notify_interval=
serial=
model_number=
model_name=
minissdpdsocket=
force_sort_criteria=
max_connections=
Sorting folders and files
Default minidlna sorts files and folder alphabetically, disregarding the object type. Adding this line sorts folders first:
force_sort_criteria=+upnp:class,+upnp:originalTrackNumber,+dc:title
Increasing inotify watches
In /etc/sysctl.conf add this line:
fs.inotify.max_user_watches=65536
Minidlna high cpu slowing down NAS
Many users, including myself, may experience very high cpu usage on the NAS from the minidlna process. First I thought it did a rescan of my NAS but I didn't give any command to do that and the NAS was not rebooted, that is when minidlna does a rescan. (minidlna -R)
I noticed that my NAS was responding very slow, also with Samba. On the NAS I did a top to see if cpu usage was high. It was. Minidlna was using 99% of the cpu. Ok. Now why? It took me a few days to figure out what was going on here.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
7848 root 37 0 32432 17m 1952 R 98.4 8.1 436:40.95 minidlna
10998 root 16 0 2992 1664 1328 R 1.6 0.7 0:01.16 top
1 root 15 0 2000 880 768 S 0.0 0.4 0:05.72 init
2 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/0
I changed the default logging of minidlna changing the /etc/minidlna.conf file:
log_level=debug
Then restarted minidlna to watch what was logged using: tail -f /var/log/upnp-av.log
After watching a while it became clear what was hogging minidlna: my LG TV
[2016/11/23 23:48:21] upnphttp.c:880: debug: HTTP REQUEST: POST /ctl/ContentDir HTTP/1.1
SOAPAction: "urn:schemas-upnp-org:service:ContentDirectory:1#Search"
DLNADeviceName.lge.com: %5bLG%5d%20webOS%20TV
User-Agent: Linux/3.10.19-32.afro.5 UPnP/1.0 LGE WebOS TV LGE_DLNA_SDK/1.6.0/05.05.01 DLNADOC/1.50
Host: 10.0.0.200:8200
Content-Length: 740
Content-Type: text/xml; charset="utf-8"
[2016/11/23 23:48:21] clients.c:271: debug: Client found in cache. [LG/entry 0]
[2016/11/23 23:48:21] upnphttp.c:653: debug: SOAPAction: urn:schemas-upnp-org:service:ContentDirectory:1#Search
[2016/11/23 23:48:21] upnpsoap.c:1907: debug: SoapMethod: Search
[2016/11/23 23:48:21] upnpsoap.c:1681: debug: Searching ContentDirectory:
* ObjectID: 0
* Count: 30
* StartingIndex: 30
* SearchCriteria: upnp:class derivedfrom "object.item.videoItem" and @refID exists false
* Filter: res@resolution,res@nrAudioChannels,res@sampleFrequency,res@bitrate,dc:creator,res@dlna:cleartextSize,dc:date,upnp:genre,res,res@duration,res@size,upnp:albumArtURI,upnp:originalTrackNumber,upnp:album,upnp:artist,upnp:author
* SortCriteria: (null)
Switching the TV off the cpu went back to normal. Wow. Could not believe a client could do this.
I hope this helps you to find the source of this problem. ;)
ps: don't forget to set minidlna logging back to warn or fatal