I'm currently transfering a lot of video files. This yields several issues. - my client "loses" minidlna connection completely if I leave it idle for a day. *I think* minidlnad only does rescans (which can be slower than disk fills with a high enough bandwidth, apparently). - it stops responding completely....
systemctl showed it as dead, e.g.,
root@mnemosyne:/var/log# systemctl status minidlna.service minidlna.service - DLNA/UPnP-AV media server Loaded: loaded (/lib/systemd/system/minidlna.service; enabled) Active: failed (Result: signal) since Tue, 15 Mar 2016 18:28:49 +0100; 4h 14min ago Process: 13481 ExecStart=/usr/sbin/minidlnad -S (code=killed, signal=KILL) CGroup: name=systemd:/system/minidlna.service
Mar 15 17:52:04 mnemosyne minidlnad[13481]: sql.c:41: error: SQL ERROR 19 [U...] Mar 15 17:52:05 mnemosyne minidlnad[13481]: INSERT into CAPTIONS (ID, PATH) ...) Mar 15 17:55:35 mnemosyne minidlnad[13481]: sql.c:41: error: SQL ERROR 19 [U...] Mar 15 17:55:36 mnemosyne minidlnad[13481]: INSERT into CAPTIONS (ID, PATH) ...) Mar 15 17:57:23 mnemosyne minidlnad[13481]: sql.c:41: error: SQL ERROR 19 [U...] Mar 15 17:57:23 mnemosyne minidlnad[13481]: INSERT into CAPTIONS (ID, PATH) ...) Mar 15 17:59:08 mnemosyne minidlnad[13481]: sql.c:41: error: SQL ERROR 19 [U...] Mar 15 17:59:09 mnemosyne minidlnad[13481]: INSERT into CAPTIONS (ID, PATH) ...) Mar 15 18:00:52 mnemosyne minidlnad[13481]: sql.c:41: error: SQL ERROR 19 [U...] Mar 15 18:00:53 mnemosyne minidlnad[13481]: INSERT into CAPTIONS (ID, PATH) ...)
the error themselves look very strange... it would seem like some kind of threaded race conditions between multiple IDs from some other table and the insertion into captions ?
for the record, I haven't touched anything as root. no files or anything (well I just used systemctl restart minidlna.service, which is obviously more responsive than the web interface).
I could upload more info, such as /apps/.readydlna/files.db if needed....but that's obviously a bit large for this forum (434M and counting).
Thanks! I'll try that tomorrow, as it's probably going to take all day to rebuild the db.
(going to watch stuff tonight, rm the db and restart the service tomorrow, do the debug and force the rescan... I gotta admit I'm not a big fan of systemd, obviously).
okay, killed the service, removed the database, started things from scratch.
Monitoring in one window with sqlite3 (select path from details order by id desc limit 15;) and in the other with journalctl -f
wait and see... crossing fingers. MIght be the first scan got interrupted and the database corrupt... though sqlite is fairly resilient, maybe minildna isn't.
I admit I just throw my full NFS share at minildna and let it sort it out... expecting my tools to work, too much time working on OpenBSD maybe.
Surprised there are still signal reset at the entrance of every handler in minildna. I figured all relevant platforms have safe signals by now.
Mar 16 01:53:27 mnemosyne kernel: [296313.858219] Out of memory: Kill process 28802 (minidlnad) score 42 or sacrifice child Mar 16 01:53:27 mnemosyne kernel: [296313.858231] Killed process 28802 (minidlnad) total-vm:52868kB, anon-rss:39392kB, file-rss:4032kB
after 2 hours +. Obviously, systemd restarts it soon after, but it has to look at the whole beginning of the filesystem until it gets to where it should.
Did anyone run valgrind or something on it ?
Probably going to try to debug this on the other side of nfs... with proper instrumentation (even though this is going to go slow as hell).
How much content are you dealing with? The ReadyNAS 104 you're using only has 512 MB of RAM. It usually takes about 256 MB of RAM to run the OS and so you have about 256 MB of RAM left to run all your services. If minidlna is running through a huge list of files and data, the process could be consuming more than the allotted 256 MB of RAM.
Moving videos and srt around *after* they've been scanned will trigger it. It seems minidlnad figures out that the file moved, but it tries to re-insert the srt into the CAPTIONS table, which does fail since there is already an entry with that specific srt.
I'll have to look at the code to make sure something more nefarious is not going on, but doing "INSERT OR REPLACE" instead of INSERT ought to be enough.
Definitely has nothing to do with the memory leak...
Historically, OOMs during a media scan usually haven't been from minidlna. In the majority of cases I've seen, there's a bad video file that the ffmpeg libraries choke on. It may be worth running a scan in debug mode to see if it's consistently getting stuck in the same spot. Try this:
# systemctl stop minidlna
# /usr/sbin/minidlnad -d -i lo -R
ReadyNASOS 6.5.0-T338 (Beta 2) is now available. Can you update to that and send in your logs if you still have issues with DLNA or if the unrelated OOM continues to occur?
