In reply to:

---

can the transfer bar share the bottom half of the playlists tab? the details can stay where they are.

---

I agree that it's weird there's no indication at all .. RMML actually shows the currently syncing file name in the status bar ... I'll play around with this.

In reply to:

---

whenever i sync with emplode, when i go back to jemplode, it gives me a "Playlists referred to a missing tune or playlist with ID 272".

---

Fixed

In reply to:

---

windows shortcuts (.lnk files) arent implemented yet =(.

---

writing this now ... .lnk format is officially the most overengineered file format i've ever seen

In reply to:

---

tags changed on the hdd doesnt change the tags on the player if it recognizes as a dupe.

---

yeah .. this is a known limitation (of emplode and RMM too, I believe). this is, in general, a hard problem because you can change tags independently in each location, so there's no way to know (automatically) which direction they should sync. I suppose this could be a configuration option though, if you maintain your repositroy in a single location.

In reply to:

---

some of my files are not syncing thru. it gives a UTF16-LE error for the reason.

---

Are these all WMA files that do this? Is there a particular file that always fails? If so, can you send me a link to download that so I can try it here?

In reply to:

---

a while back, we had a discussion whether "remove completely" will apply to fids with more than one ref. right now it deletes it completely and changes all playlists that contains it. can we get a toggle where it wont do that? especially useful when i have a favorites playlist that contain singles and refernces to albums i want to clear.

---

You can get to "remove completely" a couple different ways -- what UI method are you referring to? I think I'm misunderstanding you request, though -- if you don't want remove completely to delete tunes in multiple places, wouldn't you just not say "remove completely" (and just do a regular remove)?

In reply to:

---

so where's the autosync to hdd feature of the karma?

---

the only autosyncing that RMML does is in the sense that when you start making changes, it will automatically begin to sync in the background ... It doesn't support any of the sync profiles or anything -- is that what you're asking about?

In reply to:

---

1) jemplode allows you to exit while a sync is happening. really bad, since the bar is invisible to an unknowing user. did that accidentally.

---

Hmm .. whoops .. that's supposed to ask you if you are sure (if there are pending transfers).

In reply to:

---

you try to add some files (about 60 albums), not sync and revert changes

---

I'll check this out ...

In reply to:

---

suggest to default starting the right pane in the "Playlists" folder.

---

shouldn't be a big deal -- i'll try it out ...

In reply to:

---

upload the 60 albums again, then before syncing, deleted everything with "remove completely"....

---

You get the Evil Tester Award ... I'll check this out also.

In reply to:

---

using the cancel button in the sync doesnt work. it keeps on going. you need to highlight all the items and rightclick, then cancel for it to actually happen.

---

Hmm .. OK.

In reply to:

---

WMA files arent supported.

---

It's supposed to be -- Though I don't actually HAVE any WMA's, so it doesn't get tested. You're not trying to upload DRM'd WMA's, right? That will definitely fail. What errors are you getting? Is this the UTF16-LE one?

attached is what i see. i've pm'd you a url to download the songs in question. be patient, i only have a 12Kb upstream.

You can get to "remove completely" a couple different ways -- what UI method are you referring to? I think I'm misunderstanding you request, though -- if you don't want remove completely to delete tunes in multiple places, wouldn't you just not say "remove completely" (and just do a regular remove)?

here's my dilema. say i have a lot of mixed cds with various artists a lot of the same tracks appear in these albums. to save room, i start using only one copy of the song on the empeg, and referring to it in the corresponding playlists. (on my windows box, i actually have all the songs in one big singles directory, and individual folders containing .lnk or .pls files.) so say "nsync-bye bye bye" (note, i dont have this, nop wisecracks pls) appears on 5 of the mixed albums. so with my current scheme and deduping enabled, the track should have a ref count of 5 on the empeg. one day, i want to delete one of the 5 albums that contain the track. i hit delete on the playlist, and it when it confirms, i check the "remove completely" tab, and hit yes to all. what happens is that the other 4 remaining albums will be nsync-less. what i want to happen is that jemplode checks if the refs is 0 before removing completely, to not break up my scheme. its similar to hard links in linux. it only really deletes after the last reference is gone.

the only autosyncing that RMML does is in the sense that when you start making changes, it will automatically begin to sync in the background ... It doesn't support any of the sync profiles or anything -- is that what you're asking about?

yeah, i was hoping that there was more to it, like being able to mirror a directory structure, with additions and deletions made on the pc reflected on the empeg. got the hashes now. pretty easy to go:
if empeg->track->hash doesnt appear on the pc anymore, then delete on empeg.
if pc->track->hash doesnt appear on empeg, then transfer to corresponding playlist.

question. directed also to mlord.

is hijack v345 still necessary since this new jemplode is out? will it hurt to have it on? i'm sticking with v344 for the reason that i'm afraid its gonna break something.

another anomoly. not sure if its on purpose. when you sort your playlist by artist, it discounts "The". see attached picture

Necessary? No. Very very desireable? Yes. Especially if you use fid subdirs to speed up your player and want to guarantee that they don't get messed up.

Cheers

Okay, here's my pet feature request:

I want a "fast sync" option, where JEmplode does the database rebuild locally on the user's PC, based on the previous database + any changes that were made. It then just FTPs the new database to the player, so that the player doesn't have to take 2-10 minutes to rebuild it from scratch.

An option, of course.

Cheers

In reply to:

---

