Remove From Playlist Option Always Enabled

[Alan111S]

The code to Remove From Playlist is always enabled when the default for this is no. The older deprecated function 'queue_remove_from_playlist' in post_actions.py used to check the option and also checked if the playlist was owned by the loggedin user. The new function 'remove_tracks_from_playlist' needs to be modified to include these functions.

[oligriffiths]

Yeah I found this out the hard way, a playlist of > 200 songs emptied, WTF.
Luckily I still had a cached version on my iphone so set to airplane mode and manually copied all the songs to a new playlist before it synced.

The check should be here

spotify-ripper/spotify_ripper/ripper.py

Line 366 in fc69919

self.post.remove_tracks_from_playlist()

or in the method being called

[oligriffiths]

On further investigation, supplying --remove-from-playlist outputs No playlist specified to remove this track from. Did you use '-r' without a playlist link? as an error, so not sure that's even the right option.

There appear to be 2 removal methods:

spotify-ripper/spotify_ripper/post_actions.py

Line 263 in fc69919

def queue_remove_from_playlist(self, idx): #depreciated

spotify-ripper/spotify_ripper/post_actions.py

Line 285 in fc69919

def remove_tracks_from_playlist(self):

I don't understand the second one, that just removes all items from the playlist regardless, to me removing a track after it's downloaded (1st one) is the right approach.

[Alan111S]

So the first one was the original and checks the - r flag and playlist ownership but obviously didn't use the WebAPI properly until somebody tried to get that working. The second one just deletes the playlist without checking anything. I just haven't got the time to fix it right now but i understand the code that would need to be changed to fix it. I've modified my local copy to leave the Playlist alone - after all I can do my own deleting - thanks very much...

…

On Thu, 13 Sep 2018 at 01:46, Oli Griffiths ***@***.***> wrote: On further investigation, supplying --remove-from-playlist outputs No playlist specified to remove this track from. Did you use '-r' without a playlist link? as an error, so not sure that's even the right option. There appear to be 2 removal methods: https://github.com/SolidHal/spotify-ripper/blob/fc69919bfa79ce0646d39231ee52698ec5b4f93a/spotify_ripper/post_actions.py#L263 https://github.com/SolidHal/spotify-ripper/blob/fc69919bfa79ce0646d39231ee52698ec5b4f93a/spotify_ripper/post_actions.py#L285 I don't understand the second one, that just removes all items from the playlist regardless, to me removing a track after it's downloaded (1st one) is the right approach. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#29 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AQ5Ykelp8E2D5GQEO4gwOM4biPIM8mjbks5uaSxQgaJpZM4WA2gd> .

-- Regards Alan Prothero Mob: +61 402 371912

[madrover]

damn, I just hit this!
has anyone been able to fix this?

[SolidHal]

Sorry for any problems this caused anyone. For my use case, having it always remove is a feature rather than a bug as I dedicate a playlist to new songs I want it to automatically rip. Obviously I dont want it to rip those songs over and over. I should have made this more clear in the readme.
If someone submits a tested pull request for this I'll happily merge it.
Two possible solutions:
add flag to prevent removal and make it clear in the README that this is the case
add flag FOR removal

[jposemescouilles]

As your reaper is the only one working atm, it would be cool if we could have the option to deactivate the autoremove. It is a feature for sure, but I think the majority of users (myself included) would like to be able to keep their playlist intact.

[tjmurray]

For anyone who is having troubles, I've been using this fork (not made my me): https://github.com/wolfmanx/spotify-ripper/tree/pr-collect

solidly for the last year without any issues. It gets rid of the autoremove issues and works perfectly. Absolutely saved me so thought I'd pass on the word in case it helps anyone else!

[jposemescouilles]

@tjmurray thanks for sharing !!

[kseidenfaden]

I have some other fork installed, and now I'd like to download someone else's public playlist. The version I have will not download playlists - not even my own. And I obviously don't want to delete my friend's playlist ;-)
Do I need to go through the complete installation procedure again, or is it only a matter of substituting a few files to get this to work? (which ones?)
I'm on Ubuntu and I don't know any Python...

[kseidenfaden]

I found a workaround that kind of emulates playlist downloading with --flat-with-index: Select (in Spotify) all songs of a playlist, right-click - Share - Copy URIs (luckily copies them all in one go!), save URIs in a file, turn each of them into a shell command by running them through perl -p playlistify, where 'playlistify' is a file that gets around having to figure out which quotes to escape when issuing the command from gvim ;-) - and which contains: $_ = sprintf("spotify-ripper -f '%03d - {artist} - {track}.{ext}' %s", ++$idx, $_);, save the output, and source it in bash. Voila - 75 songs downloaded overnight :)

I'm still curious why normal playlist downloading with spotify-ripper no longer works, but I guess reading the comments about it again might tell me.

[Pancho111]

Sorry for any problems this caused anyone. For my use case, having it always remove is a feature rather than a bug as I dedicate a playlist to new songs I want it to automatically rip. Obviously I dont want it to rip those songs over and over. I should have made this more clear in the readme.
If someone submits a tested pull request for this I'll happily merge it.
Two possible solutions:
add flag to prevent removal and make it clear in the README that this is the case
add flag FOR removal

Hi Solidal ,
Can you please suggest a way to get the album cover art back ?
Since Feb script is not embeding the art anymore
I will appreciate any help .
thank you a lot