NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.

Forum Discussion

espie's avatar
espie
Guide
Mar 15, 2016

Minidlna not responding ?

Most current OS, minidlnad -V says version 1.1.5.

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).

10 Replies

Replies have been turned off for this discussion
  • kohdee's avatar
    kohdee
    NETGEAR Expert

    Those errors appear to come from the minidlna database. 

    You likely need to have the database rebuilt as something possibly corrupted it? 

    Debug more with journalctl -a _SYSTEMD_UNIT=minidlna.service

    • espie's avatar
      espie
      Guide

      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).

      • kohdee's avatar
        kohdee
        NETGEAR Expert

        espie wrote:

         I gotta admit I'm not a big fan of systemd, obviously).



        I wasn't either until it just clicked with me. Now, everything I use is Debian 8 and has systemd. 

    • espie's avatar
      espie
      Guide

      Found a way to reproduce THAT specific SQL bug.

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

      • Skywalker's avatar
        Skywalker
        NETGEAR Expert

        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

        and see what happens.

  • kohdee's avatar
    kohdee
    NETGEAR Expert

    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. 

NETGEAR Academy

Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology! 

Join Us!

ProSupport for Business

Comprehensive support plans for maximum network uptime and business peace of mind.

 

Learn More