Sounds like you need some kind of freeze/thaw mechanism when you know you'll be firing a lot of events. Then if events arrive while the UI is frozen, you don't act on them until it's thawed (and you act only once). Is that the right way to go?

I think you'll need to do some action per-event, but things like sorting the items can wait, right?

You shouldn't need to do much sorting anyway, if you can use something like the Arrays.binarySearch() method when doing inserts and keep things permanently sorted. Then only user-requested sorts need action...

In reply to:

---

You shouldn't need to do much sorting anyway, if you can use something like the Arrays.binarySearch() method when doing inserts and keep things permanently sorted. Then only user-requested sorts need action...

---

That's actually exactly the optimization a was thinking of. Right now there are some problems with what parts of the system know what pieces of information (for instance, if you change a tag that isn't a tag that is being sorted on, the playlist doesn't need to do anything -- things like that) that I need to work out. It's kind of been sitting in m Eclipse task list for a while now and I can't remember why I didn't do it originally (there was something annoying about the problem).

I figured it was something like that. At least it's not a bug, really; It's easy to deal with when you know to expect it.

And I've still been using ctrl-v to paste with no problems there either.

So did the right-click thing turn out to not be hung too? just a huge update?

In reply to:

---

Wow .. performance goes WAY up this way... I took 1000 byte block every 50000 byte interval (roughly 100 samples on a normal MP3) and it dropped from 8 seconds to 300 ms. I'd love to know, mathematically, how this affects the odds of a collision.

---

Well, its been a while since i've gone to a statistics and probabilty class, but here's my best guess:

1/(2^32) is the chance for a collision on a regular crc32 check.
you would multiply this with the probabiliy of a 50000 byte data stream that is the same the 1st 1000 bytes and different the rest.
then each segment lowers the proability of a collision. so if:
x byte block every y byte interval, with z samples, then the probability of a collision is:

[ 1/(2^32) ] * [ (yz)/(y-x)) ]

in other words, for your example, [(50000*100)/(49000)] * [1/(2^32)]

hahah. hope that makes sense to you cuz it surely doesnt to me =)

This may be true of random data but I am not sure it is true of music and perhaps even less so of an mp3 file. I wonder if you change 1 bit in a wave file how many bits change in the resulting mp3 file? In a video mpg file because of the index and difference frames a small change would propagate through many following encoded frames. This should make it more likely that intermitant crcs would catch a change.

However, it still seems likely that a rerip to correct a single skip in a song could easily be missed. Somone should probably run a test.

On the other hand I would be perfectly happy to flag my ID3 files on rerips if we could create a standard for that??

Cheers,
Eric

I take it back .. That's too annoying. Go get

http://www.jempeg.org/debug.zip

unzip jemplode20.jar, unzip debug.zip on top of it (it should replace about 6 or 7 files) then zip jemplode20.jar back up again. Alternatively you can unzip debug.zip and then zip -ru jemplode20.jar to update it and replace the files. Then run jemplode again and send me the console output. If you don't get console output, open jEmplode 2.0.lax and search for "stdout" and you should see a line that defines where stdout redirects to .. set that equal to "console" or a filename and then rerun.

What this does is print out the name of each soup, the total number of tunes in the soup vs. the total number of tunes on your Empeg and if there are any in the db that aren't in the soup, it prints out which ones. For a soup that doesn't have any searches in it, the total number of tunes in the soup should always equal the total number of tunes on your Empeg. If you have a search anywhere in the chain, the search can filter out some, so it's ok to have missing tunes in that case.

You may want to keep a copy of the original jemplode20.jar, since this debugging slows down soups a lot.



I think I did everything right I set stdout to redirect to a file but I don't get anything and I am not sure what you mean by console. What should I be watching.

Thanks

So did the right-click thing turn out to not be hung too? just a huge update?

No, the last time it happened I was in the tree, which isn't very big, and I let it sit for rather longer.

Ok I think it works now (the soup view) I think I was leaving it set on track when making the range view instead or changing it to artist. DUH sorry for the user error.

Thanks

I'm porting the songprint algorithm to Java ... It converts MP3 to a PCM bitstream, so combining songprint with file hashing should allow us to identify all the scenarios we need. I have no idea what the performace of songprint is like, though.

In reply to:

---

However, it still seems likely that a rerip to correct a single skip in a song could easily be missed. Somone should probably run a test.

---

i totally disagree. the skip that is encoded will certainly change the mp3 at some point. it will change the sequence of frames, and will alter the bitstream from that point.

