dlna: does not index music

Coming from OMV 0.5 I updated to 1.0 by doing a fresh install.
However, now I am experiencing problems with miniDLNA.
Video files and pictures can be accessed, but my music files cannot.
It seems they are not indexed at all, though file permissions are identical to the video files and pictures (though in different shared folders).
From the log I could see that miniDLNA complained about some very old JPG images which it couldn't read information from.
Then I removed the video and picture shares from the DLNA configuration to concentrate on the two music shares.
I set DLNA log level to 'Debug' and hit 'Rescan'.
Strangely, this is all that goes into the log file:

[2014/12/01 22:29:56] minidlna.c:153: warn: received signal 15, good-bye
[2014/12/01 22:29:57] minidlna.c:1004: warn: Starting MiniDLNA version 1.1.2.
[2014/12/01 22:29:57] minidlna.c:354: warn: Creating new database at /var/cache/minidlna/files.db
[2014/12/01 22:29:57] minidlna.c:1043: warn: HTTP listening on port 8200
[2014/12/01 22:29:57] playlist.c:125: warn: Parsing playlists...
[2014/12/01 22:29:57] playlist.c:256: warn: Finished parsing playlists.

Are there many debug output lines missing or why is the logfile only showing that playlists are being parsed?
I don't use playlists and with OMV 0.5 it was no problem, all files were indexed as expected.

Does anyone have a hint on how to debug this further?

Thanks,
daflow

Problem solved: after starting minidlna in debug mode on the console I could see the error message that the path of my share could not be found.

This raises 2 questions/enhancement suggestions:

1. why is the minidlna error message not visible in the logfile in the web UI, even in debug mode?

2. I entered the share's path by hand and made a mistake, but shouldn't OMV warn the user that the share's path does not exist?

Best regards

Zitat von ryecoaaron

2. If you are using the web interface to add a share, how can it not exist? The folder/path is created when creating a shared folder. If you are doing things manually, it is hard for the plugin to know that.

I will try to reproduce it and report back.

I could reproduce the behavior:
- add a shared folder
- enter a name
- select a volume
- enter an absolute path, e.g. /media/30cc64ff-f715-430f-8809-36826c215a3c/data/home/jim/NEW_FOLDER
- press save

-> The folder is not created and no error message is shown.

I realise this was an usage error, but a notification would be nice.

You are right, this folder indeed was created.
Thanks