please update to svn6809 or check tomorrow's build.  the "hasChanged" logic, meant for 6.5 and not really useful for 6.2, has been removed and should help to clear this up.  

Similiar crash with the 4/4/06 6.2.2 nightly:
2006-04-04 06:12:45.3348 Can't locate object method "artist" via package "Class::DBI::Object::Has::Been::Deleted" at /PerlApp/Slim/DataStores/Base.pm line 179.

What actions are you doing at the time of the crash?
Can you disable trackstat and see if that makes any difference?
I'm wondering if you have a conflict between the trackstat database and the slimserver database, since the log seems to show a new track being created from a trackstat track find.  If this track doesn't exist, slimserver would not keep it as an active object.

(In reply to comment #3)
> What actions are you doing at the time of the crash?
> Can you disable trackstat and see if that makes any difference?
> I'm wondering if you have a conflict between the trackstat database and the
> slimserver database, since the log seems to show a new track being created from
> a trackstat track find.  If this track doesn't exist, slimserver would not keep
> it as an active object.
> 

You mentioned pulling _hasChanged from the 4/4 nightly... however, I see it mentioned in the latest log. Could your changes not have made it the 4/4 .exe burn?

The crash will occur spontaneously if left sitting long enough, but I can always crash it by playing an entire MusicMagic generated playlist (click MM next to song title, click play at the top of the playlist produced). Note: My MM is set to create a 40 track playlist.... maybe it's too big?

I've deleted and rebuilt my slimserver.db several times, no improvement noted. I haven't tried deleting and rebuilding my MM database yet...

For tonight, I'll disable TrackStat... and see what that does. Next I'll delete and rebuild my MM database. Any other ideas?

(Thanks for your help, BTW)

you will still see some haschanged stuff, but the logic did change.  The change I speak of was done (not by me) on saturday, so certainly should be in today's build.

Created attachment 1179 [details]
Log (no Trackstat... no crash)

Thanks.  ok, next step...are you able to wipe and rebuild the trackstat db...or whatever it is using internall?
probably worth contacting the author at this point. 

one other possible thing, accented characters.  These are not yet working from MIP.  Nothing to do with slimserver end of it, but what the server recieves is a garbled version of any unicoded data.   

(In reply to comment #7)
> next step...are you able to wipe and rebuild the trackstat db...or
> whatever it is using internall?
> probably worth contacting the author at this point. 
> 
> one other possible thing, accented characters.  These are not yet working from
> MIP.  Nothing to do with slimserver end of it, but what the server recieves is
> a garbled version of any unicoded data.   
> 

I've cleared and rebuilt the trackstat database... still crashing. I also cleared and rebuilt the MMM database. No change. This may be a unicode thing after all... I've contacted Erland. I think Whicken and his team are actively working on the unicode bug.  Thanks for all your help KDF.

I'm sure Whicken will get it working as soon as possible.  Unicode is not easy, seemingly more difficult in a windows world.  The unix version seems ok, so they are certainly on the way.  Hopefully erland can grab track id's instead of the urls?  That might help.  

Just for information to help us find the problem:
- TrackStat neither creates nor remove tracks in the slimserver database tables. The only write operation towards the standard slimserver tables, if I remember correct, is to set the rating and thats only enabled in 6.5 so it can't be the problem here.
- TrackStat stores its own information in the standard slimserver database but in a separate table called track_statistics.
- TrackStat can't use track id's, the reason is that one of the main points with TrackStat is that its information should survive a database rescan and this would not be possible if track id's where used since these are changed during database rescan.
- TrackStat reads track information spontaneously from the slimserver database in a number of situations such as:
  * When ratings is to be displayed on on the SqueezeBox display
  * When ratings is to be displayed in the web interface
  * When a new track is starting to play
  * When TrackStat statistics is viewed/refreshed in the web interface for the TrackStat plugin

Some thoughs:
If the problem is related to TrackStat I suspect it might be caused by the removed track if TrackStat tries to read this after it has been removed or something. I have posted a version of TrackStat with more debug information to make it easier to see if there are any TrackStat code executed or not at the moment of the crash. 

TrackStat sends ratings and statistics to MusicMagic, maybe this causes the standards slimserver MusicMagic plugin to re-read information from MusicMagic ? Could this cause the track to be removed ?

Is TrackStat ratings displayed on the SqueezeBox display at the moment of the crash ?
In that case, how ? Via the MusicInfoSCR screensaver or some other way ?

Is TrackStat ratings displayed in the slimserver web interface at the moment of the crash ?

(In reply to comment #10)
> - TrackStat can't use track id's, the reason is that one of the main points
> with TrackStat is that its information should survive a database rescan and
> this would not be possible if track id's where used since these are changed
> during database rescan.

Would it be possible to use MusicDNS to id tracks? (http://www.musicdns.org/)

> - TrackStat reads track information spontaneously from the slimserver database
> in a number of situations such as:
>   * When ratings is to be displayed on on the SqueezeBox display
>   * When ratings is to be displayed in the web interface
>   * When a new track is starting to play
>   * When TrackStat statistics is viewed/refreshed in the web interface for the
> TrackStat plugin

Interesting that you should mention the web interface as a variable. I've been using fishbone almost exclusivley to "trigger" the bug (steps: make a MMM playlist by clicking MM beside song -- click "play" at the very top of the returned MM playlist -- crash. Slimserver goes down. Squeezebox2 loses its connection and shuts off. Just for fun I tried following the steps above using the remote + player interface only (no browser open), and the results were different.  Press and hold play from now playing screen brings up MM playlist. Pressing play at this point =does not= shut down Slimserver, however the playlist does not play the listed titles sequentially by itself. Each track must be manually queued. From this point forward MM no longer works, and although the MM icon still appears besides tracks, no new playlist can be generated.

Does this shed any light?

 
> Some thoughs:
> If the problem is related to TrackStat I suspect it might be caused by the
> removed track if TrackStat tries to read this after it has been removed or
> something. I have posted a version of TrackStat with more debug information to
> make it easier to see if there are any TrackStat code executed or not at the
> moment of the crash. 

I don't know what is meant by "removed" in this instance. Just to be clear... I'm not removing / renaming files during the crashes.... and have not moved or edited tracks since rebuilding the MMM, slimserver, and Trackstat db's.
 
> Is TrackStat ratings displayed on the SqueezeBox display at the moment of the
> crash ?

No, not every time.

> In that case, how ? Via the MusicInfoSCR screensaver or some other way ?

I no longer use MusicInfoSCR. I just use the default "now playing" with a custom "TITLE [TRACKSTATRATINGDYNAMIC] format specified.
> Is TrackStat ratings displayed in the slimserver web interface at the moment of
> the crash ?

Yes. Most likely at least one or more of the tracks appearing somewhere on the web interface will have ratings displayed. 

Okay... on further investigation. If the web browser is never opened... I can get =everything= to work without crashing! I repeated the steps above (creating an MM playlist, etc.) without producing any crash whatsoever. Everything is working... I can send ratings to MM via Trackstat, etc. So... it looks like the problem somehow involves the web interface.

Could you try the TrackStat version I posted in this thread which shows more log messages:
http://forums.slimdevices.com/showthread.php?t=22677

If the problem only happens when you use TrackStat, I suspect that the problem might be that something(not TrackStat or you) removes a track from the slimserver db and exactly at the same moment the rating for that track should be shown in the web interface. The result is that TrackStat tries to read the track from the database but since the track just have been removed it crashes instead. But to know that this is the problem I need the debug log files from a crash when you have used the TrackStat version in the thread specified above which shows more debug information.

erland, I'm sure this is related to the problem in MIP with accented characters.  Because they are affected, slimserver will not see the file as existing, and coudl be subject to cleanup at some point.  If the track is brought through trackstat, and it then tries to look up the file in the db, there would be a problem.  MIP is working on the problem, and I was not blaming trackstat, but keeping you in the loop in case you might have a workaround to keep your plugin happy until then.

According to the last crash log with the TrackStat with more debugging info it is not TrackStat that directly causes the crash, but I think it might be TrackStat the indirectly causes by making the slimserver to check if the track exists and this probably results in a crash in the slimserver code later. However, I have released a new TrackStat version (1.13.1) that does not call objectForUrl in this situation which hopefully temporary solves the problem until the unicode bug in MMM is corrected.

Could you try the 1.13.1 TrackStat version and see if it works better, please report back if it works or not and if it doesn't please post the debug log from that version when it crashes.

Trackstat 1.13.1 effectively prevents the crash. As far as I'm concerened, this solves the problem
(until the unicode bug in MMM is corrected.). Thanks KDF and Erland!