If a playlist has the same identical name as another playlist but different contents and exists as a child of another playlist (confused yet?), would this confuse the Empeg or would it recognise the two lists as separate entities?

Example:

Playlists by Genre
Rock
Country
Alternative

All Hits Playlists
Rock
Country
Alternative

Please let me know, Thank you

no, they are not stored with file names or as folder names as things are done in Windows. This should work fine.

If you create them properly in Emplode, they are separate entities and all is well.

If you try to copy one of the playlists, for example, if you copy the "alternative" playlist from one place to another, then they will be the same playlist (edits to one will appear on the other).

If you want them to be different, create the playlists individually. If you want them to be the same, copy them.

More details on how duplicates are handled are in the FAQ, here.

Create the playlist "folders" separately, Ok. Then, can I copy some or all of the contents from one to another and still have them be separate entities?

Then, can I copy some or all of the contents from one to another and still have them be separate entities?

Anything you copy is simply a link to the original thing. Actually, the original thing is just a link, too, everything is a link in Emplode.

For instance. If you copy a playlist, it's just a link to the original playlist. So if, for example, your "alternative" playlist has a bunch of sub-playlists such as "Pearl Jam", "Stone Temple Pilots", etc., then if you copy those playlists to your other "alternative" playlist, then any changes you make to the first "Pearl Jam" playlist will be reflected in the other one, too. For example, if you get a new Pearl Jam album and you add it to one of those playlists, then that new album will appear in the other playlist, too.

If you want two completely different "Pearl Jam" playlists with different contents, then don't copy it, create a new one from scratch.

Same thing with songs. Each song index is just a link to the actual song file. So if you have two completely different "Pearl Jam" playlists (each created separately), and you copy "Jeremy" from one of the playlists to the other one, then if you edit the tag data (title, artist, year, etc.) in one of the copies of "Jeremy", then the other one will reflect those changes, too.

Everything in Emplode is just a link to a database entry. So when you make a copy in emplode, you're just making a new link in a new place. Any edits are to the underlying database entry.

If you want something separate, create it using the "new" option instead of copying it.

This sounds more confusing than it actually is. In practice, it's actually very convenient. For example, you could create a "Jazz" playlist with a sub-playlist of "Pat Metheny". You could also have a copy of the "Pat Metheny" playlist in your "Artists MNO" playlist. When you got a new Pat Metheny album, you add it to one and it automatically appears in the other. See?

Eye sea. Gracias

OK, but what about this : ?
I have ripped (almost) every Led Zeppelin CD and put them pn the player
This discussion has promted me to realize that there is a lot of duplicate material. (Duh..)
When it comes time for Remasters and other box sets, can I simply make a new playlist "Remasters Disc 1" copy the appropriate tracks from the other albums and edit their entries? If I edit the album information of the entry in the Remasters Disc 1 list, will it also change the album information of the entry in the origional list ?
- confused ...

You can copy the mp3s to another playlist, yes, so you could have the same songs under the original albums and under other compilations.

But if you change the tags on the mp3s from within emplode, they will be changed every place that song exists, so that ``The Battle of Evermore'' will appear to come from ``Led Zeppelin IV'' whether you're playing ``IV'' or you're playing it within a ``Remastered'' playlist.

