I think I posted this first one before, but I don't remember a response, so maybe I didn't. Forgive me if I did.

First, IWBNI I could choose how jEmplode orders the tracks by default upon insertion/upload. Right now, it seems to do it by filename, which may or may not be the correct way. IWBNI I could choose to order them by track number or, possibly, something else arbitrarily.

Second, how about automatically stripping ID3 tags on upload to the player? I'm not suggesting that the local files be modified, but the ID3 tags are useless once they've gotten to the player, so how about removing them during transfer? This would need to be a configurable option, as I'm sure some people have other data in their ID3 tags that they might want to get back out of the empeg.

I think you suggested this .. if it wasn't you, someone else did... i think it was just this morning Maybe tms13 did?

1) I need to take a look at this because right now the code is such that it just quicksorts the filenames you uploaded ... Basically the sort has to move to a different level of the code. I don't guess it will be a big deal, but it is a little trickier.

2) I would wait for ID3 rewriting ... Dan's taking a look at fixing up the tffid3 ID3 parser/writer so that writing works properly, which would let you rewrite tags on the way back out.

ms

I probably did. Losing my memory in my old age.

1) No problem. It would be nice though, for a friend of mine, since his tracks don't get ordered in the ``correct'' order on upload using jEmplode currently, and it's a multi-step process to get them to do so.

2) My point in removing ID3 tags is to save space. It's likely that ID3v2 tags will take up 2k or so per track, due to padding (MP3 Tag Studio uses 1500B by default, for example), and that can add up to quite a bit of wasted space.

If we get tag writing support, I imagine it would be relatively trivial to remove tags on the way in ...

Apparently I'm getting the reverse of memory loss, too, as I thought you already had ID3 rewriting support working. Bleargh. Whenever. It's far from urgent. Just thought it would be simple and a possibly handy idea.

Oh, and is there a way to prevent uploading m3u files when uploading directories? If not, that would be a nice addition.

And I'm still getting ``plays'' set to 65535 when uploading via jEmplode. This is almost as annoying as the fact that the number of plays shows up on the Info screen to begin with.

It kind of half worked before i took it back out... So you're only kind of half losing your mind

Always interesting when people want features actually removed I guess I'll file this one in "you can't please all of the people all of the time" and add a config option.

The problem is that I have m3u files in each of my Artist/Album directories, so that if I import a directory, each album contains a duplicate of itself as a child. But if I have a new artist, I can't just import the m3u file, because I then would have to create the playlist for the artist first, which is just a pain.

Perhaps what we really want is for jEmplode to recognise that a file in a M3U list is the same file (by pathname) as one that's being pulled in anyway, and substitute a reference to the first one? I.e. upload the file and put it in the M3U playlist as well as the filesystem-based playlist.

It does reference count, so if you upload the same tune twice before syncing, the second will just be a reference to the original... Is that what you were saying?

It already does that. Or seems to. That doesn't help the fact that I end up with a Playlist tree that looks like:

U2

  War

    War

  Joshua Tree

    Joshua Tree

The Who

  The Who Sell Out

    The Who Sell Out

  Meaty, Beaty, Big and Bouncy

    Meaty, Beaty, Big and Bouncy

Okay. I've got a big bug now.

Basically, jEmplode doesn't work right.

I tried to do a bunch of stuff with jEmplode last night, and it all appeared to work properly. I edited some metainfo (marked tags, track names, years) on some tracks. I deleted some playlists with their tracks. I uploaded some new tracks. After it synced, I didn't go back and check anything, as it all seemed to work right.

