Bug 1915 - press/holding play with remote to save the current playlist doesn't create an m3u file
: press/holding play with remote to save the current playlist doesn't create an...
Status: CLOSED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: Playlists
: 6.1.1
: All All
: P2 normal (vote)
: ---
Assigned To: Dan Sully
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-08-02 15:27 UTC by Kevin Pearsall
Modified: 2008-09-15 14:35 UTC (History)
1 user (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Pearsall 2005-08-02 15:27:14 UTC
it puts it in the database but it doesn't save a file for it or something.
Comment 1 KDF 2005-08-02 16:10:49 UTC
basically, this is intentional.  savePlaylist writes into the db so that the
server can use it right away, without requiring a rescan.  Are any playlists
being written out from the db?  If an existing playlist is changed, does that
get written out?
Comment 2 Blackketter Dean 2005-08-02 16:22:15 UTC
Right, it should be added to the db, but it should also get written to the file system.  we fixed a similar 
bug with using the web interface to save, but missed this.
Comment 3 KDF 2005-08-02 16:47:46 UTC
the plugin is using the CLI, $client->execute for the playlist save, so perhaps
the fix from the web should use this common code so that any playlist save to
db, will write out to file.
Comment 4 Dan Sully 2005-08-08 23:58:57 UTC
Fixed in subversion change 3907 & change 3908.
Comment 5 Kevin Pearsall 2005-08-11 16:32:03 UTC
this looks good now but check out bug 1961
Comment 6 KDF 2005-08-11 16:56:02 UTC
1961 is not directly related.  Likely more to do with Dan's ongoing
optimisations to use ID's wherever possible. Some changes in the last few days
cleaned this up for the internal playlists, so I expect something similar will
do for the radio plugins.