PDA

View Full Version : Crashes on re-scan - can't call method "url" on anundefined value - line 819 of info.pm



John Eckman
2005-03-05, 08:53
I've been doing some more troubleshooting of this issue I mentioned last
week.

Seems to be related to some kind of bad track information in the
database? Maybe a corrupt file in my Mp3 collection?

Running SlimServer 6.0 from the 3-1-2005 nightly, Windows 2000 server,
running as a service.

Large (30,000+) library of mp3s.

If I stop the service, remove the C:\Program
Files\SlimServer\server\Cache folder (and thus the db in it) and the
restart the service, it scans through the libary just fine.

However, whenever I do a rescan (either manually triggered through the
web interface or scheduled via the plug in), the service crashes with
the following entry in the Event log:
Can't call method "url" on an undefined value at:
/Perl/App/Slim/Music/Info.pm at line 819.

Since others don't seem to be having the same problem, I'm guessing it
is something in my library.

Three questions:

1. Is there a better way to trap errors in SlimServer? I've tried
setting some debug options, but when i go to see the log the server's
crashed already and can't show me the log - can the log be set to a real
file, instead of the web output?

2. Any idea what kind of file might cause this behavior? Should I be
looking for a corrupt mp3? An m3u playlist? What would the server be
calling "url" method on?

3. What changes could I make to the module where this crash occurs to
catch the file being scanned at that moment?

Thanks in advance-

John

Dan Sully
2005-03-05, 12:40
* John Eckman shaped the electrons to say...

>1. Is there a better way to trap errors in SlimServer? I've tried
>setting some debug options, but when i go to see the log the server's
>crashed already and can't show me the log - can the log be set to a real
>file, instead of the web output?

At line 367 in slimserver.pl - if you uncomment that DIE, you'll usually be
able to get a backtrace when the server crashes. If it's actually segfaulting
though, that's a bit harder to track down. Your other option is using the
perl debugger: perl -d slimserver.pl

>2. Any idea what kind of file might cause this behavior? Should I be
>looking for a corrupt mp3? An m3u playlist? What would the server be
>calling "url" method on?

The server would call url() on a $track object. This particular error is
happening in cachedPlaylist(), so that's where I would look first. Perhaps a
playlist that is referring to a file that no longer exists.

>3. What changes could I make to the module where this crash occurs to
>catch the file being scanned at that moment?

At Slim/Music/Info.pm in sub cachedPlaylist() - after the my $song line, add:

$song->print();

It then calls $song->tracks(), and expects back a list of $track objects,
encapsulated as a Slim::DataStores::DBI::PlaylistTrack relationship to the
primary song/playlist.

-D
--
Indifference will certainly be the downfall of mankind, but who cares?