what X every Y interval will do is catch a song that has been mp3trimmed. if there was a corrupt frame that was taken out, 10k from begin/end will not see it.

I'm porting the songprint algorithm to Java

Cool. Aside from the obvious advantage of duplicate handling it seems like that may have some other uses as well. Would automatic id3 tagging of files be a possible future use (that was the original reason for the songprint stuff right)? Or how about automatic detection of damaged files if the songprint does not match what the id3 tags say the file should be.

-Mike

Yep -- I don't know that there's a songprint server anymore (freetantrum.org seems to be gone). But perhaps someone could set one up for Empeg folks to submit their data to. I've ported the songprint algorithm itself, but I need 1) a good FFT library for it and 2) an mp3 decoder (basically, I need a PCM stream from an MP3). For 1), one option is the FFTW Java wrapper (which uses JNI), and for 2) I can use JavaLayer (pure Java). There is obviously a big issue of performance when computing this stuff, and I don't know if Java's going to be up to it.... We'll see, I suppose.

ms

This should be a simple one:

How about a little advanced search cheat sheet somewhere, so I don't always have to refer to the FAQ to remember what I can search on?

Sigh.

Okay. This was my first attempt at uploading with these new PrePre jEmplodes and it didn't go well at all.

The main problem is that it failed to upload everything I told it to, and it also seems to have failed rebuilding the players database, as after the ``sync'', the player took quite a while on that item in the startup phase.

To be complete, I first dragged a folder from Windows Explorer to the main playlists item. Oddly, it only inserted the subdirectories of that folder (that is, I dragged an artist folder, and it put album playlists at the top level and the artist playlist was nowhere to be seen). So I created the artist playlist and cut the (single) album playlist, clicked on the artist playlist and clicked paste (all with the toolbar buttons).

The next folder I dragged into the opened main playlist window and it seemed to insert properly.

I then placed the two new top-level playlists in the correct position. (BTW, is there any faster way to do that than clicking the up/down buttons multiple times, like emplode's Alt-drag?)

Then I synced. I wasn't paying close attention, but everything seemed to go fine until towards the end, when it seemed to stop before it uploaded all of the tracks. It also took a long time to restart the player, as it was rebuilding the database(s). I noticed that some of the tracks were still red, so I tried to sync again, but jEmplode didn't try to upload anything, but it did reboot the player again, taking a long time. Then I exited jEmplode and it told me that I should sync. I told it not to bother, since I was sure it wouldn't do anything.

I started up emplode. None of the new playlists were there. A ``refs=0'' search showed many, but not all, of the tracks I'd intended to upload. I deleted them and followed the same procedure again, except under emplode, and everything worked fine.

This is pre5 under Windows 2000 Pro. I'm not sure what JRE jEmplode is using. I'm double-clicking on the jEmplode.exe executable, but I have both 1.4.0_01 and 1.3.1_04 installed. If I double-click on the jar file, the toolbar buttons are wider than when I run the exe. This bug was under the exe. (Maybe you could put the Java version in the about box?)

The player is running beta13 with Hijack v291.

Edit: This is all via ethernet. Is it possible that the use-hijack option might be screwing things up? ISTR that that's the default, and I don't believe I've touched that option.

I think freetantrum is dead, looking at sourceforge and other supporting sites, last posts were 2001.

But there is Musicbrainz which does appear up and running, and has a Linux distribution.

Worth a look see?

I'll add a "Add Variable" button in the advanced search screen

I want a soup playlist like msaeger e.g.

Artists
......0-E
........Albums
.............Tracks
......F-J
........Albums
..............Tracks
......K-O
.........Albums
..............Tracks
......P-T
.........Albums
..............Tracks
......U-Z
.........Albums
..............Tracks

But what I also want is to exclude an artist from the tree if their album track count is (say) < 4.

I want to do this so that the soup more or less just lists full albums by artist and ignores single track entries from Various Artists albums.

Is this possible?

Currently this is not possible..

Hijack is used for downloading but not uploading .. However, it is possible that Fast Connections are screwing you up.

1) when you dragged a folder, the folder itself wasn't added. this is my first concern because it's weird -- I just tried this on WinXP and it works (i.e. I drag folder "X" with folders in it, and I get an "X" playlist with all that stuff in it). Can you try to duplicate this and tell me if an exception shows up on your console? was there already a playlist at the top level that had a name that was the same as the folder you dragged?

