You are here: Home » Topic » Error loading plugin /usr/lib/mt-daapd/plugins/ssc-script.so

Error loading plugin /usr/lib/mt-daapd/plugins/ssc-script.so

FireFly Media Server (formerly mt-daapd) Firefly Media Server Forums Firefly Media Server Setup Issues Error loading plugin /usr/lib/mt-daapd/plugins/ssc-script.so

This topic contains 12 replies, has 2 voices, and was last updated by  rpedde 11 years, 8 months ago.

Viewing 13 posts - 1 through 13 (of 13 total)
  • Author
    Posts
  • #1802

    valdemar
    Participant

    Hi,

    I get “Error loading plugin /usr/lib/mt-daapd/plugins/ssc-script.so: plugin declined to load”, which prevents me from streaming flac-files. Syslog dump and sw versions in this thread: http://forums.fireflymediaserver.org/viewtopic.php?p=15040#15040.

    Maybe related issue is this message in extended configuration view:

    Options missing from config.xml
    The options below are in your mt-daapd.conf and Firefly uses them,
    but this web page can’t handle them until they are added to config.xml

    plugins:plugins

    Thanks,
    Valdemar

    #12861

    rpedde
    Participant

    @valdemar wrote:

    Hi,

    I get “Error loading plugin /usr/lib/mt-daapd/plugins/ssc-script.so: plugin declined to load”, which prevents me from streaming flac-files. Syslog dump and sw versions in this thread: http://forums.fireflymediaserver.org/viewtopic.php?p=15040#15040.

    Maybe related issue is this message in extended configuration view:

    Options missing from config.xml
    The options below are in your mt-daapd.conf and Firefly uses them,
    but this web page can’t handle them until they are added to config.xml

    plugins:plugins

    Thanks,
    Valdemar

    That means that either the ssc_codecs or the ssc_script isn’t set in your config.

    #12862

    valdemar
    Participant

    Thanks Ron!

    I had forgot to activate mt-daapd-ssc.sh. Mt-daapd now starts without any errors.

    Unfortunately it still does not trancode flac. I have forced a rescan by deleting the songs.db. I don’t know what else to do. No output to log. SB outputs: “Unable to play “name of song””

    Valdemar

    #12863

    valdemar
    Participant

    I suspected my DB was corrupt, since it did not update. Then I deleted songs.db again, but this time it was unfortunately not recreated at start-up. I get below message instead. How can I recreate songs.db?

    Thanks,
    Valdemar

    Oct 10 18:47:36 LKG7F3AB4 mt-daapd[15928]: Firefly Version svn-1673: Starting with debuglevel 9
    Oct 10 18:47:36 LKG7F3AB4 mt-daapd[15928]: Plugin loaded: daap/svn-1673
    Oct 10 18:47:36 LKG7F3AB4 mt-daapd[15928]: Plugin loaded: ssc-script/svn-1673
    Oct 10 18:47:36 LKG7F3AB4 mt-daapd[15928]: Plugin loaded: rsp/svn-1673
    Oct 10 18:47:36 LKG7F3AB4 mt-daapd[15928]: Starting rendezvous daemon
    Oct 10 18:47:36 LKG7F3AB4 mt-daapd[15928]: Client running
    Oct 10 18:47:36 LKG7F3AB4 mt-daapd[15928]: Starting signal handler
    Oct 10 18:47:36 LKG7F3AB4 mt-daapd[15931]: db_sqlite2_open: unable to open database: /var/cache/mt-daapd/songs.db (/var/cach$
    Oct 10 18:47:36 LKG7F3AB4 mt-daapd[15931]: Error opening db: Misc SQL Error: unable to open database: /var/cache/mt-daapd/so$

    #12864

    rpedde
    Participant

    @valdemar wrote:

    I suspected my DB was corrupt, since it did not update. Then I deleted songs.db again, but this time it was unfortunately not recreated at start-up. I get below message instead. How can I recreate songs.db?

    Thanks,
    Valdemar

    Oct 10 18:47:36 LKG7F3AB4 mt-daapd[15928]: Firefly Version svn-1673: Starting with debuglevel 9
    Oct 10 18:47:36 LKG7F3AB4 mt-daapd[15928]: Plugin loaded: daap/svn-1673
    Oct 10 18:47:36 LKG7F3AB4 mt-daapd[15928]: Plugin loaded: ssc-script/svn-1673
    Oct 10 18:47:36 LKG7F3AB4 mt-daapd[15928]: Plugin loaded: rsp/svn-1673
    Oct 10 18:47:36 LKG7F3AB4 mt-daapd[15928]: Starting rendezvous daemon
    Oct 10 18:47:36 LKG7F3AB4 mt-daapd[15928]: Client running
    Oct 10 18:47:36 LKG7F3AB4 mt-daapd[15928]: Starting signal handler
    Oct 10 18:47:36 LKG7F3AB4 mt-daapd[15931]: db_sqlite2_open: unable to open database: /var/cache/mt-daapd/songs.db (/var/cach$
    Oct 10 18:47:36 LKG7F3AB4 mt-daapd[15931]: Error opening db: Misc SQL Error: unable to open database: /var/cache/mt-daapd/so$

    mkdir /var/cache/mt-daapd
    chown nobody /var/cache/mt-daapd (or whatever your runas user is)

    If there is a .journal file in there, you can delete that, too. That should do it. So long as the directory is empty and writable by the run_as user, then it should re-create it.

    — Ron

    #12865

    valdemar
    Participant

    Thank you, Ron. The songs.db is back up.

    Unfortunately problems persist:

    1) Not serving songs: SB still outputs: “Unable to play “name of song”” and neither Banshee (full stop sign) nor Amarok (“No suitable input plugin. This often means that the url’s protocol is not supported. Network failures are other possible causes”) can play songs. Both sw players play flac natively, so it is not a transcoding issue only.

    2) No database update – last month’s entries into Music Folder not reflected and accessible.

    Valdemar

    #12866

    rpedde
    Participant

    @valdemar wrote:

    Thank you, Ron. The songs.db is back up.

    Unfortunately problems persist:

    1) Not serving songs: SB still outputs: “Unable to play “name of song”” and neither Banshee (full stop sign) nor Amarok (“No suitable input plugin. This often means that the url’s protocol is not supported. Network failures are other possible causes”) can play songs. Both sw players play flac natively, so it is not a transcoding issue only.

    2) No database update – last month’s entries into Music Folder not reflected and accessible.

    Valdemar

    1) Do the needful — check that you have flac in your transcode codecs, and that you’ve added the full path to wavstreamer and the flac decoder binary in the transcode script. Run the script by hand to make sure it will output data, and cat that into a file and see if it is a valid wav file.

    2) Check permissions. If it scanned the rest but not the new ones, it’s likely permissions.

    #12867

    valdemar
    Participant

    1) Do the needful — check that you have flac in your transcode codecs, and that you’ve added the full path to wavstreamer and the flac decoder binary in the transcode script. Run the script by hand to make sure it will output data, and cat that into a file and see if it is a valid wav file.

    I didn’t know it was needful :-). The Unslung version ran out of the box, if I remember correctly. Anyway, I appreciate you patience. This part is SOLVED.

    2) Check permissions. If it scanned the rest but not the new ones, it’s likely permissions.

    I thought myself it was a permissions problem, but all permissions are the same. Any other ideas?

    #12868

    rpedde
    Participant

    @valdemar wrote:

    1) Do the needful — check that you have flac in your transcode codecs, and that you’ve added the full path to wavstreamer and the flac decoder binary in the transcode script. Run the script by hand to make sure it will output data, and cat that into a file and see if it is a valid wav file.

    I didn’t know it was needful :-). The Unslung version ran out of the box, if I remember correctly. Anyway, I appreciate you patience. This part is SOLVED.

    Aaaaah… clearly I need to add something to the wiki so folks know it’s needful. 🙂

    2) Check permissions. If it scanned the rest but not the new ones, it’s likely permissions.

    I thought myself it was a permissions problem, but all permissions are the same. Any other ideas?

    Hmm… the best way to debug that I think is to do a full scan at debuglevel 9. Then search through the debug log to find each “component” of the path… like “/mnt/m3”, then “/mnt/mp3/new music”, then “/mnt/mp3/new music/from work”, etc and follow the scanning process of a song that doesn’t appear.

    If it doesn’t scan it, it will emit *some* kind of error about it. Whether it’s an error about bad permissions, or metadata it doesn’t understand or whatever. Something will be logged.

    Someone had a patch to push up the debugging info for failures to scan, and I might do something like that — throw up more visible errors for scan failures on first run only, so that the logs don’t get swamped with stuff, but problematic files are still visible on low debug levels.

    — Ron

    #12869

    valdemar
    Participant

    Hmm… the best way to debug that I think is to do a full scan at debuglevel 9. Then search through the debug log to find each “component” of the path… like “/mnt/m3”, then “/mnt/mp3/new music”, then “/mnt/mp3/new music/from work”, etc and follow the scanning process of a song that doesn’t appear.

    If it doesn’t scan it, it will emit *some* kind of error about it. Whether it’s an error about bad permissions, or metadata it doesn’t understand or whatever. Something will be logged.

    Debug level 9 does not output any error messages, I am afraid.

    Someone had a patch to push up the debugging info for failures to scan, and I might do something like that — throw up more visible errors for scan failures on first run only, so that the logs don’t get swamped with stuff, but problematic files are still visible on low debug levels.

    I have not been able to track that patch down

    Valdemar

    #12870

    rpedde
    Participant

    @valdemar wrote:

    Debug level 9 does not output any error messages, I am afraid.

    It has to emit something. As it scans the directory, it will emit a “found %s” message for each directory element. You should be able to follow at least as far down the path as it gets to the actual songs.

    If it’s a directory and it can’t opendir it, it will log a message. If it’s a file that’s on the extensions list, it will scan and add it to the database, or emit an error. No other options.

    So it’s in the log file. You’ll have to walk back every single directory from the top and follow what it’s doing in each subdirectory, but it’s there.

    Or else the music isn’t in a directory covered by the mp3_dir option. Those are the only two options.

    — Ron

    #12871

    valdemar
    Participant

    It has to emit something. As it scans the directory, it will emit a “found %s” message for each directory element. You should be able to follow at least as far down the path as it gets to the actual songs.

    Well, you are right. I thought everything would turn up in syslog; but after creating a log specific to mt-daapd, I got the information needed.

    The thing is that the meta data cannot be read. Example:

    2007-10-22 17:30:22 (00004000): Cannot read FLAC metadata from /usr/public/flac/Arturo Benedetti Michelangeli/ - Schumann ....

    This is not an isolated problem. I get this behavior with hundreds of songs. They all seem to include proper metadata.

    The problem might be related to this: http://forums.fireflymediaserver.org/viewtopic.php?p=14937
    Any solution yet?

    Thanks,
    Valdemar

    #12872

    rpedde
    Participant

    @valdemar wrote:

    It has to emit something. As it scans the directory, it will emit a “found %s” message for each directory element. You should be able to follow at least as far down the path as it gets to the actual songs.

    Well, you are right. I thought everything would turn up in syslog; but after creating a log specific to mt-daapd, I got the information needed.

    The thing is that the meta data cannot be read. Example:

    2007-10-22 17:30:22 (00004000): Cannot read FLAC metadata from /usr/public/flac/Arturo Benedetti Michelangeli/ - Schumann ....

    This is not an isolated problem. I get this behavior with hundreds of songs. They all seem to include proper metadata.

    The problem might be related to this: http://forums.fireflymediaserver.org/viewtopic.php?p=14937
    Any solution yet?

    Thanks,
    Valdemar

    Yeah, that’s possible. Can you send me one of those flacs with a note that it’s a flac that won’t read metadata? ([email protected])?

Viewing 13 posts - 1 through 13 (of 13 total)

The forum ‘Setup Issues’ is closed to new topics and replies.