and hit yes to all. what happens is that the other 4 remaining albums will be nsync-less. what i want to happen is that jemplode checks if the refs is 0 before removing completely, to not break up my scheme.

---

So this sounds like just regular "remove" to me ... The whole point of remove completely is to remove all references (so by definition, refcount > 0). What is the problem in this circumstance with not checking remove completely/

I've considered writing this ... Does anyone know exactly what steps are required to do this properly? I know what files I download to retrieve the database -- it is as simple as just replacing those couple files?

jEmplode should work with both -- it attempts the new way first, then falls back to the old way (well, not the way old way, but the middle old way )

ms

This is intentional ... The, A, and An get switched to the back (The Birds sorts as "Birds, The"). This was generally the most popular sort choice.

ms

And restarting the player after. At least I recall manually tweaking a database with the 2.x software that way.

The problem, though, is a database format change then becomes your problem.

So this sounds like just regular "remove" to me ... The whole point of remove completely is to remove all references (so by definition, refcount > 0). What is the problem in this circumstance with not checking remove completely/

well yeah. all i have to do is delete without removing completely, and then search for refs=0 and delete whats not in a playlist.

i just wanted to to take out these steps. just a pet peeve that i'm sure no one else will reflect. just ignore me. =)

I see now ... What you want is not necessarily to modify remove completely, but rather you want to bring back the old Empeg rules where when the refcount goes to 0, the tune gets removed. So are all your tunes in at least one playlist? If so, I could maybe bring back a configuration option that would make it so when you do a delete it will check refcount and actually delete the refs = 0 ones ...

Hi Mike, are you going to release the source for 46 or wait until another version to do so? I still would like to write my Palantir PDB Creator code so it would work with JEmplode.

I believe JEmplode *already* is dependent on database format -- it pulls down the current database files from the player and has to know how to parse them already. So no biggie going the other way.

And yes, it's as simple as that -- the database, playlist, and tags files.

Cheers

Mark, does this mean that there is no need for the players 200mhz processor to do the database rebuilds? A PC could just do it and send the results? As long as Jemplode could recover and "re-send" if there was ever a power loss to the player or a connection drop, that'd be really cool.

So cutting the database rebuild time in half wasn't enough for you huh?

The 200Mhz SA CPU is not the limitation here -- it sits practically idle while the rebuild goes on -- waiting for disk I/O nearly 100% of the time.

You see, the player software is very conservative about how it rebuilds the database, because it doesn't know what has or may have changed since the previous database was built. So, it discards everything (or is told to do so by (J)Emplode), and rebuilds from scratch, re-reading every single *1 tag file from the fids directories. On a 10000 song player, that means it has to do at least 10000 disk seeks and 10000 disk reads, plus all of the directory lookups and metadata reads required to locate the data blocks for those 10000 tag files.

Whereas JEmplode, knows what changes it is making, and can simply apply them as a delta to the previous database file from the player, without reprocessing 10000 tag files in the process. This will work fine nearly 100% of the time. And for a really screwed up player, we still have the option of letting the player regenerate it all from scratch if need be.

Cheers

Ah... . very interesting. Any idea why this isn't part of emplode already? Is it because it works "nearly 100%" of the time and not "each and everytime"?

Either way, very cool idea!

Yeah -- I can .. I was thinking I'd release it for 47 after I fix some of these bugs, but I can put 46 up if you'd like. Incidentally, you can do plugins now for jEmplode, so just by implementing a simple interface and making a special file in your plugin jar file, it will be detected and added to the Plugins menu. I can put a sample plugin file up for you.

I would guess that Emplode lacks it because, when Emplode was first written, a BIG empeg player had like, 4GB (!!!!!) of drive space, and a database rebuild was probably only a few seconds even for a full player. So no biggie.

Things change..

And even if I have to rebuild the entire thing (without deltas), I have them all in memory, so it's pretty painless ...

ms

Mike, that would be awesome. I'll begin writing the plugin for Palantir as soon as you get it up somewhere for me to download!

Are you talking about an auto install for Palantir or an auto export of the database? Either way: Cool!

Auto generation of the .pdb file you need to load on your Palm each time you add or remove songs. Depends on what options are available to me, but I could make it auto-generate when syncing, and then launch the .pdb file to make it install on the Palm. Otherwise, it would be available as a menu option (Plugins -> Generate Palantir PDB).

An automated install of Empire is waiting until we get a "site exec" command in Hijack.

Any idea why this isn't part of emplode already?

1) What Mark said.
2) emplode hasn't seen any development effort since 2.0-final was released. When I left, it was planned to include v3.0 car player support in the next version of Rio Music Manager, since it's the most flexible platform, going forward, but that'll take some time -- not least because there's a lot to do -- I'm guessing.

For the simple plugin docs:
http://www.inzyme.com/rio/plugin.html

In your case, I would recommend making your plugin action extend org.jempeg.music.manager.action.ExportAction and just call the superclass passing in your custom exporter impl.

ms

Hello Mike,

I have a short question. Why I am not able to upgrade to the latest Hjjack version anymore. I did compare the settings with jEmplode 45. I have the same setting, but 46 tells me everytime, that I have to have the Hijack 242 or higher installed, connected over ethernet and "Use Hijack when possible. I fullfil all the requirements and I can download with jemplode 45 the latest Hijack with the same settings on a other computer.

Thanks a lot

I'll take a look at this ... I maybe hosed it up.