miniDLNA memory leak and not scanning any media

tekkb · 2. März 2013

Report back to us how you like Twonky after you 've been using it a while. I may buy it just out of curiosity.

ryecoaaron · 2. März 2013

Zitat von "tekkbebe"

Report back to us how you like Twonky after you 've been using it a while. I may buy it just out of curiosity.

I think I avoided it because I thought it used java and not free. Definitely going to look into that if you have good luck.

macnb · 5. März 2013

Problem solved - temporarily.

When you install the plugin, it automatically pulls the binaries from some repo.
I guess the plugin developer has taken the sources from here, compiled it and posted to a repo.

The size of the plugin binary is significantly smaller than the binary posted at source-forge site. (276960 bytes vs 2697744 bytes source-forge). I guess the binaries there have a whole bunch of debug code.

So I replaced binary with the 1.0.25 binary from source-forge.
I restarted the service and hey presto it indexed my entire collection within a few minutes (including all the .TS files) !

CPU load was around 27% and no memory blockages.

So the 1.0.25 binaries from source-forge work but the binary that the plugin pulls down does not.
So need to go back to the developer of the plugin - a bug report ???.

ryecoaaron · 5. März 2013

The binary on sourceforge is statically linked (includes libraries in executable thus bigger). The binary that Marcel compiled (maintainer of minidlna plugin) is dynamically linked and uses the system libraries. The libraries the sourceforge executable uses are much newer which must fix your problem.

macnb · 5. März 2013

I see what static means now.
OK so there's either a problem with one of the dynamic libraries that minidlna uses or with minidlna compilation itself.

Either way, I guess I ought to report it.

ryecoaaron · 5. März 2013

It is probably a problem with ffmpeg/libavformat. Debian Squeeze is using a very old version.

macnb · 5. März 2013

Zitat von "ryecoaaron"

It is probably a problem with ffmpeg/libavformat. Debian Squeeze is using a very old version.

Probably. One of the changes in 1.0.25 was "Add support for the latest ffmpeg/libav library versions".
If OMV is not using the latest, there may be incompatibility issues.

Problem reported on issue tracker.

macnb · 8. März 2013

Well I reported the problem here:

https://github.com/OMV-Plugins…iavault-minidlna/issues/4

But no response...comment...reads...

So not sure if anyone is at home or the dev on the minidlna has stopped or reported in the wrong place ??

tekkb · 8. März 2013

This is part of the reason the minidlna package is separate from the plugin. We had issues before.

macnb · 8. März 2013

Zitat von "tekkbebe"

This is part of the reason the minidlna package is separate from the plugin. We had issues before.

I think you may have misunderstood me.
I reported the problem on the OMV-Plugin site...NOT the minidlna site (as the problem is NOT in the minidlna source package but with the way the plugin is implemented). Check the link I posted.

ryecoaaron · 9. März 2013

I just noticed in minidlna CVS that there is a fix for compiling minidlna against older versions of ffmpeg. Might have to try it out.

macnb · 11. März 2013

I think the plugin developer should fixing it so that everyone gets to benefit ?

ryecoaaron · 11. März 2013

Zitat von "macnb"

I think the plugin developer should fixing it so that everyone gets to benefit ?

I agree but no one has heard from him in a while.

With the recent change, I was able to compile on OMV (fresh install with no plugins and no third party repositories). If you want to compile your own version, just do the following as root (or use sudo). If you need the /etc/init.d/ script (most likely), then you will want to install minidlna plugin first. These instructions will replace the version installed with the new compiled version.

Code

apt-get install build-essential cvs gettext autopoint autoconf automake libavutil-dev libavcodec-dev libavformat-dev libjpeg62-dev libsqlite3-dev libexif-dev libid3tag0-dev libogg-dev libvorbis-dev libflac-dev


cvs -d:pserver:anonymous@minidlna.cvs.sourceforge.net:/cvsroot/minidlna login   (no password)
cvs -z3 -d:pserver:anonymous@minidlna.cvs.sourceforge.net:/cvsroot/minidlna co -P minidlna


cd minidlna
./autogen.sh
./configure
make
make install
cp minidlnad /usr/sbin/minidlna

Alles anzeigen

*edit - forgot cvs and build-essential - added to the package list

macnb · 11. März 2013

Zitat von "ryecoaaron"

I agree but no one has heard from him in a while.

That's a shame...I guess this is the nature/reality of open source s/w.

Zitat von "ryecoaaron"

If you need the /etc/init.d/ script (most likely), then you will want to install minidlna plugin first. These instructions will replace the version installed with the new compiled version.

I did not understand that bit about the /etc/init.d/ script. Please explain.

I don't have the CVS command. Does this get download by doing the apt-get commands you mentioned ?

ryecoaaron · 11. März 2013

The init.d script is the script that starts minidlna on startup. If you don't have it, you would have to manually start minidlna every time you reboot.

I forgot to add cvs to the apt-get install command. It is added now

macnb · 11. März 2013

Zitat von "ryecoaaron"

The init.d script is the script that starts minidlna on startup. If you don't have it, you would have to manually start minidlna every time you reboot.

I forgot to add cvs to the apt-get install command. It is added now

Got it. I kinda figured it out.
Thx for your help.

Now... how do you ensure that the new compiled minidlna is linked to the older ffmpeg ?

ryecoaaron · 12. März 2013

When you compile minidlna this way, it is compiled dynamically against the system libraries. So, it uses the system libraries as opposed to a statically linked binary that uses compiled-in libraries which may not match the system.

macnb · 12. März 2013

Compiled and built no problem. Thx for the pointers.
As expected, the new one behaves as before (fails)
The latest OMV system libraries are picking up ffmpeg libs that are incompatible with latest minidlna.
I cannot find where those ffmpeg libs are ...even if they are the problem...not sure they are.

Anyway, the point is combination of OMV+minidlna is broken.
Workaround is to download static minidlna and use that.
But as OMV and minidlna plugins get updated, the user has to keep manual track of of the updates and keep updating the minidlna package manually.

Or....pay 20 bucks and use Twonky which (so far) seems to work very well.

ryecoaaron · 12. März 2013

Ever since I started testing twonky, I haven't used minidlna. So, I guess twonky is working very well. The minidlna issue will go away once OMV is based of Wheezy. Unfortunately, I am too used to the sort by date feature in twonky.

timduncan · 27. Mai 2013

When miniDlna is scanning for files, it uses all available memory. When it is done scanning, it releases it. I don't think this is a memory leak. But it maybe not efficient.

Houston Best Document Conversion Services

Jetzt mitmachen!