You are here: Home » Topic » svn-1696 FreeBSD "plugins/plugin_dir not specified&quot

svn-1696 FreeBSD "plugins/plugin_dir not specified&quot

FireFly Media Server (formerly mt-daapd) Firefly Media Server Forums Firefly Media Server Nightlies Feedback svn-1696 FreeBSD "plugins/plugin_dir not specified&quot

This topic contains 16 replies, has 4 voices, and was last updated by  anotherhowie 8 years, 11 months ago.

Viewing 15 posts - 1 through 15 (of 17 total)
  • Author
    Posts
  • #1908

    Osik
    Participant

    Hi all,

    today i was setting up my new server (FreeBSD 7.0 Beta2 AMD64). I just builded the svn-1696 sources and installing them, but on start i get the error

    plugins/plugin_dir not specified
    Aborting

    I checked my installation and found the plugin_dir in /usr/local/lib/mt-daapd/plugins. I tried to make a symlink to a folder where mt-daapd search the plugins but this doesn’t work. The Configurations seems ok and the plugin_dir is set up.

    Here is the mt-daapd.log with debuglevel 9

    2007-11-04 14:40:07 (bb2e592f): Firefly Version svn-1696: Starting with debuglevel 9
    2007-11-04 14:40:07 (bb2e592f): Warning: Could not load plugins
    2007-11-04 14:40:07 (bb2e592f): Error opening plugin dir /usr/lib/firefly/plugins. Ignoring
    2007-11-04 14:40:07 (bb2e592f): Error opening plugin dir /usr/lib/mt-daapd/plugins. Ignoring
    2007-11-04 14:40:07 (bb2e592f): Error opening plugin dir /lib/mt-daapd/plugins. Ignoring
    2007-11-04 14:40:07 (bb2e592f): Error opening plugin dir /lib/mt-daapd/plugins. Ignoring
    2007-11-04 14:40:07 (bb2e592f): Error opening plugin dir /opt/share/firefly/plugins. Ignoring
    2007-11-04 14:40:07 (bb2e592f): Error opening plugin dir /opt/share/mt-daapd/plugins. Ignoring
    2007-11-04 14:40:07 (bb2e592f): Error opening plugin dir /opt/lib/firefly/plugins. Ignoring
    2007-11-04 14:40:07 (bb2e592f): Error opening plugin dir /opt/lib/mt-daapd/plugins. Ignoring
    2007-11-04 14:40:07 (bb2e592f): Error opening plugin dir plugins/.libs. Ignoring
    2007-11-04 14:40:07 (bb2e592f): plugins/plugin_dir not specified
    2007-11-04 14:40:07: Aborting

    Any ideas?

    #14215

    fizze
    Participant

    well, the message sais that the plugins_dir isnt found under dne plugins section in the config file.

    that should read like this:

    [plugins]
    plugin_dir = /foo/bar
    #14216

    Osik
    Participant

    yeah i know, the problem is, i got such section in my mt-daapd.conf. but this doesnt matter. at the moment i update my userland and kernel, i hope in a couple of hours theres is a chance for me to try it and fix it.

    Thanks

    Osik

    #14217

    Osik
    Participant

    well afterall, i have no solution found for this problem. maybe my config helps.

    # $Id: mt-daapd.conf.templ 1660 2007-09-12 13:08:04Z rpedde $
    #
    # This is the mt-daapd config file.
    #
    # If you have problems or questions with the format of this file,
    # direct your questions to [email protected].
    #
    # Questions and discussions about the format and content of this
    # config file can probably be obtained by consulting the wiki:
    #
    # http://wiki.fireflymediaserver.org/Config_File
    #
    # Or by asking questions on the forums at
    #
    # http://forums.fireflymediaserver.org
    #
    #

    [general]

    #
    # web_root (required)
    #
    # Location of the admin web pages.
    #
    # If you installed from .RPM, .deb, or tarball with –prefix=/usr, then
    # this is correct.
    #
    # If you installed from tarball without –prefix=/usr, then the correct
    # path is probably /usr/local/share/mt-daapd/admin-root.
    #

    web_root = /usr/local/share/mt-daapd/admin-root

    #
    # port (required)
    #
    # What port to listen on. It is possible to use a different
    # port, but this is the default iTunes port
    #

    port = 3689

    #
    # admin_pw (required)
    #
    # This is the password to the administrative pages
    #

    admin_pw = mt-daapd

    #
    # db_type (required)
    #
    # This is what kind of backend database to store the song
    # info in. Valid choices are “sqlite” and “sqlite3”.
    #

    db_type = sqlite3

    #
    # db_parms
    #
    # This is any extra information the db needs to connect.
    # in the case of sqlite and sqlite3, this is the name
    # of the directory to store the database in
    #
    # If you installed from RPM or .deb, this path likely already
    # exists. If not, then you must create it. The directory itself
    # must be writable by the “runas” user.
    #

    db_parms = /usr/local/var/cache/mt-daapd

    #
    # mp3_dir (required)
    #
    # Location of the mp3 files to share. Note that because the
    # files are stored in the database by inode, these must be
    # in the same physical filesystem.
    #

    mp3_dir = /tank/Musik

    #
    # servername (required)
    #
    # This is both the name of the server as advertised
    # via rendezvous, and the name of the database
    # exported via DAAP. Also know as “What shows up in iTunes”.
    #

    servername = Firefly %v on %h

    #
    # runas (required)
    #
    # This is the user to drop privs to if running as
    # root. If mt-daapd is not started as root, this
    # configuration option is ignored. Notice that this
    # must be specified whether the server is running
    # as root or not.
    #
    # This is also ignored on Windows.
    #

    runas = root

    #
    # password (optional)
    #
    # This is the password required to listen to MP3 files
    # i.e. the password that iTunes prompts for
    #

    #password = mp3

    #
    # extensions (optional)
    #
    # These are the file extensions that the daap server will
    # try to index and serve. By default, it only indexes and
    # serves .mp3 files. It can also server .m4a and .m4p files,
    # and just about any other files, really. Unfortunately, while
    # it can *attempt* to serve other files (.ogg?), iTunes won’t
    # play them. Perhaps this would be useful on Linux with
    # Rhythmbox, once it understands daap. (hurry up!)
    #
    # Failing that, one can use server-side conversion to transcode
    # non-standard (.ogg, .flac) music to wav on the server side.
    # See the ssc_* options below.
    #
    # To be able to index .ogg files, you’ll need to have configured
    # with –enable-oggvorbis. For .flac, –enable-flac, for .mpc,
    # –enable-musepack.
    #

    extensions = .mp3,.m4a,.m4p,.ogg,.flac,.mpc

    #
    # ssc_codectypes (optional)
    #
    # List of codectypes for files that the daap server should
    # perform internal format conversion and present to clients
    # as WAV files. The file extensions that these codectypes correspond
    # to must also be present in ‘extensions’
    # configuration value, or files are not probed in the first
    # place.
    #
    # Valid codectypes:
    #
    # mp4a – for AAC (.aac, .mp4, .m4a, .m4p)
    # mpeg – for mp3
    # wav – for wav
    # wma – for wma
    # ogg – for ogg
    # flac – for flac (.flac, .fla)
    # mpc for musepack (.mpc, .mpp, .mp+)
    # alac for alac (.m4a)
    #

    ssc_codectypes = ogg,flac,alac

    #
    # ssc_prog (optional)
    #
    # Program that is used in server side format conversion.
    # Program must accept following command line syntax:
    # ssc_prog filename offset length …
    # Parameter filename is the real name of the file that is
    # to be converted and streamed, offset is number of bytes
    # that are skipped from the beginning of the _output_ file
    # before streaming is started, length is length of the song
    # in seconds (or zero). All other possible arguments must
    # be ignored. The resulting wav file (or the rest of
    # the file after initial seek) is written to the standard
    # output by the ssc_prog program. This is typically
    # a script that is a front end for different conversion tools
    # handling different formats.
    #

    ssc_prog = /usr/local/bin/mt-daapd-ssc.sh

    #
    # logfile (optional)
    #
    # This is the file to log to. If this is not configured,
    # then it will log to the syslog.
    #
    # Not that the -d switch will control the log verbosity.
    # By default, it runs at log level 1. Log level 9 will churn
    # out scads of useless debugging information. Values in between
    # will vary the amount of logging you get.
    #

    logfile = /var/log/mt-daapd.log

    #
    # rescan_interval
    #
    # How often to check the file system to see if any mp3 files
    # have been added or removed.
    #
    # if not specified, the default is 0, which disables background scanning.
    #
    # If background rescanning is disabled, a scan can still be forced from the
    # “status” page of the administrative web interface
    #
    # Setting a rescan_interval lower than the time it takes to rescan
    # won’t hurt anything, it will just waste CPU, and make connect times
    # to the daap server longer.
    #
    #

    #rescan_interval = 300

    # always_scan
    #
    # The default behavior is not not do background rescans of the
    # filesystem unless there are clients connected. The thought is to
    # allow the drives to spin down unless they are in use. This might be
    # of more importance in IDE drives that aren’t designed to be run
    # 24×7. Forcing a scan through the web interface will always work
    # though, even if no users are connected.

    # always_scan = 0

    #
    # scan_type
    #
    #
    # This sets how aggressively mp3 files should be scanned to determine
    # file length. There are three values:
    #
    # 0 (Normal)
    # Just scan the first mp3 frame to try and calculate size. This will
    # be accurate for most files, but VBR files without an Xing tag will
    # probably have wildly inaccurate file times. This is the default.
    #
    # 1 (Aggressive)
    # This checks the bitrates of 10 frames in the middle of the song.
    # This will still be inaccurate for VBR files without an Xing tag,
    # but they probably won’t be quite as inaccurate as 0. This takes
    # more time, obviously, although the time hit will only happen the
    # first time you scan a particular file.
    #
    # 2 (Painfully aggressive)
    # This walks through the entire song, counting the number of frames.
    # This should result in accurate song times, but will take the most
    # time. Again, this will only have to be incurred the first time
    # the file is indexed.
    #

    scan_type = 2

    #
    # compress
    #
    # Whether to use gzip content-encoding when transferring playlists etc.
    # This was contributed as a patch by Ciamac Moallemi just prior to the 0.2.1
    # release, and as such, hasn’t gotten as much testing as other features.
    #
    # This feature should substantially speed up transfers of large databases
    # and playlists.
    #
    # It will eventually default to 1, but currently it defaults to 0.
    #

    #compress = 0

    [plugins]
    plugin_dir = /usr/local/lib/mt-daapd/plugins

    [scanning]

    # should playlists be processed at all?
    #
    process_playlists = 0

    # should itunes xml files be processed?
    #
    process_itunes = 0

    # should m3u files be processed?
    #
    process_m3u = 0

    is there a problem building mt-daapd on an amd64?

    thx for help

    greetz

    Osik

    EDIT:

    the following files are in that folder

    -rw-r–r– 1 root wheel 133582 Nov 4 23:41 libout-daap.a
    -rwxr-xr-x 1 root wheel 94969 Nov 4 23:41 libout-daap.so.0.0
    -rw-r–r– 1 root wheel 63392 Nov 4 23:41 librsp.a
    -rwxr-xr-x 1 root wheel 46492 Nov 4 23:41 librsp.so.0.0
    -rw-r–r– 1 root wheel 17546 Nov 4 23:41 libssc-script.a
    -rwxr-xr-x 1 root wheel 18070 Nov 4 23:41 libssc-script.so.0.0
    -rwxr-xr-x 1 root wheel 1123 Nov 4 23:41 out-daap.la
    -rwxr-xr-x 1 root wheel 1093 Nov 4 23:41 rsp.la
    -rwxr-xr-x 1 root wheel 1135 Nov 4 23:41 ssc-script.la

    #14218

    rpedde
    Participant

    @osik wrote:

    -rw-r–r– 1 root wheel 133582 Nov 4 23:41 libout-daap.a
    -rwxr-xr-x 1 root wheel 94969 Nov 4 23:41 libout-daap.so.0.0
    -rw-r–r– 1 root wheel 63392 Nov 4 23:41 librsp.a
    -rwxr-xr-x 1 root wheel 46492 Nov 4 23:41 librsp.so.0.0
    -rw-r–r– 1 root wheel 17546 Nov 4 23:41 libssc-script.a
    -rwxr-xr-x 1 root wheel 18070 Nov 4 23:41 libssc-script.so.0.0
    -rwxr-xr-x 1 root wheel 1123 Nov 4 23:41 out-daap.la
    -rwxr-xr-x 1 root wheel 1093 Nov 4 23:41 rsp.la
    -rwxr-xr-x 1 root wheel 1135 Nov 4 23:41 ssc-script.la

    Your libtool isn’t honoring -avoid-version. You should be able to make a symlink for “librsp.so” to “librsp.so.0.0”, etc, and it should work.

    — Ron

    #14219

    Osik
    Participant

    hi ron,

    thx for help. one problem solved but another one appeared. I am starting the mt-daapd but it “crashes” immediately. after that i startet it with debuglevel 9.

    here is the log:

    2007-11-06 13:45:06 (bb2e592f): Firefly Version svn-1696: Starting with debuglevel 9
    2007-11-06 13:45:06 (bb2e592f): Attempting to load plugin /usr/local/lib/mt-daapd/plugins/libout-daap.so
    2007-11-06 13:45:06 (bb2e592f): Loaded plugin /usr/local/lib/mt-daapd/plugins/libout-daap.so (daap/svn-1696)
    2007-11-06 13:45:06 (bb2e592f): New transcode codec list:
    2007-11-06 13:45:06 (bb2e592f): Attempting to load plugin /usr/local/lib/mt-daapd/plugins/librsp.so
    2007-11-06 13:45:06 (bb2e592f): Loaded plugin /usr/local/lib/mt-daapd/plugins/librsp.so (rsp/svn-1696)
    2007-11-06 13:45:06 (bb2e592f): New transcode codec list:
    2007-11-06 13:45:06 (bb2e592f): Attempting to load plugin /usr/local/lib/mt-daapd/plugins/libssc-script.so
    2007-11-06 13:45:06 (bb2e592f): Loaded plugin /usr/local/lib/mt-daapd/plugins/libssc-script.so (ssc-script/svn-1696)
    2007-11-06 13:45:06 (bb2e592f): New transcode codec list: ogg,flac,alac
    2007-11-06 13:45:06 (bb2e592f): Plugin loaded: ssc-script/svn-1696
    2007-11-06 13:45:06 (bb2e592f): Plugin loaded: rsp/svn-1696
    2007-11-06 13:45:06 (bb2e592f): Plugin loaded: daap/svn-1696
    2007-11-06 13:45:06 (bb2e592f): Starting rendezvous daemon
    2007-11-06 13:45:06 (bb2e592f): Starting signal handler
    2007-11-06 13:45:06 (bb2e592f): Pid: 4674
    2007-11-06 13:45:06 (bb2e592f): Starting UPnP listener thread
    2007-11-06 13:45:06 (bb2e592f): Opening database
    2007-11-06 13:45:06 (19e27352): upnp listener thread started
    2007-11-06 13:45:06 (bb2e592f): Processing rendezvous message
    2007-11-06 13:45:06 (bb2e592f): Rendezvous socket closed (daap server crashed?) Aborting.
    2007-11-06 13:45:06: Aborting

    Any ideas? maybe a missing link for Rendezvous?

    Greetz

    Osik

    #14220

    Osik
    Participant

    i removed now my complete installation of mt-daapd-svn-1696 and tried svn-1586, which is still running on my old server (FreeBSD 6.2 p4 x86). But i get the same error. I think it’s a problem with x64. Does anybody got mt-daapd running on an x64 (amd64, x86_64) server (linux, freebsd)? i would switch to x86 but i need zfs support which is more stable (freebsd user experiences) on x64.

    I hope someone has a solution for my problem 🙁

    Greetz

    Osik

    ps: ron you did a great job on this tool 😉

    #14221

    rpedde
    Participant

    @osik wrote:

    i removed now my complete installation of mt-daapd-svn-1696 and tried svn-1586, which is still running on my old server (FreeBSD 6.2 p4 x86). But i get the same error. I think it’s a problem with x64. Does anybody got mt-daapd running on an x64 (amd64, x86_64) server (linux, freebsd)? i would switch to x86 but i need zfs support which is more stable (freebsd user experiences) on x64.

    I hope someone has a solution for my problem 🙁

    Greetz

    Osik

    ps: ron you did a great job on this tool 😉

    Getting rid of –enable-upnp would probably help. What other configure flags did you use?

    #14222

    Osik
    Participant

    hi ron,

    i set the following configure flags:

    ./configure –enable-sqlite3 –with-id3tag=/usr/local –enable-oggvorbis –enable-flac –enable-upnp –enable-musepack

    so upnpsupport is already builtin. After that I configured it that way:

    ./configure –enable-sqlite3 –with-id3tag=/usr/local

    But this produces the same error.

    A friend of mine is testing, building and installing svn-1696 on an x86_64 freebsd 7.0 asap. usually he uses svn-1696 on an x86 freebsd 7.0 without having such trouble. i hope i can reply as soon as possible if he also gets this error.

    Greetz

    Osik

    #14223

    Osik
    Participant

    Hi Ron,

    well as i told you above, my friend get the same problem on different hardware but same os and architecture (x86_64).

    I can send u a log from building mt-daapd if this helps.

    Yesterday i tried to building it with avahi support but i get errors when building mt-daapd. So this won’t work too.

    Greetings

    Osik

    #14224

    rpedde
    Participant

    @osik wrote:

    Hi Ron,

    well as i told you above, my friend get the same problem on different hardware but same os and architecture (x86_64).

    I can send u a log from building mt-daapd if this helps.

    Yesterday i tried to building it with avahi support but i get errors when building mt-daapd. So this won’t work too.

    Greetings

    Osik

    Seems like on previous freebsd there were pthreads problems, and there was some hackery in the config script to try and “fix” that.

    I wonder if -lpthreads is now the way to go.

    Can you get a backtrace of the crash using gdb?

    #14225

    Osik
    Participant

    Hi ron,

    using gdb gives me a normal exit. so it doesn’t really crash.

    Here the output of mt-daapd:

    (gdb) r
    Starting program: /usr/local/sbin/mt-daapd
    [New LWP 100180]
    [New Thread 0x801b01120 (LWP 100180)]

    Program exited normally.
    (gdb) quit

    I wonder if this helps.

    Thanks for help

    Greetz

    Osik

    EDIT: For testing i started mt-daapd with -d 9 an -f to see the output. Nothing really changes except that theres is an Segmentation fault after Aborting.

    Rendezvous socket closed (daap server crashed?) Aborting.
    Aborting
    Segmentation fault

    Don’t know if this matters.

    ps: oh btw. on the machine of my friend its now working. he was configuring building and installing for a second time and it works like a charm. Magic….

    #14226

    rpedde
    Participant

    @osik wrote:

    ps: oh btw. on the machine of my friend its now working. he was configuring building and installing for a second time and it works like a charm. Magic….

    Ooh, that sucks. That makes replicating it hard.

    — Ron

    #14227

    Osik
    Participant

    after i installed my system again. but this can take a while.

    I think we can close this thread. I will tell my experiences after reinstalling my system.

    Thanks ron

    Regards

    Osik

    #14228

    Osik
    Participant

    well after reinstalling freebsd 7.0 beta 2 x64 it works like a charm. don’t no how this could be but i would say its fixed.

    thanks ron

    Osik

Viewing 15 posts - 1 through 15 (of 17 total)

The forum ‘Nightlies Feedback’ is closed to new topics and replies.