2) Right now I don't have drag-n-drop hooked up from jEmplode to jEmplode... I'll put it on the list.

3) did you get any exceptions on the console when the sync failed? It's weird that it never displayed an error ...

4) As far as the playlists not being there -- The deal is that because you are now allowed to cancel an upload, jEmplode tries to not leave a bunch of zero ref playlists on the player (i.e. it uploaded a playlist but it didn't upload the playlist that actually referenced it). So it puts all the playlists at the end of the sync. The consequence of this is that if sync fails during one of the tunes, none of your playlists get uploaded.

I'm not even sure where to start with this one I'm just going to go and try to do some big uploads and see what happens.

I don't even know where the console would be. Fill me in and I'll try again. Note that that report was about the one and only time I attempted this with pre5 (or any of the prepre releases), so it's possible that it was a freak one-time occurence. Tell me where to find the console and I'll try to reproduce it. But if the console is supposed to be a pop-up window that shows the exception, as I've seen before, I definitely didn't see one of those.

1) I realized I wasn't totally clear about exactly what I did. I think you got it, but let me reiterate. When the top-level playlist wasn't added, I dragged a folder from explorer onto the left panel's root playlist item (BTW, it didn't highlight -- should it? If not, can you add that?). The second time, when it worked correctly, I dragged it into the right panel while the root playlist was open. Unfortunately, there was another difference. The first one was a folder that contained a folder that contained some mp3s. The second was a folder that contained tracks, without an intervening folder. I'll try to narrow down exactly what caused this problem later (when you tell me where to find the console). The only other thing I can think of that is not normal is that I'm dragging these folders from Explorer's location bar (where the URL would be if I were displaying a web page), and not from the main pane. I've never seen that cause problems with any other application before, but it's not 100% normal.

The only other things I can mention are that it wasn't exactly a large upload (two albums worth -- about 110 MB) and that both of the folders contained m3u files. One created a sub-playlist that needed to be deleted before the sync (I made sure not to delete any tracks during that process) and the other one was bogus, referencing files no longer there, which was reported when it was added.

I can't seem to duplicate that failed first-level playlist thing. I suppose it's possible that I just brain-farted on that one and dragged the wrong thing.

Oh, and I just started jEmplode via the command prompt with ``java -jar jemplode20.jar'', so I've got a console now.

Well, I can't seem to duplicate any of those errors now.

But I'll try some more later on tonight. I think it might have to do with that bogus m3u file.

I'm trying to get the download feature working properly in jEmplode v42-pre5 and am having some problem...

* The tags aren't filling in properly...

I have "Write ID3v2 Tags to Downloaded Files" selected, but the genre and track numbers aren't filling out... I'd LOVE to have the track number use the position fields for population as a lot of my tracks don't have a track number properly populated...

* I'm using "{artist} - {source} - {pos:2} - {title}.mp3" as my filename format, but the POS has mixed results. Sometimes I get no POS at all, sometimes I get a single digit...

Any help?

- Jon

Small feature request:

Could we have an option to ignore playlist files on import?

Great stuff Mike..I've just gotten around to upgrading

I think I've found a bug:
I created a Soup on the Title tag, and it only listed about 1/3 of my tracks. When I created a Ranged Soup on the Title tag, all tracks appeared correctly in their respective ranges. (Both done 'JEmplode only')

Thanks for adding Wendy to the mix, can I now request that I can (optionally) recusively apply Wendy flags to playlists (including Soup).

BTW, If I rename a Soup (on empeg) playlist will it stop syncing itself? I really want to rename my Soup lists to always appear at the end, and also make them more...aesthetically pleasing... eg "(By Decade)", "(By Artist)", "(By Genre)", but I don't want them to lost their autosync status.

Something I noticed that could be better (though doesn't do any serious harm):

I created a soup based on play_count, so that I could see which tunes I overplay (and to stress-test your code ). I have set play_count to have java.lang.Integer as its typeClass and sortClass, like so:

jempeg.tag.play_count.sortClass=java.lang.Integer
jempeg.tag.play_count.typeClass=java.lang.Integer

But the soup view isn't sorted in numerical order, as the attached image shows. How difficult would it be to make the soup views sort using the same class as the corresponding column? I'll give you a hint: the answer we want to hear is "not very"

I officially seem unable to reproduce any of those errors I reported before. So nevermind.

you mean ignore .m3u files?

It's supposed to, but then I haven't taken a look at the tag definition code since before the 42 releases, so maybe those system properties just aren't being loaded in properly.