Runing minidlna on OpenMediaVault (via a plugin).
The plugin automaitcally pulls and installs minidlna.
It installed minidlna version 1.0.25
In the minidlna.conf file, if media_dir= points to a directory containing .TS files (bluray rips), the minidlna service is eventually killed by the kernel (as it uses up all the memory (8GB). And, no files appear on the clients.
Previous versions were fine but latest version fails ..no errors in the log file.
Anyone seen this ?
Going back to 1.0.24 fixes the problem.
Thus 1.0.25's handling of .TS files is badly broken.
I've not had any problems.
Nearly all my media is in m2ts format (not .ts) including all my re-encoded DVD rips (hundreds of videos), my straight Blu-Ray rips (I only have about 20 of these), and my HD Freesat recordings (quite a few).
Given that Blu-Rays are in m2ts format on the disc, you've clearly used a tool to put them into a ts container. It's possible that something is wrong in one (or more) of them.
You could try having it scan a smaller selection to troubleshoot.
Your unequivocal statement that the app is 'handling of .TS files is badly broken' is perhaps a little premature until you've exhausted other alternative causes. Use of such emotive language is unlikely to cause someone who does this in their free time to help you.
The reason I mention m2ts here is that, to the best of my knowledge, minidlna treats .ts and .m2ts files as if they are the same.
Agree with you to say it's badly broken may be overstating it.
The reason I say it's broken is that the problem did not appear till I went from 1.0.24 to 1.0.25.
I went back to 1.0.24 and the problem goes away.
That is, 1.0.24 does not use up the 8GB memory, does not load up the dual-cpu to 50%, does not SSH terminal and is not killed off by the kernel eventually due to lack of memory. And, all the media are scanned and added to the DB.
My .TS files are simply a container of H.264 video stream, Audio and Subs created with TX-Muxer in the past.
DLNA clients play the files fine (XBMC, Samsung TV, MCE, etc). .TS files were a standard way to store blu-ray rips in the past…MKV have taken over now. I could re-rip the blu-rays into .MKV's and the prblem would go away….but would take too long to redo my collection.
Just seems, that the latest minidlna is scanning a .TS file and seems to be caught in a loop, gobbling up memory and never ending. Will try to simplify a test case.
Just installed TwonkyServer 7.1.2 on the same system. It took nearly 2 hours to scan all the same media.
What it does is to scan each .TS file and build a time-seek profile to figure out the time length of the video - it does this iFrame-by-iFrame. I wonder if minidlna is trying to do the same thing but something is going wrong in the process.
Workaround is to go back to older version (and everytime an auto update on the system occurs which pulls in the latest)
I appreciate that this is frustrating. It's possibly a problem with the precompiled binary that you are pulling in. Do you know where this originates?
As I say, all my media is in m2ts, which only differs from ts in that each packet has 4 extra bytes of info, and is treated identically by minidlna. I've just seen I've just done a count of indexed files in my minidlna DB and I'm showing over 4000 video files in m2ts format.
My minidlna instance runs on a server with 2 GB of RAM and a single core 3 GHz processor.
I am up to date with the latest CVS check-in, and I do not have this problem, indeed, I've never had this problem. I do get high CPU activity on scanning, but it does not kill the server.
This is a potential pitfall with open source software… As soon as you are talking about a pre-compiled binary, possibly with patches, it's difficult to troubleshoot. I can only recommend that you build from source and see if the problem persists.
That was was a very good question about where I pulled the binaries.
It is part of the plugin for OpenMediaVault. 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 here. (276960 bytes vs 2697744 bytes here).
I guess the binaries here have a whole bunch of debug code.
So your question prompted me replace the plugin binary with the binary from here.
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 binaries from here work but the binary that the plugin pulls down does not.
So need to go back to the developer of the plugin.
Many thanks for your help.
Glad I could help :-)
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.