It's trickier than that ... Not-yet-added is only 1/4 of the problem. There's also deleted nodes, updated nodes, and the worst offender modified playlists (adding/deleteing nodes from a playlist). I don't keep intermediate states in the database snapshot. What I mean is, that as you are making a bunch of changes, deleting playlists, adding playlists,adding things to playlists, modifying nodes, etc, I maintaint two things: the current database (after all changes), and a running changeset list of changes. The change list is what you see in the sync queue (that third tab on the left side), and I use this to do background syncs. However, for database rebuilding, I take the current database, write it out into Empeg's format, and send it over to the Empeg. It's not using changesets because to make that work, I'd have to always keep around two copies of the database -- the current one that jEmplode believes is on the Empeg, the current one that you see in the UI in jEmplode, and the set of changes between them. Technically I could probably modify the changeset objects a little maybe be able to derive the old state from the outstanding change sets, but this presents some problems ... For instance, there are some changeset optimizations where if you for instance add a tune to a bunch of playlists, then later delete it, it will be "smart" about what is in the queue. The delete will remove all the previous activity because a delete trumps everything else. That makes sense if you're always flushing the entire queue, but if you want partial queues, coalescing previous entries is undesirable (you lose intermediate state).

In short, it's just a big pain in the ass problem