Please give more details on the steps you take to reproduce this, it it doesn't seem that it should be possible from a quick look at the code.

I saved a new playlist.

Thanks.  reprduced and have a fix (change line 264 to "if (ref $params->{'playlist'})"

However, this now shows a crash at line 290.  This crash occurs when saving, and also when clicking the pwd link or "done editing" link from edit playlist page. I think I need to change a few params in urls, but I'll work on it for tonight.

actually...in looking at this, I've uncovered a number of editPlaylist problems/crashes and I'm most of the way through working them all out.  browse_playlist.html and edit_playlist.html need to use playlist.id=, Web/EditPlaylist.pm needs to grab playlist.id as a param, and Slim::Formats::Playlists::Base::_pathForItem needs to deal with the fact that it is getting track objects instead of urls (m3u files are being written using the class references currently :)

Last issue I'm dealing with is when making changes to playlists via edit playlist, the db is adding the changes as a new set of track.  Thus you end up with the unedited track list followed by the editted track list.  

Dan,  If you want to review this first, I can post a diff later (if I can get internet back online at home) or I can just commit when I have a working result.

Subject: Re:  Playlist Update crashes SS in BrowseDB.pm

>Dan,  If you want to review this first, I can post a diff later (if I can get
>internet back online at home) or I can just commit when I have a working
>result.

Go ahead and commit when you have something working.

Thanks.

Hopefully fixed at change 8028, at least as far as the crash described here and the followup crash.  What I have discovered after this update is:

1) that playlist writing is not always writing out the filenames because the routines have been based on getting a url.  Now they are being given full track objects, so they end up very odd.

2) Edit playlist, move or delete a file, causes the database to add the tracks to the playlist all over again, effectively doubling the number of tracks.  This is also written out to the file.  however, browse playlist will still show only the original list in it's original order.
I think this last one has to do with a bad line of code that is attempting to delete the playlist, but doesn't seem to accomplish that.  

renoting summary and changing severity to reflect current status.

This should be fixed as of change 8214.

Please reopen if you can reproduce.

thanks