I find it very confusing the way the current system works in terms of symbolic links (aka playlists). I load a bunch fo songs in, create various playlists, which themselves are collections of artists, albums or tunes...but then I go to delete one of my playlists, and the tunes it contained are deleted from the other playlists where they reside as well?!?!?! I'm certain this has to do with something about the way playlists and tunes are actually symbolic links in linux...and the behavior of deleting a dir symbolic link vs. a file symbolic link. Maybe? In any case, my feature request is that there is a way to have your tunes be loaded in, and then if I create ANY other playlists which reference that tune, I want to see that the other playlist is only a reference. Deleting a reference should never delete the base tune...and FOR SURE..it it is going to delete files from my EMPEG it should be requesting for my permission to do so.

It should also be a lot more clear about what the result of copying a playlist is. For example, let's say I have a playlist called "base list" that has within it a bunch of playlists (by artist), and within each of those artist playlists are each of the playlists by album, and within each of those playlists are the actual tunes. Let's assume that I stored them there by dragging a similar folder structure from the windows desktop and dropped them into this "base list" play list.

Now I create a couple other favorites play lists. For one of them, I want a higher level playlist called "all Artists". Then than copy all my other artist playlists from the "base list" by dragging and crtl-dropping them. Now...presumably I have two copies of each artist playlist (with references to all of the albums and tunes underneath). Presumably if I were to delete any of those artist playlists from within the "all artists" playlist, nothing would be effected inside my "base list". But that's not what happens. when I delete from "all artists", it dissappears from "big list" too. ICCKKK!

I think it would be a lot more straightfoward if the tunes went in...and if you create secondary references to tunes or anything....they are always that....just references. Deleting a reference tune OR playlist should NEVER EVER delete the original tune from the unit. I cannot fathom why deleting an artist from one playlist, would also remove the same artist from another playlist...Some kind of screwiness going on there....at least....if its not...and that's the intended feature...then it should be much more clear....I've accidentally erased files a few times now inadvertandly this way...but either not understanding clearly the way the playlist copy is copying playlists...or by some bug in Emplode software....

-steve
sjs@bstage.com

More on the subject...

I think it comes down to this. If I have a structure like this:

---Top list
-----Artist A
-------Album 1
---------tune 1, 2, 3,etc..
-------Album 2
---------tune 1, 2, 3, etc..
-----Artist B
-------Album 1
---------tune 1, 2, 3, etc..
-------Album 2
---------tune 1, 2, 3, etc..

Then if I were to copy all the artist playlists to a new top level playlist...using the drap + crtl-drop method... I then have two top level playlists which look identical..they both contain the same set of artist playlists, which contain a set of albums, etc..

Now if I delete the Album 1 playlist from Artst A on the 2nd top level playlist...it gets dropped from the first top level playlist automatically for some reason. I am guessing this is because each of the Artist playlists are actually just symoblic links to the same directory. So if I delete anything from the contents of one of those artist playlists...I'm also deleting the contents from the other copy of that artist playlist by virtue of the fact that the artlist playlist itself is a symbolic link to a directory.

Is this making any sense?

What I would really like to see as a feature would be

A) the ability to copy a tree structure of playlists within playlists...and have ALL the new copies be completely new copies...not merely symbolic links to the same playlist. I want to delete things in one playlist without effecting the original playlist where it was copied from. BUT, I do want the actual MP3's to be references to the same MP3 file. In other words, when copying playlists, please don't make them be just symbolic links. Make them be copies, which contain symbolic links to the actual MP3 files.

B) if people really DO want to have two playlists linked that way, so that, for example, adding an album to one playlist would also add it to the other playlist that is linked to the same dir...then fine...but make that an option..

C) make it clearly visible through either a tag or icon or something whether a given playlist is linked to the same dir as another playlist..or whether it is in fact its own unique copy.

D) Make it much more obvious as to how to copy playlists and tunes arond to get the desired copy behaviour...

E) I'd still like to see a confirmation dialog when about to delete MP3's from my Empeg.

thanks

-steve

Then if I were to copy all the artist playlists to a new top level playlist...using the drap + crtl-drop method... I then have two top level playlists which look identical..they both contain the same set of artist playlists, which contain a set of albums, etc..

Now if I delete the Album 1 playlist from Artst A on the 2nd top level playlist...it gets dropped from the first top level playlist automatically for some reason. I am guessing this is because each of the Artist playlists are actually just symoblic links to the same directory. So if I delete anything from the contents of one of those artist playlists...I'm also deleting the contents from the other copy of that artist playlist by virtue of the fact that the artlist playlist itself is a symbolic link to a directory.

Is this making any sense?

Close enough . The player does not actually use filesystem links, but behaviour is almost the same as if it did (the difference being that one can't give two instances of the same object different names). See my other posts on the topic (search for FID, I guess).

I second your wishes (actually, I expressed them already in slightly different form).

Hey, guys@empeg, these wishes are quite frequent. Give us some thoughts on them!

Cheers!

Dragi "Bonzi" Raos
Zagreb, Croatia
Q#5196, MkII#80000376, 18GB green