SSODS F.A.Q.¶
Under construction, never finished and probably always outdated.
Coming sooner or later.
Go here for the old SSODS 3.x FAQ.
Use internal, running instance of mysqld¶
On TurboStations:
dbsource: dbi:mysql:database=slimserver:host=localhost:port=3306:mysql_socket=/tmp/mysql.sock
On DiskStations: don’t know, but probably something similar to the above
Slow Artwork Scanning¶
In SBS: go to Server Settings → Advanced → Performance and set «Artwork Resampling» to «Resize Artwork».
Use binary Perl modules shipped with SBS¶
SSODS comes with all binary Perl modules required by SBS. This is because the ones shipped with SBS may or may not work on your system. SSODS deactivates all the binary Perl modules in SBS ($SSDIR/CPAN/...). If you want to use a module that is shipped with SBS you need to tell SSODS. E.g. for Audio::Scan you would do (untested..):
mv /opt/ssods4/var/home/SqueezeboxServer/CPAN/Audio/Scan.pm-SSODS-off /opt/ssods4/var/home/SqueezeboxServer/CPAN/Audio/Scan.pm touch /opt/ssods4/var/home/SqueezeboxServer/CPAN/Audio/Scan.pm-SSODS-ignore mv /opt/ssods4/var/home/SqueezeboxServer/CPAN/arch/5.10/arm-linux-gnueabi-thread-multi/auto/Audio/Scan/Scan.so-SSODS-off /opt/ssods4/var/home/SqueezeboxServer/CPAN/arch/5.10/arm-linux-gnueabi-thread-multi/auto/Audio/Scan/Scan.so touch /opt/ssods4/var/home/SqueezeboxServer/CPAN/arch/5.10/arm-linux-gnueabi-thread-multi/auto/Audio/Scan/Scan.so-SSODS-ignore
SSODS renames all relevant files to *-SSODS-off. If you create an empty *-SSODS-ignore file SSODS will ignore this particular file. You also need to rename the xy-SSODS-off to xy. You need to do this with all files that are included in the module in question. See /opt/ssods4/share/sbs/shipped-binaries for hints (you can also delete the relevant lines in there and re-install the SBS tar ball).
Note that you have to replace arm-linux-gnueabi-thread-multi with the directory that corresponds to your system (arm-linux-gnueabi-thread-multi for the arm version of SSODS, powerpc-linux-thread-multi for the ppc version of SSODS and i386-linux-thread-multi for the i686 version of SSODS).
Alternatively, you can disable this mechanism altogether by creating a file SSODS_SSUSEBINARIES in the SBS directory (e.g. touch /opt/ssods4/var/home/SqueezeboxServer/SSODS_SSUSEBINARIES). Once you re-installed the SBS tar ball SSODS should not touch any of the files anymore.
Automatic Library Scanning¶
Recent (development?) SBS versions use the Linux::Inotify2 Perl module to monitor the music library directories for changes. This allows SBS to detect newly added files and to initiate a scan of these files automatically.
SSODS does not include this module. This is because SSODS is built to run on different systems, which may or may not have the inotify functionality in the Linux kernel.
The «My Music → Browse Music Folder» is a work-around to add a new album to the database immediately without triggering a rescan of the whole library. Browse to the newly added album and add it to the playlist, which will run the scanner program on this directory, which will add the files to the library.
However, even without the Inotify interface SBS will automatically add new files to the database. It does so by checking the music library directories every so often (every 10 minutes?), which enables it to detect new files. So even though it’s not real-time automatic scanning still works in SSODS.
Mplayer¶
SSODS does not include mplayer (anymore). SSODS is built with a minimal approach. It’s meant to be used with «normal» music files (i.e. mp3, flac, ogg) and hardware players (SB3, Radio, Boom, Transporter). This may break the ability to play certain exotic music formats for some users. My recommendation in this case: convert the files to mp3.
It is, however, possible to use mplayer obtained from another source (Optware, compiled yourself, ..) with SBS in SSODS. To do so SBS must be able to find the mplayer binary. It looks in /opt/ssods4/bin for external programs. Hence, you need to copy or link the binary to that path. E.g.:
ln -s /path/to/mplayer /opt/ssods4/bin
How is SSODS made and why is it made like this?¶
Squeezebox Server is a Perl program that requires a standard Perl and some additional modules. SSODS comes with Perl and those modules.
Some Perl modules shipped with SBS are plain Perl. They work out-of-the box with any (recent) Perl interpreter. Other modules, such as the Audio::Scan module, include c code that needs to be compiled into libraries, of which functions are then usable from plain Perl. SBS comes with the required binary modules that are not included in the standard Perl distribution/package.
In theory one could use these libraries/modules with SSODS. It even works in practice quite well for i386 and it mostly works on the arm platform but it’s a mess on powerpc (and some devices that use ancient compilers, such as the Diskstations). I’ve seen very strange behaviour (of Perl functions, SBS functionality) when using the binaries from SBS even if they should be binary compatible. This is not Windows where an .EXE from 1992 is still running fine in the most recent version. This is Linux where there is a zillion of ways of doing stuff.
Hence I build all required modules and include them with SSODS. And I disable the corresponding ones included in SBS. This is the way I found it working best (and I’ve tried many ways).
Unsupported hardware, unsupported Squeezebox Server versions¶
If your hardware is not supported (anymore) or if you want to run a SBS version that is not supported by SSODS (missing Perl modules, too old versions of Perl modules, etc.) you have several options (ordered by increasing level of geekness required):
- You stay with the current supported version of SBS for SSODS. It does play your music, doesn’t it? If so, it’s going to do that even if the current SBS is at version 100000000.
- You wait for SSODS to support your desired version of SBS, which may or may not happen.
- You tell SSODS to use the modules included with SBS. Some folks have successfully done that. See Use binary Perl modules shipped with SBS above. This is more or less easy and may or may not work.
- Compile the missing modules yourself. Some folks successfully did so using GCC from the appropriate Optware feed (see this thread).
- Build SSODS yourself with the updated modules. The build scripts are included in the SBS distribution:
/opt/ssods4/share/ssods/ssods-buildscripts.tar.bz2. Compilers for some platforms are available for download at my homepage: diskstation toolchains. However, this is not trivial and requires a rather deep understanding of stuff. It is also possible to cross-compile SSODS by setting/enhancing thebuildssods.cfgvariables accordingly. This requires even more geekness (I failed at doing so).
What hardware is recommended?¶
Marvell Kirkwood based and i386 based devices.
What hardware is not recommended?¶
Any PowerPC based device.
How long is SSODS going to support my platform?¶
Nobody knows.
What file types are supported in SSODS?¶
SSODS is built as the minimal system required to use Squeezebox Server. It may or may not include additional tools required to play file or stream formats that your player cannot play natively. Use .mp3 files or any of the other formats that your player plays natively (depends on the model, check the respective specs).
DNS / hostname resolving issues¶
Use this test script to check if SSODS/Perl is able to do hostname lookups:
#!/opt/ssods4/bin/perl
#
# stolen from http://www.peter.com.au/perl/index.html#getdnsinfo http://www.peter.com.au/perl/index.html#getdnsinfo
#
use strict;
use warnings;
use Socket qw(AF_INET);
usage() if $#ARGV == -1;
display_info( @ARGV );
sub display_info {
foreach (shift) {
my ($ip, $host, $aliases, $addrtype, $length, @addrs);
$ip = $_;
if ( /^(d+).(d+).(d+).(d+)$/ ) {
print "IP is $ipn";
($host, $aliases, $addrtype, $length, @addrs) =
gethostbyaddr( pack( 'C4', $1, $2, $3, $4 ), AF_INET );
die "Reverse lookup failed to find name for $ipn" unless $host;
}
$host = $ip unless $host;
print "Hostname is $hostn";
($host, $aliases, $addrtype, $length, @addrs) = gethostbyname( $host );
die "Lookup failed to find address for $hostn" unless @addrs;
print "Maps to these IPs:n";
foreach (@addrs) {
print "IP: ".join( '.', unpack( 'C4', $_ ) )."n";
}
}
}
sub usage {
print STDERR <<EOM;
Usage: getdnsinfo.pl <IP|host>...
Example `getdnsinfo.pl www.interarchy.com'
EOM
exit( 0 );
}
# eof
Note: this will be included in future SSODS versions as /opt/ssods4/bin/checkdns.pl.
modules.conf, SSODS version and SBS version¶
Most SSODS releases are made for one (or more) particular release(s) of SBS. E.g. SSODS 4.9.1 is for SBS 7.5.1 and 7.5.2. Because SBS is very picky about certain Perl modules (particularly, the Audio::Scan module, but also others) there is a modules.conf file in the SBS package. The file states the minimal version for certain modules and, for some, modules asserts a particular version. This is because some modules (Audio::Scan, Image::Scale, and others) are made for SBS, i.e. they are developed in parallel and their API evolves and changes. This is why a certain version of SBS requires a certain version of this-or-that module.
When you want to run a SBS version other than the one a particular version of SSODS is made for, it might complain about wrong or missing Perl modules. You have several options:
- compile a suitable version of SSODS (the build scripts are included, see above) that has the right module versions
- patch the
modules.conffile. This is not recommended since it will most likely break some stuff. - choose a version of SBS that fits SSODS. This is the recommended solution. I.e. at the time of this writing you would use SSODS 4.9.1 with SBS 7.5.2.
Known Bugs¶
Plenty. Among them:
Passwords longer than 8 chars are useless¶
If you set a SSODS web interface password only the first 8 characters of the password are actually used. E.g. if you enter «1234567890» as the password only «12345678» is actually used. You wouldn’t usually notice this because this happens when setting the password and also when entering the password to access the page. Never mind. 8 characters should be enough to protect SSODS. :)