as mentioned int the forum, this log is meaningless in regard to the problem.  These are simply notices of missing graphics, which is due to the in-progress work on the Default skin.

Did you do a search before filing this?  Does bug2739 not match your issue?  If not, please explain specific differences.  Perhaps try debugging with d_command  and d_parse and attaching to bug2739 unless you really feel your bug is not a duplicate.

Subject: Re:  Can't save Playlists

I searched before filing, I'm not sure that bug 2739 matches mine, because my playlists never save at all, they don't save occasionally. I added the d_command and d_parse debug choices, and trying to save resulted in the following:

2006-01-09 16:12:41.5481 Dispatch: requestFromArray(playlist save Untitled)
2006-01-09 16:12:41.5493 
2006-01-09 16:12:41.5497 Request: Command [00:04:20:06:17:63->playlist save] (Dispatchable)
2006-01-09 16:12:41.5500    Param: [_title] = [Untitled]
2006-01-09 16:12:41.5503 Commands::playlistSaveCommand()
2006-01-09 16:12:41.7116 Request: Command [00:04:20:06:17:63->playlist save] (Done)
2006-01-09 16:12:41.7121    Param: [_title] = [Untitled]
2006-01-09 16:12:41.7124    Result: [__playlist_id] = [18046]
2006-01-09 16:12:41.7130    Result: [__playlist_obj] = [file:///Music3/Playlists/Untitled.m3u]
2006-01-09 16:12:41.7134 Dispatch: Notifying CODE(0x9f9e44c) of playlist save =~ (no filter)
2006-01-09 16:12:41.7144 Dispatch: Notifying CODE(0x8d981fc) of playlist save =~ [['playlist']]
2006-01-09 16:12:41.7150 Playlist: modifyPlaylistCallback() savecurrsong is 0
2006-01-09 16:12:41.7156 Command: executeCallback()
2006-01-09 16:12:41.7971 parseList (type: m3u): file:///Music3/Playlists/Untitled.m3u
2006-01-09 16:12:41.7975 parsing M3U: file:///Music3/Playlists/Untitled.m3u
2006-01-09 16:12:41.7980   entry from file: #CURTRACK 3
2006-01-09 16:12:41.7983   entry from file: #EXTM3U
2006-01-09 16:12:41.7985   entry from file: #EXTINF:-1,China Grove
2006-01-09 16:12:41.7987   found title: China Grove
2006-01-09 16:12:41.7990   entry from file: /Music2/Music3_Alias/The Doobie Brothers - Best Of The Doobies/01 - China Grove.flac
2006-01-09 16:12:41.7998     entry: file:///Music2/Music3_Alias/The%20Doobie%20Brothers%20-%20Best%20Of%20The%20Doobies/01%20-%20China%20Grove.flac

This continues for the rest of the song files in the Playlist, and after all of the files are parsed:

2006-01-09 16:12:54.4825 parsed 11 items in m3u playlist
2006-01-09 16:13:08.5239 currentPlaylistChangeTime : Mon Jan  9 16:08:49 2006
2006-01-09 16:13:08.5243 currentPlaylistRender     : Mon Jan  9 16:09:03 2006
2006-01-09 16:13:08.5246 currentPlaylistRenderSkin : 
2006-01-09 16:13:08.5248 currentPlaylistRenderStart: 0
2006-01-09 16:13:08.5249 skinOverride: 
2006-01-09 16:13:08.5252 start: 0
2006-01-09 16:13:08.5255 Skipping playlist build - not modified.


Let me know if I should attach to 2739 or continue with the 2804 I submitted. Thanks.
 -------------- Original message ----------------------
From: Slim Devices Bugzilla <bugs@bugs.slimdevices.com>
> https://bugs-archive.lyrion.org/show_bug.cgi?id=2803
> 
> 
> 
> 
> 
> ------- Comment #1 from slim-mail@deane-freeman.com  2006-01-09 11:38 -------
> as mentioned int the forum, this log is meaningless in regard to the problem. 
> These are simply notices of missing graphics, which is due to the in-progress
> work on the Default skin.
> 
> Did you do a search before filing this?  Does bug2739 not match your issue?  If
> not, please explain specific differences.  Perhaps try debugging with d_command
>  and d_parse and attaching to bug2739 unless you really feel your bug is not a
> duplicate.
> 
> 
> 
> 
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.

*** Bug 2804 has been marked as a duplicate of this bug. ***

There is a comment from Fred currently in EditPlaylist::SaveCurrentPlaylist that seems to indicate changes are needed.  Fred, is that ready to be completed so that debug can proceed from there?  

Also, I'm not sure why the playlist save is being done there,before any other processing is done.  However, I wasn't going to look at it until that note is ready to clear up.

I think the comment just went away with my last commit earlier today. This was just waiting on the (for now) definitive way to execute a request, but the basic functionality was there: execute Playlist Save and get the ID back.

BTW, I tried that at some point when doing changes and it was already behaving as described here. I was planning to investigate once the other changes were done (and post a bug).

So "debug can proceed from there".

Part of what is going on here is also expressed in bug 2592.  It appears that the playlist is initially saved as untitled.m3u regardless of what name is typed in. second save should work ok, but is clearly not the right thing to be doing.

Should be fixed as of change 5930.

Will be in the 2006-01-29 nightly

*** Bug 2739 has been marked as a duplicate of this bug. ***

part of this is fixed, but the part mentioned in bug 2739 is still a problem.  When we click 'save', we then load the name playlist using browsedb on teh left side, which lists the stored tracks, not the current ones.  We'd need to update the playlistObj->tracks, but then revert them i the user doesn't click the save button.  Alternatively, we need some sort of object for the current playlist, so that browsedb can return that object and its tracks.  The current playlist is $client->currentsongqueue.  maybe given no id, then browsedb for playlistTracks can return that?

hrm.  it seems that added tracks get in as lightweihttracks.  when sent through the savePlaylistCommand, I can dump the whole playlist,and dump each track during ->setTracks, but the returned playlist is still only the original playlist, made up of the track objects (dropping the lightweighttracks).  I suspect this is really the crux of the problem when saving modified playlists.

with some tips, I might be able to get further.

What's the status on this?

Still an issue in the latest nightlies?

Thanks

status is that I gave up.  I haven't looked at it since my last comment, and don't ever use the server in a way to know offhand if it is still a problem. I'll have to recreate the modifications I used to watch the process.  My feeling is that nothing substantial has changed.

New data on this (r8167):

1) load an existing playlist
2) add a new track to the current playlist
3) click save, under now playing area
3) click save in the left side playlist listing
4) check confirm overwrite then click rename

server crash:
Can't call method "name" on an undefined value at D:\slim\server/Slim/Web/Pages/BrowseDB.pm line 135.

Fixed in change 8217