PDA

View Full Version : Slimserver probl. music scan pukes



sinking_fast
2005-08-06, 06:24
Hi All! First post on the forums. I hope I found the right place for this question. If no perhaps a kind moderator can move it to the appropriate forum.

With that said, I have installed, configured and tested SlimServer on a Buffalo Linkstation for purposes of eventually serving up music files to a yet to be purchased SB. I am running into a bit of a problem, however, when it comes to getting SS to scan my music files. I have about 4500+ songs located on a shared drive of the Buffalo LS located in the /mnt/share directory. When I initiate slimserver.pl in the foreground I can watch as it begins its scan as well as what appears to be its eventual crash. I have included a series of "error" messages that scroll over and over and over -- i.e. it seems to be stuck on something. I'm hoping someone with some expertise can see what's the matter and suggest a solution.

FWIW I am running the most current stable version available via the Download page. Same goes with perl.

Many thanks!

Use of uninitialized value in substr at /mnt/slimserver/CPAN/Audio/APETags.pm li
ne 208.
Use of uninitialized value in substr at /mnt/slimserver/CPAN/Audio/APETags.pm li
ne 208.
Use of uninitialized value in substr at /mnt/slimserver/CPAN/Audio/APETags.pm li
ne 209.
Use of uninitialized value in substr at /mnt/slimserver/CPAN/Audio/APETags.pm li
ne 209.
substr outside of string at /mnt/slimserver/CPAN/Audio/APETags.pm line 228.
Use of uninitialized value in substr at /mnt/slimserver/CPAN/Audio/APETags.pm li
ne 227.
Use of uninitialized value in substr at /mnt/slimserver/CPAN/Audio/APETags.pm li
ne 228.
substr outside of string at /mnt/slimserver/CPAN/Audio/APETags.pm line 228.
Use of uninitialized value in pattern match (m//) at /mnt/slimserver/CPAN/Audio/
APETags.pm line 202.
Use of uninitialized value in substitution (s///) at /mnt/slimserver/CPAN/Audio/
APETags.pm line 206

dean
2005-08-06, 08:03
It looks like you have an APE file in there that has tags that are
confusing slimserver. Can you run SlimServer with the --d_info flag
and look at the output and see which file is being processed when you
get those errors?

On Aug 6, 2005, at 6:24 AM, sinking_fast wrote:

>
> Hi All! First post on the forums. I hope I found the right place
> for
> this question. If no perhaps a kind moderator can move it to the
> appropriate forum.
>
> With that said, I have installed, configured and tested SlimServer
> on a
> Buffalo Linkstation for purposes of eventually serving up music
> files to
> a yet to be purchased SB. I am running into a bit of a problem,
> however, when it comes to getting SS to scan my music files. I have
> about 4500+ songs located on a shared drive of the Buffalo LS located
> in the /mnt/share directory. When I initiate slimserver.pl in the
> foreground I can watch as it begins its scan as well as what
> appears to
> be its eventual crash. I have included a series of "error" messages
> that scroll over and over and over -- i.e. it seems to be stuck on
> something. I'm hoping someone with some expertise can see what's the
> matter and suggest a solution.
>
> FWIW I am running the most current stable version available via the
> Download page. Same goes with perl.
>
> Many thanks!
>
> Use of uninitialized value in substr at
> /mnt/slimserver/CPAN/Audio/APETags.pm li
> ne 208.
> Use of uninitialized value in substr at
> /mnt/slimserver/CPAN/Audio/APETags.pm li
> ne 208.
> Use of uninitialized value in substr at
> /mnt/slimserver/CPAN/Audio/APETags.pm li
> ne 209.
> Use of uninitialized value in substr at
> /mnt/slimserver/CPAN/Audio/APETags.pm li
> ne 209.
> substr outside of string at /mnt/slimserver/CPAN/Audio/APETags.pm line
> 228.
> Use of uninitialized value in substr at
> /mnt/slimserver/CPAN/Audio/APETags.pm li
> ne 227.
> Use of uninitialized value in substr at
> /mnt/slimserver/CPAN/Audio/APETags.pm li
> ne 228.
> substr outside of string at /mnt/slimserver/CPAN/Audio/APETags.pm line
> 228.
> Use of uninitialized value in pattern match (m//) at
> /mnt/slimserver/CPAN/Audio/
> APETags.pm line 202.
> Use of uninitialized value in substitution (s///) at
> /mnt/slimserver/CPAN/Audio/
> APETags.pm line 206
>
>
> --
> sinking_fast
>

sinking_fast
2005-08-06, 09:30
Hi dean, I took a brute-force approach to the problem before reading your reply and simply moved the ape files out of my music collection -- I didn't have that many to begin with. That did change things. Didn't solve them but it did change things. I am getting a different error that has me stumped. Here's the error message:

DBD::SQLite::db commit failed: database is full(13) at dbdimp.c line 217 at /mnt
/slimserver/Slim/DataStores/DBI/DBIStore.pm line 780.
DBD::SQLite::db commit failed: database is full(13) at dbdimp.c line 217 at /mnt
/slimserver/Slim/DataStores/DBI/DBIStore.pm line 780.
DBD::SQLite::db do failed: database is full(1) at dbdimp.c line 401 at /mnt/slim
server/Slim/DataStores/DBI/DataModel.pm line 235.
DBD::SQLite::db do failed: database is full(1) at dbdimp.c line 401 at /mnt/slim
server/Slim/DataStores/DBI/DataModel.pm line 235.
END failed--call queue aborted.

Plenty of storage space available on the hard drive. Any ideas?

Marc D.Field
2005-08-06, 14:34
In article news:sinking_fast.1tcpsc (AT) no-mx (DOT) forums.slimdevices.com, sinking_fast <sinking_fast.1tcpsc-NUepA2SMhDQqspMVqqL2D+4xXEVPTSb/VpNB7YpNyf8 (AT) public (DOT) gmane.org> wrote:
>/mnt/slim
>server/Slim/DataStores/DBI/DataModel.pm line 235.
>DBD::SQLite::db do failed: database is full(1) at dbdimp.c line 401 at
>/mnt/slim
>server/Slim/DataStores/DBI/DataModel.pm line 235.
>END failed--call queue aborted.
>
>Plenty of storage space available on the hard drive. Any ideas?


Hi,

Do you know where SlimServer is storing your database file? My guess is that it is storing the database on the smaller partition of the LinkStation (mounted as / and *very* small) and really is running out of space. You really want to store the database on the larger partition, which is mounted as /mnt. You can supply a command line switch when you run slimserver.pl to specify the location of the database. Take a look at the SlimServer readme or the suggestion on my website, http://fieldnetworks.com/slim/linkstation.html.

Marc

sinking_fast
2005-08-06, 15:55
Hi Marc,

It was your website that I followed verbatim that got me this far. I am familiar with your suggestion of placing the data in the /mnt directory tree because of space considerations. I am *pretty* certain that I properly configured slimserver according to your directions. How could I verify that I have everything pointing to the right place?

edit: In answer to your question, .slimserversql.db is being stored in /mnt/slim-data. Is this good?

Thanks,

Jim

Marc D. Field
2005-08-06, 20:05
On 08/06/2005 03:55 PM, sinking_fast wrote:
> It was your website that I followed verbatim that got me this far. I
> am familiar with your suggestion of placing the data in the /mnt
> directory tree because of space considerations. I am *pretty* certain
> that I properly configured slimserver according to your directions. How
> could I verify that I have everything pointing to the right place?

Hi Jim,

It sounds like there are two possibilities:

Possibility #1. The problem is the placement of the database file. How
did you invoke SlimServer? Did you use the --cachedir /mnt/slim-data
option? If so, I'd check whether there is a file called
..slimserversql.db in your /mnt/slim-data directory (use ls -AlF; plain
ls will not show the file). If you did use the --cachedir option and
the file is there, I'd look to possibility #2. If the database file
isn't in /mnt/slim-data, you'll need to track down the database file
(probably in /root or /etc) and delete it, and then try again.

Possibility #2. The problem has to do with the ape file crash. I'd
delete the database file and try again. It could be that the database
became corrupt from the bad session when you had the ape files in your
music directory.

I'm sure there are other possibilities too, but hopefully this is a good
start.

Marc

sinking_fast
2005-08-07, 10:36
On 08/06/2005 03:55 PM,....<snip>....
I'd delete the database file and try again.
....<snip>....
Marc

Hi Marc,

Success!! Deleted the database file, ran another scan and it completes without incident. All music files found and indexed. The database file must have been corrupt to some extent and caused things to hickup with subsequent runs. Many thanks for your assistance!

Jim