I went to play one of the new albums in my car this afternoon, and when it hit the second or third track, the player got wedged. I had to power cycle it. When it came back up, it was no longer wedged, but it refused to play that track. I skipped it (which it wouldn't let me do before the reboot) and it played the next track fine. I skipped back and it still wouldn't play that track. Then I noticed that it was playing them in the wrong order. So I just let it go, to investigate when I got home.

I got home and investigated with the real emplode. Upon initial connect, it complained of corruption. It said that the playlist for ``Earth and Sun and Moon'' didn't match the tracks inside it. ``Earth and Sun and Moon'' was one of the playlists I deleted. When I acknowledged the error, ``ESM'' was a child of the root playlist, whereas before it was a child of my ``Midnight Oil'' playlist, which itself was a child of the root. It only contained 5 tracks, as opposed to the 11 it contained before I deleted it. So I deleted it and the remaining tracks.

The playlist that was out of order and whose second or third track wasn't playing was listed. And it was in the correct order. (Shuffle was definitely not on on the player.) So I deleted it and reuploaded with emplode. Also, I downloaded the track that was causing problems before I deleted it. It won't play in WinAmp. So it apparently got corrupted somewhere.

I decided to also check the other new album I uploaded with jEmplode. The Artist and Album playlists were there, but they didn't contain any tracks. So I deleted the Album playlist and reuploaded it with emplode.

However, the metainfo editing seemed to work fine.

This is all with Blackdown JDK 1.3.1 on a Gentoo PPC Linux 2.4.19 installation.

Oh, and a real minor one:

There's a button apparently for the Wendy Filters at the end of the toolbar, but there's no image in it, so it's tiny. Plus, it doesn't do anything when clicked on.

More...

Under Mac OS X, I clicked on the ``Unattached Items'' list to see if anything was there. There wasn't. I then went to the Advanced Search and typed in ``refs=0''. About 7 things showed up. Shouldn't they have been in the ``Unattached Items'' list?

Also, I initially mistyped ``refs=0'' as ``refs-'', then caught myself. I hit the Delete key, which is in the same place as the Backspace key on a PC keyboard and should do the same thing. It popped up a dialog asking me if I wanted to delete the ``Unattached Items'' list (most likely because that was the last one selected before I clicked over to the search tab. I couldn't find a key that would allow me to backspace over the erroneous ``-''. The other ``del'' key did the same thing. I had to highlight it and overwrite it.

Unattached Items is not used anymore ... I don't know if I'm still recreating it.

Keybindings for OS X in Swing are a little weird ... I'll see if I can remap backspace. You're right that the Delete key was probably saving focus from the most recently selected item ... I'll fix that too.

ms

Yeah .. I uncommented it in the last build but didn't feel like doing a screen grab of the wendy filter button from Emplode and then forgot to do anything with it

and miles to go before i sleep.
and miles to go before i sleep.

In reply to:

---

My point in removing ID3 tags is to save space. It's likely that ID3v2 tags will take up 2k or so per track, due to padding (MP3 Tag Studio uses 1500B by default, for example), and that can add up to quite a bit of wasted space.

---

Wow, that's a lot of padding by default.

Even assuming 2k per tag - which is much higher than most tags I've seen - you'd still have to strip a whole lot of tags to get enough extra space for even a couple of tracks. I don't think it's really worth the extra complication involved, primarily because there are so many different types of information that can be stored in ID3v2 tags - they can't all be stored in the Empeg's database. It'd probably be a better idea to compact the tags on the way in; that way, the information that isn't stored in the Empeg's database won't be lost.

That's not to say that JEmplode will never have the capability to remove tags on the way in; just that I don't think it's going to be as high a priority as rewriting tags on the way out...

I agree ... Rewriting/Updating on the way out is definitely higher priority. I hadn't thought about preserving tags that Emplode doesn't use.

Anyone have opinions on what to do in this case? Basically it's a config option as to whether or not you want tags removed prior to jEmplode updating them on the way out (so if you have extra data, jEmplode won't kill it unless you want it to?)

ms

Okay, I just tested it under Windows, and I still get the same issues. Given that many people seem to be using it without so many issues, there must be something n my end that's got it working funny. I'll play around with it and see what I can find.

I see what you mean now. Not using m3u files, I didn't fully understand what problem you were seeing, as I'd imagined that you'd use m3u only for playlists additional to the one implied by the directory structure. Thanks for the explanation.

I guess it'd be useful to have "ignore m3u files" and "import only m3u files" as alternatives to the current behaviour.

Okay, I updated Hijack (I was running a couple of revs behind), and I tried disabling jEmplode's Hijack support. Neither had any affect on the symptoms I'm seeing. I can't honestly think of anything else to try. Maybe a different version of Java? What are you using? Maybe you should just come over to my house and take a look.

You know, my empeg is very near capacity; I'm having to delete stuff to upload new stuff now. Could that have an effect on any of this?

My dream is this:

On my PC, I would have a bunch of artist/album folders which are just raw Windows folders and MP3 files. There are no M3Us in there.

I would also have a group of M3U playlists in the root directory above those folders. These are not artists/albums, they are my mood playlists. For instance, they are named "(Low Key).M3U", "(LAN Party).M3U", "(Demo).M3U", etc.

My dream would be to have Jemplode be smart enough to recognize that structure on the PC as being the main actual files in the artist/album folders, and the M3Us be entered as my custom playlists which point to those songs, but which are only pointers to the actual artist/album song FIDs. So that way the M3Us create proper mood playlists, but they do not cause the songs to be uploaded to the player twice when I synch.

Then, after that's all set, a single button in Jemplode would synch that structure from the PC to my player, taking into account any changes, edits, deletions, or additions I've made on the PC. Another button in Jemplode could, if desired do the reverse: Download all the songs from the player, fix up all their tags as part of the download process, put them into that folder structure, and create the M3U playlists for me. This would allow me to easily recover from a failure of the PC, or to duplicate all my collection to another PC.

But, alas, that continues to be my dream.

I fired up Emplode last night and noticed that it complained about the length of a couple playlist that were supposed to be deleted ... I forgot to respond to your message though. I'm going to clean up a lot of this stuff this weekend...

ms

I use Jemplode in Linux and Emplode in Win2K. I have found that sometimes, the results I get in Windoze (after having used JEmplode) looks a bit different than what I see in Jemplode. I had to use Emplode to clean up the playlists before I went on to use JEmplode.

In reply to:

---

My dream is this:
...
But, alas, that continues to be my dream.

---

Well, this isn't to far of...

I don't use .m3u for my playlists;
And everything is in a (MySQL) database,
but if I plugin my Empeg at home the dhcp-deamon triggers my updater.
And that injects the changes onto my player (via hijack and ftp).

Only things not working is updating the database,
but that is soon to be there.

I'll still have to rework the database format (6NF was too much ),
but then I'll post the stuff....

ah yes,
generating .m3u from the database is very easy...

Lemme also give you some concrete information.

One of the new albums I uploaded recently was Jason Loewenstein's At Sixes and Sevens, which has 14 tracks. As with most of my albums, it has a playlist at the root for the artist named the same as the artist, and each artist has a subordinate playlist named for and containing individual albums. In this case, it's the only album.

In order to test, I deleted all of that using jEmplode by selecting the artist playlist on the playlists tab and then clicking the trashcan button. It pops up a dialog asking ``Are you sure you want to delete Jason Loewenstein''. I check the ``Remove completely'' checkbox and click yes. Then I sync.

After the sync, I move over to the ``Search'' tab and enter the advanced search ``refs=0''. This shows me 8 things. The first is the ``Jason Loewenstein'' playlist, and it's colored in red. The other seven are tracks 1, 3, 5, 7, 9, 11, and 13 from that album (I hadn't noticed that pattern before, and it may go to explain the following steps). Those 8 items are shown with positions 1-8 (I don't know where that info is determined, so I don't know if it's relevant or not).

So I select all of those items and click the trashcan button again, this time clicking the ``Yes to All'' button and sync again. (This time I happen to get a socket write error exception at EmplodeSyncManager.java:655 when the player has finished rebuilding the database but jEmplode doesn't seem to notice; probably just happenstance and unrelated to the greater problem, but it does have to rebuild the database upon reopening it.) Another ``refs=0'' search leaves me with tracks 1, 5, 9, and 13. These were marked positions 2, 4, 6, and 8 on the previous search.

So I select all of those, trashcan/Yes-to-all them, sync (another exception; it occurs to me that I never saw this until I disabled jEmplode's Hijack support) and another search gives tracks 5 and 13 (former positions 2 and 4).

Do it again (no sync error this time); search reveals track 13 (former position 2).

One more time and they've all gone away.

So it looks like jEmplode only deletes half of what I ask it to each time.

And if I try to upload the same album with the two playlists by bringing up the ``Jason Loewenstein'' directory in Windows Explorer, drag the icon from the Address bar to the Playlists icon in the Playlists tab in jEmplode, everything seems to go more or less okay. (Actually, there seems to be something weird going on with the m3u contained within the ``At Sixes and Sevens'' directory, in that either the files referenced in it or the actual mp3 files are being reported as ``Unknown File Format''. I could understand if they were marked as dupes, but that isn't the case.) Anyway, I click the status dialog's OK button and then sync.

jEmplode shows the new playlist to contain the tracks in the correct order, but the player plays them in the order: 6, 4, 8, 1, 9, 14, 5, 13, 10, 3, 12, 7, 2, 11. If I cycle the player's power, I get them in a different order. Hmmm. Yup. It turns out that the ``Always randomize contents'' checkbox has been turned on for both of those new playlists. Interesting. And simply looking at, not changing anything in, the playlists' properties dialogs changes their display from black to red. But if I do clear that checkbox and resync, then everything seems to be fine on the player.

Taking a step back, if I delete those playlists and try again, I can see that, before I sync to upload the playlists and tracks, the randomize box for those playlists is checked. Maybe that's a feature? Regardless, if I uncheck them before I sync, they remain unchecked after the sync, and they don't turn red when I look at their properties dialogs.

Anyway, that's way more information (or at least way more rambling) than you wanted, I'm sure, but there you go.

> Anyway, that's way more information (or at least way more rambling) than you wanted, I'm sure, but there you go.

No way .. This is great info. I mentioned this in another thread, but basically jEmplode is approaching it's 2 year anniversary, and it is just long overdue for an overhaul... A lot of thse problems are because the code is so hard to follow because it's just gotten new features stuck in every week... I'm going to go back and really spend some time redesigning some internal things (like for instance the concept of the Soup didn't exist when jEmplode was first made). Hopefully I can get a more solid, easier-to-follow codebase going that will make some of these problems go away.

Thanks for the info -- this is really helpful.

ms