few issues with the latest code (02/20/2011)

  • Anonymous - 2011-02-20

    1. scanner crashes when scanning my media library, the 0.18 version works OK.
    minidlna0220: segfault at 91b3af4 ip 0057e553 sp bf988a54 error 4 in libc-2.13.so

    I could not figure out how to enable a higher level of logging to see what file it fails on, but I think it fails when starting to parse video files.

    # uname -a
    Linux nas #1 SMP Mon Feb 7 06:57:55 UTC 2011 i686 i686 i386 GNU/Linux

    2. when an alternative DB path is specified in config via db_dir, the minidlna.log file is not created over there

    3. the following not-making-sense warning pops in the log

    inotify.c:182: warn: WARNING: Inotify max_user_watches  is low or close to the number of used watches  and I do not have permission to increase this limit.  Please do so manually by writing a higher value into /proc/sys/fs/inotify/max_user_watches.

    (yes, I run it under non-root user, but max_user_watches is higher than it wants anyway…)

  • Will

    Will - 2011-02-20

    Indeed, the log issue has now been like that for months. :(

    I wonder what is new with the 0.19 version? It's not even posted on the home page yet.

  • Justin Maggard

    Justin Maggard - 2011-02-20

    We're looking for 65536 max watches as a minimum, but we may want to revisit that.  I had a few users running minidlna before copying their entire media library to a new device.  So the default at the time (8192) wasn't enough for people in those cases.  But I'm willing to make a change there if it makes sense.

    I'll look into the logging issue.  But the scanner crash is the most interesting thing for me.  You can get more info about where the scanner is by starting minidlna with a forced rescan in debug mode with "minidlna -R -d".  A gdb backtrace would also be very helpful, or even valgrind output.

  • Anonymous - 2011-02-21

    for crash - it doesn't create a core file (maybe a kernel var set to skip that), but I've found a MP3 file that causes scanning thread to crash.

    It looks like a ID3 TAG embedded in MP3 file is causing that (it has European symbols in it and some long names), cause when I erased the fields, minidlna was able to parse the file w/o trouble.

  • Anonymous - 2011-03-01

    status update:

    - bad tag in audio no longer crashes scanner. thanks for the fix.
    - log file is still created in /tmp/minidlna, rather than in dir set via db_dir config option.

  • Justin Maggard

    Justin Maggard - 2011-03-12

    The log directory can be set by configuring log_dir in the config file (ie. log_dir=/var/log).  I know, it's not obvious, because I missed putting this new option in the the sample config file.

    I've just checked in one more change so we will use the db_dir for the log_dir in cases where db_dir has been set but log_dir has not.  If neither has been set, it will still go to the default location.

  • Anonymous - 2011-04-13

    I am getting a very similar result. Installed from the ppa to 10.04 Ubuntu server. I launch minidlna from the command line (server is headless) via ssh.

    uname -a
    Linux server 2.6.38-7-server #39~lucid1-Ubuntu SMP Mon Mar 28 20:45:25 UTC 2011 x86_64 GNU/Linux

    minidlna: segfault at 8012f4798 ip 00007f893ad8090e sp 00007fff7821f0f0 error 4 in libavformat.so.52.31.0

    Trying to scan these folders:
    Music: 14,452 files, 1343 subfolders, 108.5GB
    Videos: 1,890 files, 78 subfolders, 1.3TB
    Pictures: 14,475 files, 237 subfolders, 37.3MB

    I get all the way through Music, most of the way through Videos - then it segfaults. Each time the segfault occurs on the 4th file of a subfolder under Videos. At first, I assumed that file was the problem, so I re-encoded it with handbrake and changed it to m4v from mpg and renamed it (in case it was a bad character in the filename). The filename change caused a change in the order of the files in the subfolder (via alpha). On the next run, it segfaulted on a different file now in the 4th position alphabetically in the same subfolder. I repeated this again with the next file and got the same results.

    The error message made me think is was a file format issue, but the odd "4th in the list" behavior makes me think it's a capacity issue.

    If I attempt to dump the running log to a text file, it segfaults randomly very early in the process.

    Let me know if I can post any useful data or run any tests to debug this.

  • Anonymous - 2011-04-13

    So I tried removing the Music location from the conf file to test the assumption that it was too many files. This proves not to be the case as it segfaulted on the 4th file in Videos/Music again.

    Still testing…

  • Justin Maggard

    Justin Maggard - 2011-04-13

    Are you able to build from source?  If you can reproduce it, it would be nice if you could run minidlna binary with debugging symbols through valgrind to see where the problem lies.  But as of right now, it looks like it's a bug in the ffmpeg libraries and not in minidlna.

  • Anonymous - 2011-04-14

    I keep getting crashes from various videos in one specific subdirectory so I just removed it to expedite things. This allowed the file scan to complete without a segfault.

    Now it will launch and run for a few minutes and then segfaults without warning. I haven't yet been able to access anything via my dlna client (LG tv) but I did manage to see the server for a few moments before it crashes again. The dmesg crash notice is the same as before

    minidlna: segfault at 0 ip 0000000000414ec9 sp 00007fff682d5320 error 4 in minidlna

    I am going to reconfigure it again, this time creating a new set of directories and putting just a few files in it. My media currently resides on a btrfs partition and I'm wondering if the file system may have an impact also.

    It's Grand Prix weekend here in Long Beach so I may not get time to build it from source, but I'll try and do that in a week or so. I'm not familiar with valgrind usage - any quick tips?

  • Justin Maggard

    Justin Maggard - 2011-04-14

    Thanks.  To catch where the segfault is happening, you shouldn't need to do anything more than this:
    # valgrind /path/to/minidlna -R -d

  • Anonymous - 2011-04-14

    I created a new folder and moved 7 movies into it ( a reiserfs raid partition). This scanned OK and it stayed up long enough to start a movie. Here's the tail end on the output from the server:

    upnphttp.c:1754: info: Serving DetailID: 18
    upnphttp.c:1140: debug: sendfile error :: error no. 32
    minidlna.c:1143: debug: HTTP connection from
    upnphttp.c:263: debug: Range Start-End: 858144768 - -1
    upnphttp.c:155: debug: Client found in cache.
    upnphttp.c:767: debug: HTTP REQUEST: GET /MediaItems/18.mp4 HTTP/1.1
    Pragma: no-cache
    Cache-Control: no-cache
    Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, text/html, text/xml, text/plain, application/json, application/atom+xml, */*
    Accept-Language: ko-kr, ko;q=0.8, en-us;q=0.5, en;q=0.3
    Connection: Close
    Range: bytes=858144768-
    User-Agent: Mozilla/5.0 (compatible; MSIE 8.0; Windows NT 5.1; LG_UA; AD_LOGON=LGE.NET; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; LG_UA; AD_LOGON=LGE.NET; LG NetCast.TV-2010)

    upnphttp.c:1754: info: Serving DetailID: 18
    upnphttp.c:1140: debug: sendfile error :: error no. 32
    Segmentation fault

    dmesg output same as above.

  • Anonymous - 2011-04-14

    FYI: ffmpeg and dependants are 4:.0.5.1 ubuntu1.1 packages.

    Also, I've been launching minidlna as a user. Should I be launching it as root?

  • Anonymous - 2011-04-14

    Valgrind output:

    ==3992== Invalid read of size 1
    ==3992==    at 0x414EC9: ??? (in /usr/sbin/minidlna)
    ==3992==    by 0x40762D: ??? (in /usr/sbin/minidlna)
    ==3992==    by 0x6F50C4C: (below main) (libc-start.c:226)
    ==3992==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
    ==3992== Process terminating with default action of signal 11 (SIGSEGV)
    ==3992==  Access not within mapped region at address 0x0
    ==3992==    at 0x414EC9: ??? (in /usr/sbin/minidlna)
    ==3992==    by 0x40762D: ??? (in /usr/sbin/minidlna)
    ==3992==    by 0x6F50C4C: (below main) (libc-start.c:226)
    ==3992==  If you believe this happened as a result of a stack
    ==3992==  overflow in your program's main thread (unlikely but
    ==3992==  possible), you can try to increase the size of the
    ==3992==  main thread stack using the -main-stacksize= flag.
    ==3992==  The main thread stack size used in this run was 8388608.
    ==3992== HEAP SUMMARY:
    ==3992==     in use at exit: 81,148 bytes in 260 blocks
    ==3992==   total heap usage: 2,650 allocs, 2,390 frees, 1,494,678 bytes allocated
    ==3992== LEAK SUMMARY:
    ==3992==    definitely lost: 0 bytes in 0 blocks
    ==3992==    indirectly lost: 0 bytes in 0 blocks
    ==3992==      possibly lost: 78,024 bytes in 233 blocks
    ==3992==    still reachable: 3,124 bytes in 27 blocks
    ==3992==         suppressed: 0 bytes in 0 blocks
    ==3992== Rerun with -leak-check=full to see details of leaked memory
    ==3992== For counts of detected and suppressed errors, rerun with: -v
    ==3992== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)

  • Anonymous - 2011-04-14

    ==4007== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)
    ==4007== 1 errors in context 1 of 1:
    ==4007== Invalid read of size 1
    ==4007==    at 0x414EC9: ??? (in /usr/sbin/minidlna)
    ==4007==    by 0x40762D: ??? (in /usr/sbin/minidlna)
    ==4007==    by 0x6F50C4C: (below main) (libc-start.c:226)
    ==4007==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
    -4007- used_suppression:      2 dl-hack3-cond-1
    -4007- used_suppression:      2 glibc-2.5.x-on-SUSE-10.2-(PPC)-2a
    ==4007== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)

  • Anonymous - 2011-04-14

    My wife's not after me to do anything, so I went ahead and compiled from source. Currently, using the prepared directory as detailed above I am 20 minutes into UltraViolet without a hitch.

    I am going to let this movie run it's full length and then I will re-direct the config to the original directory group and see how it goes…

  • Justin Maggard

    Justin Maggard - 2011-04-14

    Great, thanks.  Maybe it was just the PPA build that went awry.

  • Anonymous - 2011-04-15

    Seems to be fine now. I was able to scan the entire collection on the btrfs partition no problems…

  • Anonymous - 2012-07-11

    Hi, I've got the same issue you've described here (segfault) when minidlna is doing a scan.
    It crash on a file that I've rename without success.

    I don't really understood how oshunluvr resolve his problem.

    Could someone light me?


Log in to post a comment.