This is the case because the all the playlists will point to the same ``file'', and it is that ``file'' that stores the tag info. (I put quotes around ``file'' because it's actually a pair of files.)

Yes, and this behaviour is why I asked for two different "copy" modes:
One that creates an actual duplicate (of the tags file, not necessarily of the mp3 file), and one that acts like the current "copy" that is actually only linking to the original.
Let's assume we have 3 MP3s with associated tag files, on the empeg these are files 10, 11, 20, 21, 30 and 31 (I am not sure right now, but let's assume the tag files are the ones ending in '0'). We also have playlist 101/100 which is the root playlist, containing songs 11/10 and 21/20, playlist 111/110 containing song 31/30 and playlist 120/121 which is empty. If I copy playlist 111/110 into playlist 121/120 using the existing mode, emplode just adds 111/110 to the running order of playlist 121/120. So, if I change any tags in the playlist 111/110 inside playlist 121/120, the changes also show up on the original playlist 111/110 just below the root playlist. The same applies to tags of song 31/30.
Using "deep copy", emplode would create a new playlist inside playlist 121/120 (let's just name it 131/130), which in turn contains a new copy of song 31/30's tag information (which I would name 41/30(sic) for now).
Now, you might ask why I create a new playlist, copying the contents of playlist 111/110 (i.e. copy both files), but only create a new tag file for the MP3s conatined therein. Here is the reason:
There are two things I can change about a playlist: The tag information (stored in the *0 file, following my assumption above) and the running order and contents of the playlist (which is stored in the *1 file). For music files, I can't change the music file itself, only the tag information about it.
All that is needed to allow this is an additional field in the tag files that allows explicit naming of the associated data file. So if a tag file X0 contains a line "datafile=<filename>", not the X1 file is associated with it, but <filename> is. If no such line is in the tag file, the normal X1 file is associated. This way, we do not need to create real duplicates of songs, but can still use different tags for different locations.
A third possible copy mode would be "deep copy of playlists only" which would not create new tag files for existing MP3 files, but would just create new copies of the playlist and it's sub-playlists. thinking about it, I think this mode would be easier to implement, and probably be used more often (very often by me).

mschrag: Any chance that you implement the third mode (deep copy of playlists only) as a possible copying mode in Jemplode (oooops, I mean Jempeg)?
guys@empeg: What about you?

cu,
sven

You cannot have a tag file separate from a content file (i.e. the 0 and 1 files are in pairs). To deep copy a music file would require copying the content as well.

See this for more information.

A function for "deep copy" of playlists may appear in emplode, but as we're in feature-freeze right now, it won't be for v2.0.

Hi Roger.

I remember that document. But what you said is part of what I proposed:
I proposed to break the pairs apart. But even with keeping the pairs, you could still do hard/soft links on the empeg, but that would require a change in the communication protocol between emplode and the player, as the current protocol doesn't seem to allow the creation of links.
If you wanted to supply support for deep copying of tunes, without giving up space benefits of the current solution (and without breaking the pairs), hard links for the data files would probably be the best way to achieve the goal. Soft links would require you to keep track of possible soft links, because you wouldn't want to remove the link target without removing the links as well. Using hard links, the OS takes care of that. My suggestion of breaking the pairs would not need modification of the communication protocol AFAIK, but it would require additional logic in the player (for the handling of the datafile= lines) and in emplode (for keeping track of the datafile= links during deletion of tunes).
All in all, deep copy of playlists would be very nice to have, deep copy of tunes too would also be nice, but would require much more changes to the existing code than it is worth, I guess.
I hope Jemplode is faster in implementing deep playlist copies than you guys are (and I certainly don't want to delay the release of 2.0 player software).

cu,
sven

Unfortunately, hard links would break on two-drive empegs since hard links can't exist between two filesystems.

Unless the new version were to integrate RAID0 support.

deep copy of playlists should be pretty easy ... I can probably put that in.

Mike

Hi.

Unfortunately, hard links would break on two-drive empegs since hard links can't exist between two filesystems.

Actually, it wouldn't. Hard links don't take up any additional space, only additional inodes (which are available even on a full music partition usually). And the tag file can be stored on a different drive than the data file AFAIK (I didn't actually test this, but ISTR having seen a pair of *1 & *0 files spread across both drives in my MkII). And on my (full) first drive, there are still 500 inodes free, on the second drive, I still have plenty of them too, along with approx. 4GB of free space.
Just in case you wonder: I added the second drive only a month ago, and I added and deleted a few audiobooks since.

Also, I don't think RAID would make sense (yeesh, I think I _always_ misspell that word) on an empeg. With RAID and two drives, only striping mode (Raid 0?) or mirroring is possible. Mirroring wouldn't make any sense at all, and with striping, you would loose _all_ your music if one drive fails. With the current solution, you only loose half of it (with two equally sized drives).

cu,
sven

[Edit: corrected spelling of "sense"]
[Edit 2: Completed rant on RAID]

Nah. You really can't have a hard link to a file on another filesystem. They don't allow it because it creates problems with keeping everything in sync. A symlink would work though.

JBOD would be a better idea if you really wanted it to appear as a single drive. Striping would cause both drives to spin up when reading a song which would definately be a bad thing. Still got the problem with one drive dying as you say for normal striping though.

- Trevor

I responded to the wrong thread Sorry about that ... I stuck in deep copy of playlists into jEmplode 33. I could do deep copy of tunes, but it would copy the MP3 itself too, which is probably not what people want.

Mike

Hi.

Nah. You really can't have a hard link to a file on another filesystem. They don't allow it because it creates problems with keeping everything in sync. A symlink would work though.

Is it really this hard to understand, or didn't I choose the right words?
The whole point of my post was that you can _always_ create a hardlink to an existing file, even on an otherwise full disc, as long as there are free inodes. You don't need a link on drive1 to a file on drive0 because you can also create the link on drive0 itself (remember, the player software finds the files it is looking for, no matter if they are on drive0 or drive1).
So if you have a full drive0, which (among others) contains the (fid) files 1100 and 1101 (with *0 being the tag file and *1 being the data/mp3 file), and have drive1 with some space left, and both drives have a few inodes still unoccupied, for a copy of mp3 file, with its tags being free to manipulate without changing the tags of the original, you can

1. create a hard link on drive0 (named 1111)
2. create a copy of file 1100 named 1110 and place that copy on drive1
   

This way, you have not used any additional space, except for the tags. You obviously need to store the tags twice because otherwise, you couldn't change them without changing the original, right?

Was this description clear enough now?

cu,
sven

Whoa. Calm! I didn't quite understand what you were trying to do. I do now though Thanks for the bigger explanation

I didn't know that the player could for example have the *0 file on drive0 and the *1 on drive1 though. I thought you were trying to make a hardlink from drive0 to drive1 which wouldn't work as you know.

I've actually had a few occasions where I wanted to have different tags because a tune was in more than one album but in the end I just duplicated the file. Turned out that a few of them were mixed anyway so the start and end didn't fit elsewhere.

- Trevor

Hard links do not use up inodes.

Here's the mostly complete introduction:

When you see the word "inode", just think of it as being another name for "the file data stored on disk". Here's how it works:

Each file/directory on a filesystem uses one inode -- a data structure on disk which describes the file location/size/etc. Inodes themselves are not useful until they are linked into a directory somewhere, so that applications can access them. The process of linking an inode into a directory, and thereby giving it a "name", is known as hard-linking.

All files are "hard-linked" to at least one directory when created. Additional "hard links" can also be created, which merely cause the same inode ("file") to appear in more than one directory. No new inodes are used for this.

But since directory entries reference "inodes" within the same filesystem, and only within the same filesystem, the inodes MUST be on the same filesystem as the directories which link to them.

So a file ("inode") on the /drive0 filesystem can only appear in directories on the /drive0 filesystem.

To complete the story, there are also "symbolic links". A symbolic link is not really a link, but rather a way of storing an arbitrary string in a directory entry. This creates a directory entry which does NOT link to any inode ("file"), but rather just contains a "target" string, which is re-interpreted at access time as a new path to look up.

When accessing the target of a symbolic link, the kernel just grabs the string from the directory entry, and then does another lookup search using the new string for the path instead of the original string that referenced the symbolic link entry.

Since symbolic links are just strings, they can contain anything, including "invalid" strings that don't contain a valid pathname (in other words, they don't have to reference something that actually exists). And because they are just strings, they are not restricted in any way as to where the so-called "target" file resides -- so they can be used to cross filesystem boundaries.

Cheers

And smu is very correct, in that neither Hijack nor the player care which drive the *0 and *1 files appear on. Both pieces of software simply treat /drive0/fids and /drive1/fids as a single combined directory when looking for fids, even though they are actually two separate directories which happen to be on separate filesystems. The code for this looks like:

if (fidfile not found on /drive0/fids) then

    look for it on /drive1/fids

Yeah, but you don't need the hard link to span the disks. You put the hard link on the same disk as the original *0 file, and the *1 file can go on either disk. Neither the player nor emplode care which disk the files are on, and the *1 and *0 file don't have to be on the same disk.

I wasn't aware that the *1 and the *0 files could be split up like that. (And to expand on Mark's correction about hard links and inodes, it actually is possible that hard links can take up disk space, indirectly, if the new directory entry forces the size of the directory to be larger. But that's picking nits.)

And I was joking about the RAID, BTW.

Yup. I've found this out now
Smu, mlord and you've have all explained it to me. Sorry if I came over as being argumentative Not intentional I promise!

- Trevor