Now I'm quite happy to accept that I may be doing something wrong here, but why when I delete anything and then sync with the new emplode does what I've deleted move into Unattached Items?

This is all stuff which is not copied into another playlist - it was uploaded into the playlist I just deleted it from.

To make things even more annoying, if I delete a playlist which contains a playlist which contains tracks, the playlist moves to Unattached Items. If I delete the playlist from Unattached Items, the tracks which were in it now appear there.

This means that it takes several delete, sync operations to delete the files I want to get rid of - hardly friendly.

I am now pretty sure that the free space reported is too low for the files which appear in the database.

Any ideas?

Nick.
(copied to [email protected])

--
18Gb blue (now AR red) - s/n 080000299 (original queue position 8724)

but why when I delete anything and then sync with the new emplode does what I've deleted move into Unattached Items?

I just tried this and couldn't reproduce your reported behavior. Hmm....

if I delete a playlist which contains a playlist which contains tracks, the playlist moves to Unattached Items. If I delete the playlist from Unattached Items, the tracks which were in it now appear there.

Hmm, I don't know if this is new behavior or if was already like that in 1.01. Is it possible that this is the first time you did things that way?

Just as a refresher, all items in emplode (whether they are playlists or songs) are just links to files on the hard disk. Only when the last link to a given file is deleted, does the file itself get deleted.

When you have links nested within links, I don't know how emplode is supposed to behave when you delete a parent link. I also don't know what behavior I'd prefer in that situation: Do I want it to recursively delete the tree, or do I want to save the sub-links just in case? I know that if the tree contained a link to a playlist that was stored elsewhere, I wouldn't want it to be deleted.

There is also the possibility that you're seeing the results of some kind of a malfunction related to your first complaint.

Mike, did that behavior change in this release?

___________
Tony Fabris

I'm fairly positive this bug has come up before, but i can't find it anywhere on the board. I've had this exact problem for quite some time and i haven't upgraded to 1.02 yet. In an organization scheme that's artist->album->songs... if i delete the artist in emplode and sync, the album then appears in the unattached items, then when i delete the album in the un. items folder and sync, the songs that were in that playlist appear.

Can anyone find the thread on this or am i dreamin' it up?

UPDATE -> here it is... i found it (one of em at least)


|| loren.cox
|| 080000446

Edited by loren on 09/01/01 01:35 AM.

if I delete a playlist which contains a playlist which contains tracks, the playlist moves to Unattached Items. If I delete the playlist from Unattached Items, the tracks which were in it now appear there.

This is how mine has always worked, for every version of software from 1.0 to 1.02RC. I always assumed that was what it was supposed to do.

The workaround is to just pretend that that Unattached Items listing on your emplode screen is not really in bold print, and then deal with it the next time you do a synch. :-)

tanstaafl.

"There Ain't No Such Thing As A Free Lunch"

Interesting, I have never seen anything in unattached items unless I specifically copied it there and then did a sync. I was thinking it was kind of useless., or maybe just a safety net for things that got uploaded but somehow did not make it into the playlist.

Steve Bates

I was thinking it was kind of useless., or maybe just a safety net for things that got uploaded but somehow did not make it into the playlist.

That is correct, that is one of the purposes of the Unattached Items folder. If you understand how the playlists work on the Empeg hard disk, you'll see that what you're describing is exactly the same as the behavior reported at the beginning of the thread.

Here's how it works:

When you add a song with emplode, the first thing it does is upload the song. Then it uploads the changes to the playlists. Then it rebuilds the database based on those changes.

Now, think for a moment about what a playlist is. It's simply a collection of links to other playlists, or links to songs.

So, if you upload the song file, but something goes wrong on those later steps, then the song itself is orphaned on the hard disk- there are no links which point to it. Hence "Unattached".

Now, if you think about it, this is exactly the same thing that happens when you delete a playlist halfway down the tree structure. You have removed a parent link to a branch, but the branch itself still remains (that collection of links).

If nothing else links to that branch, then it is also "Unattached". See? It's the same thing.

I think I know why the empeg doesn't automatically prune the playlists beneath the playlist you're deleting. It's because there's a possibility that it might be linked elsewhere, and there's (currently) no code to go checking to see if it's linked elsewhere. There's also the possibility that you might have done it accidentally, thinking that it was linked elsewhere, but in fact you just deleted the last link.

Personally, I like this behavior. It makes sure that I'm very serious about deleting a song before it goes ahead and does it. However, from a "Joe Consumer" point of view, it seems that it should behave the other way.

There's one other use for the "Unattached items" folder- for storing songs that you don't want in your rotation, but that you need to keep on the empeg for whatever reason. Shuffling the whole unit won't play the Unattached Items. For instance, if there is an album that you need to keep only for when your great grandma comes to visit, you can stick it in Unattached Items most of the time, and just do a quick synch to put it back into rotation as she's pulling up the driveway.

I use it in a similar way, now that I've got a Mark2 and Displayserver is available. I use the Unattached Items folder to taxi files between home and work. I create a big .zip of everything I want to taxi, rename it to ".MP3", send it to the Unattached Items folder, then retrieve it with Displayserver at the other location. Then I rename it back to ".ZIP" and unzip it.

