read the faq, searched the board. ok so i can be pretty slow (how about that for a warning?).

1) i put a full album on the player.
2) i decide that i only want one of the songs to remain.
3) i _move_ (cut/paste) the selection to a fav singles folder

4a) i delete the original playlist with delete all versions checked. this results in my moved item getting deleted too.

4b) i delete the original playlist without the delete all versions checked. the single track is retained in the fav singles folder, but the tracks that were deleted did not yield any additional disk space on the player. yes, these were the only locations that these tracks were in a playlist on the player so the music should have been physically deleted [as long as i understand the process correclty].

** could someone please correctly identify my problem?.

*** do i have music floating on my player with no playlist to locate it? how can i locate and delete?

thanks thanks thanks. much appreciated.

m i c h a e l

This is something that's annoyed me slightly, too. I wish the player worked more like a Unix filesystem where it would delete the data if it wasn't referenced anywhere instead of this all-or-nothing deleting.

Anyway, the tracks are still there, not referenced in any playlist.

Go to the advanced search and type in ``refs=0''. This will return all the tracks on the player that are not referenced anywhere. You can then delete them from that screen.

500+ mb cleared. thanks!

Interesting thing you've uncovered there. I wonder if it could be considered a bug?

For reference, the thing that I think is a bug was 4a. 4b is "by design" behavior as described here.

A way around it, in your case, could have been to do it in two stages:

- Move the one track out of that folder, then synch.
- Go back in and delete the larger playlist with the "delete all tracks" checkbox checked. Then synch again.

2.0 is pretty much feature-frozen at this point, but maybe this is something that can be looked at for 3.0?

To confirm, that is a bug:

4a) If he'd moved the track from one playlist to another, then the reference should have been removed from the original playlist, and the track should not have been deleted along with the original playlist, regardless of whether the checkbox was checked.

4b) With the checkbox unchecked, the decision was made to leave the tracks on the player (in the mistaken assumption that soup would be coming soon).

4c) There ought to be a third option, for Unix-like semantics: remove it from this playlist, and if it's the last reference, remove it entirely.

As I recall, we couldn't make the confirmation dialog look nice, so we opted (in the interests of not confusing Rio Central customers -- Marketing told us to assume that they were less clueful than car player customers) to hide the third option.

This is excused (in the Rio Central case) because it does have soup.

And I never noticed, because I don't have my tracks in more than one place, so the behaviour with the checkbox checked is the Unix way, and I never uncheck it.

I added "refs" count in Emplode as a displayed field. So I can always tell if there is more than one reference of that song floating around. Sometimes it can take me a very long time to find that ofher reference though!

I think it was Peter that gave me a tip to help with this. If you delete that track with the box checked then do a search for "changed=" you will get a list of all playlists that were effected by you deleting that song (assuming that is the only thing you did during that sync).