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

[valdemar]

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

[rpedde]

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

[valdemar]

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

[valdemar]

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$

[rpedde]

@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

[valdemar]

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

[rpedde]

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

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

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?

[rpedde]

@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

[valdemar]

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

[rpedde]

@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

[valdemar]

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

[rpedde]

@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])?

[Author]

Posts