(Hey, Dionysus, how about putting that one in the tips 'n tricks FAQ?)

___________
Tony Fabris

When you add a song with emplode, the first thing it does is upload the song. Then it uploads the changes to the playlists. Then it rebuilds the database based on those changes.

No. It uploads the playlists first. This was changed back in the BETAn days because people got so annoyed about everything ending up in unattached items if a sync failed.

I think I know why the empeg doesn't automatically prune the playlists beneath the playlist you're deleting. It's because there's a possibility that it might be linked elsewhere, and there's (currently) no code to go checking to see if it's linked elsewhere. There's also the possibility that you might have done it accidentally, thinking that it was linked elsewhere, but in fact you just deleted the last link.

It does prune them. Each item has a reference count and once that hits zero the file gets deleted. It seems that this is going wrong somewhere. Exactly how are you deleting the files? Pressing the delete key? Right clicking and selecting delete? I can't reproduce the problem here.




--
Mike Crowe
I may not be speaking on behalf of empeg above :-)

Now I'm quite happy to accept that I may be doing something wrong here, but why when I delete anything and then sync with the new emplode does what I've deleted move into Unattached Items?

It shouldn't. I've just tested it here and it didn't for me. How are you performing the deletion?



--
Mike Crowe
I may not be speaking on behalf of empeg above :-)

Mike, did that behavior change in this release?

Not that I know of. Some bugs that caused items not to be marked as modified were fixed which _may_ affect it were fixed but I can't really see how anything that changed could cause a change in this behaviour.

I'm baffled as to how everyone is seeing deleted items appear in unattached items after successful synchronisations. Of course, a failed synchronisation can cause stuff to appear in unattached items but a successful one should not.

Please can anyone who can reproduce this on demand describe exactly how they do it?


--
Mike Crowe
I may not be speaking on behalf of empeg above :-)

Here's a thought:

In some private conversations I had with Doug Burnside, he said he was poking through his exported CSV file, and noted some reference counts that looked wrong. For instance, a reference count of "2" for a song that he was sure was only referenced once.

Is it possible that people who had previous database errors might have a few incorrect reference counts, and this is the root of the problem?

___________
Tony Fabris

Darn, I wish I could reproduce it on demand, but I can't now.

I just got done deleting a bunch of stuff from my Mark1, and a large percentage of those songs ended up in the "Unattached Items" folder unexpectedly.

Here's the steps I did last night:

- I wanted to pull a bunch of stuff off the Mark1 that my wife doesn't like. Because the Mark1 will be now almost exclusively played in her presence (we haven't yet settled on whether or not it goes in her car, but for now it is the household Empeg and gets shuffled from room to room).

- Among the things I was deleting was all of the Nine Inch Nails.

- I had two playlist sets: An Artist/Album/Songs set for Nine Inch Nails. And also there was a "Lan Party" playlist which contained a bunch of NIN, Prodigy, Crystal Method, etc.

- I deleted the NIN playlists. I think I did it by selecting the songs, pressing Delete, selecting the album playlists, pressing delete, then selecting the NIN playlist, and pressing delete. But it's possible that I just selected the album playlists and pressed delete instead of getting the individual songs.

- I then went to the Lan Party playlist and selected all of the songs and pressed Delete. Then I selected the Lan Party playlist itself and pressed Delete.

- I also deleted a bunch of other stuff on the empeg as part of this.

- Then I synched. All of the NIN songs were in "Unattached Items" afterwards. I had done a whole bunch of deletes, removing entire sets of artists in the same way I did the NIN stuff, but only the NIN stuff was in the Unattached Items folder.

Does that make any sense?

___________
Tony Fabris

Is it possible that people who had previous database errors might have a few incorrect reference counts, and this is the root of the problem?

Reference counts aren't persistent - they only exist for the time between downloading and synchronising so there's no scope for them to really go stale apart from within emplode itself.

What I'm wondering is if there's a particular way of deleting that isn't dropping the reference count and is therefore not causing the item to be deleted, just unreferenced since they _are_ removed from the parent playlist.


--
Mike Crowe
I may not be speaking on behalf of empeg above :-)

I've got emplode open now and it just happened to me. There is still a playlist left in "unattached items". The last time I had the problem that was also the case. After I deleted the playlist and synchronize, the songs were still present.
If someone wants to see it you can click here for screenshots.
The sequence was :
1) delete 2 playlist with 1 playlist in it with songs in it
2) delete 1 playlist with songs in it
3) synchronize
4) 1 playlist with songs in it appears in "unattached items" together with some loose songs
5) delete that playlist and songs
6) synchronize
7) loose songs from the previous playlist reappear in "unattached items"
8) delete them
9) synchronize
All done
BTW my "unattached items" is renamed to "empty" and i'm still using 1.01

Frank van Gestel

Edited by fvgestel on 09/01/01 09:40 PM.

In reply to:

---

How are you performing the deletion?

---

Highlighting the playlist and hitting the key.

Nick.

--
18Gb blue (now AR red) - s/n 080000299 (original queue position 8724)