69. Initiate off-color jokes mode.

Posted by: mschrag

69. Initiate off-color jokes mode. - 25/09/2004 04:22

Fixed Set Playlist Order (doesn't work for Sorted playlists now too)

Fixed removing Playlist Sort order in Playlist Properties

Added Edit=>Resort that will recursively resorts the selected playlists (in the event that something gets wacked out)

Unified Set Playlist Order, runtime playlist sorting, and playlist.resort()

Added "Sort Playlists Above Tunes" Option
Note: This flag is not stored on the Empeg itself, only in jEmplode. So life will be easier for you if you only change this value when your Empeg
database is visible in jEmplode. If you have this option enabled, disconnect from your Empeg, turn off the option, then reconnect to your Empeg,
it can get confused (that is, your Empeg will be sorted with playlists above tunes but jEmplode will be trying to runtime sort playlists and
tunes together since that is the new value). In the event that you decide to change this setting when you don't have an open database, when you
reconnect, you can select the root playlist and choose the Edit=>Resort option to recursively make your Empeg playlists consistent with the new
setting value. If you have your Empeg database open when you change this option, it will automatically resort all your playlists for you. This
same scenario can happen if you use jEmplode to communicate with multiple devices (Karma, or multiple Empegs). This value is jEmplode-global, so
it will affect apply to all of your devices. Later versions may support per-playlist versions of this setting, but it was too annoying to do
for this first rev.
Posted by: StigOE

Re: 69. Initiate off-color jokes mode. - 25/09/2004 12:53

I downloaded version 69 and tried to connect to my Karma using USB (don't have the dock with me), but receive the following error:

You do not have jEmplode.dll installed somewhere in your PATH. USB support will not work until you do.

Where can I fing this file? And since I haven't run jEmplode before (Buh, shame on me... ), is there anything particular I have to do, except perhaps make a plugin-directory for the Palantir-plugin (which I have already done...)?

Stig
Posted by: mschrag

Re: 69. Initiate off-color jokes mode. - 25/09/2004 13:22

Even if you had jEmplode.dll, you wouldn't be able to communicate with the Karma over USB ... It's a completely different protocol (much lower level than the Empeg, it's actually controlling the drive from what I understand) that is not open source. Sorry, it's pretty much Ethernet or nothing for Karma+jEmplode.

As far as Palantir, I believe you just need the plugins folder + put the jar in there, but that's not my bag, so I wouldn't take my word for it
Posted by: StigOE

Re: 69. Initiate off-color jokes mode. - 25/09/2004 14:45

Bummer... Guess I have to wait till I get home with testing jEmplode. Oh, well... Thanks, anyway.

Stig
Posted by: The Central Guy

Re: 69. Initiate off-color jokes mode. - 25/09/2004 16:27

I'm using 69 and have a question about sorting. I'm loading my music collection from my Central to my new Empeg. I've got all the music copied over, 10K songs, but I need some help with playlist sorting...I'm trying to build a list like this:

Beatles <= contains songs from all 3 CDs below
...Let It Be <= Contains only Let It Be Songs
...Abbey Road <= Contains only Abbey Road Songs
...Sgt. Pepper <= Contains only Pepper songs

I've been able to sort the individual CD playlists by Track Number and then use "Set Playlist Order" to get the positions to match the track numbers. That's great, if I choose one of those playlists then it plays the songs in CD track order.

But if I choose the Beatles playlist, the best I can get is songs sorted by CD but then played alphabetically within each CD. So the Let It Be songs play alpha, followed by the Abbey Road songs in alpha order, then followed by the Sgt Pepper songs in alpha order.

I've tried to sort the songs in the Beatles playlist by clicking on Track and then clicking on Album to get the songs shown in proper track order by CD. But when I choose Set Playlist Order, the track numbers jumble. The songs from each CD stay together within the playlist, but I can't seem to get the songs sorted in track order by CD.

Can someone please offer some tips on sorting?

Second, is my playlist scenario above an efficient way of listing the songs? I thought of having 5 higher level playlists called Artists A-E, etc. and then listing the artists and albums underneath, but that's a little bit more setup work than the way I have them listed above...

Thanks for any suggestions....

Randy
Posted by: mschrag

Re: 69. Initiate off-color jokes mode. - 25/09/2004 16:58

Create soup playlist, select "On Device" (unless you only want this as organization inside of jEmplode):

Add Tag Layer => Artist, Sort by Title
Add Tag Layer => Album, Sort by Title (seems like some people like to do a Sort by Year here for the album layer)
Add Sort Tracks Layer => Sort by Track #

It will then manage the playlists for you.
Posted by: image

Re: 69. Initiate off-color jokes mode. - 25/09/2004 17:11

BUG REPORT: jemplode doesn't like being told to cancel the sync in the middle of it with fast rebuild on. what happens is that it tries to rebuild then restart, but it always needs another rebuild after.
Posted by: mschrag

Re: 69. Initiate off-color jokes mode. - 25/09/2004 18:37

Yeah I think if you cancel I will have to fall back to a normal build since what jEmplode has for your database and what is on the Empeg will not be in sync in that case, so I can't fast rebuild it.
Posted by: image

Re: 69. Initiate off-color jokes mode. - 26/09/2004 04:17

yeah, that seems like the logical thing to do. but, can't you just change the fast rebuild code to not take account of the not yet added parts? i mean, you color code them on the interface, certainly there's a flag of some sort.
Posted by: mschrag

Re: 69. Initiate off-color jokes mode. - 26/09/2004 12:39

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
Posted by: slothy

Re: 69. Initiate off-color jokes mode. - 28/09/2004 20:10

I'm a programmer, and I hate it when people do this, but be prepared for a report of many bugs all at once:

With jemplode 69, I tried adding a new file and got this:

Unable to write [FIDLocalFile: title = file.mp3; fid = 108480] back to the device.

Two things - my last sync was with the regular emplode, which I haven't used in years. I tried it because after adding a Tribe Called Quest album using jemplode, the player had a bad db build and when I tried to connect using jemplode it just hung on Updating Interface and the memory usage was spinning wildly out of control.

So I tried using regular emplode, and it added the new album beautifully. Since then though, when I connect using v69 of jemplode, instead of Playlists, the tree shows "A Tribe Called Quest" on the left pane. Weird stuff.

Also, I'm pretty low on space on the player - jemplode estimates 294 megs free. If that is off, maybe it's running out of space, but this is the first file it's trying to add, so it seems unlikely that jemplode's estimate would be 294 megs off.

Thanks again for jemplode, it's a great app and it has been serving me well for years now!

Jon
Posted by: mschrag

Re: 69. Initiate off-color jokes mode. - 28/09/2004 22:50

Quote:
Unable to write [FIDLocalFile: title = file.mp3; fid = 108480] back to the device.

So you can consistently reproduce this problem? If so, can you run jemplode from the console and send me the stack trace that prints out?

Quote:
it just hung on Updating Interface and the memory usage was spinning wildly out of control.

.. and this was with jEmplode 69 also? If you reproduce this and get it to happen consistently, let me know -- i'm like to get a thread dump.

Quote:
instead of Playlists, the tree shows "A Tribe Called Quest" on the left pane. Weird stuff.

So you're saying the root playlist is not there and there's an album name instead? So you can't see anything in the tree at all? What in the world is THAT?
Posted by: slothy

Re: 69. Initiate off-color jokes mode. - 28/09/2004 23:17

I just tried running jemplode and adding the album again and it's working this time. I'll try adding some more and see if I can reproduce it.

re: spiraling out of control on the Updating Interface step: This happened with v68, not 69. I realized after emplode fixed it that I probably should have put my empeg out on the net and emailed you to connect to it yourself. If I ever reproduce that you better believe I'll do that next time.

Quote:
So you're saying the root playlist is not there and there's an album name instead? So you can't see anything in the tree at all? What in the world is THAT?


My tree is fine, like it contains the root of my playlists, it's just not called Playlists anymore, but instead it's now named A Tribe Called Quest. It's quite peculiar but harmless to me. I took a screenshot for you - http://www.slothy.com/jemplode.jpg

*note* I actually have my playlist separated into Artists and Genres, those aren't copies of the jemplode ones, those are just the names of my playlists.

Let me know if you want me to put my empeg on the net tonight and I can email you the IP so you can connect yourself if that would help.

Jon
Posted by: tfabris

Re: 69. Initiate off-color jokes mode. - 29/09/2004 00:39

You know, some of the behavior you're describing (playlists and playlist names getting scrambled amongst each other) is something that happened to me when I was trying out one of the alpha software builds, switching back and forth between V3 and V2, and doing emplode synchs. What software version is on the player that's showing this behavior?
Posted by: slothy

Re: 69. Initiate off-color jokes mode. - 29/09/2004 04:34

Ooh. Apparently I used emplode 2.0-beta13 when I did that sync. If that's the culprit, how would I go about renaming my "A Tribe Called Quest" back to Playlists? jemplode v69 has already done a db rebuild (from memory) and it's still called that. Should I uncheck that and force a resync?
Posted by: mschrag

Re: 69. Initiate off-color jokes mode. - 29/09/2004 06:07

Can you get a playlist properties dialog on the root playlist in jEmplode?
Posted by: tms13

Re: jemplode 69 - 05/10/2004 14:29

Every time I edit a track or playlist, all its ancestor playlists get "Various" for artist, album, genre and year. I understand that this is supposed to be some kind of feature, but I think it's a real pain. How do I turn this off?

Also, sorting is no longer stable. In other words, if I sort a playlist on (say) Genre, I'll get all the Ambient followed by all the Black Metal followed by all the Classical and so on (yes, I have eclectic tastes!). So far, so good. But when I select "Set Playlist Order", I get a different sequence to what's displayed (though still Ambient, Black Metal, Classical, ...). This is a problem because if I then sort by, say, Year, the Genre no longer acts as a secondary key - within each year, the genres are now all jumbled up.

I think that sorting should use the current display order as a fallback when two items compare equal on the relevant field; this would solve the above.

This is a regression since v55 (though that seemed to use playlist position rather than display order as a fallback, so you needed to "Set Playlist Order" at each step to get working secondary and tertiary sorts).
Posted by: mschrag

Re: jemplode 69 - 05/10/2004 14:41

So on the rollup tag values, yeah it is a "feature", but I debated whether i would add it into non-soup playlists or not. I'll make that an option.

As far as sorting, you should probably use Playlist Properties=>Set Sort Tag instead of Set Playlist Order. I'll check out Set Playlist Order and see what it might be doing. Incidentally, I don't think Set Playlist Order ever supported secondary sort keys (at least I didn't write support in -- you may have been able to do some trick to make it happen ,but it was definitely a side-effect).

When you say you get a difference sequence than what's displayed -- if you set playlist order on a genre sort, then sort by "position", is it sorted by genre or just totally random?
Posted by: tms13

Re: jemplode 69 - 05/10/2004 15:15

Quote:
So on the rollup tag values, yeah it is a "feature", but I debated whether i would add it into non-soup playlists or not. I'll make that an option.

So it's mandatory in v69? Okay, I'll wait for this to become optional.

Quote:
As far as sorting, you should probably use Playlist Properties=>Set Sort Tag instead of Set Playlist Order. I'll check out Set Playlist Order and see what it might be doing. Incidentally, I don't think Set Playlist Order ever supported secondary sort keys (at least I didn't write support in -- you may have been able to do some trick to make it happen ,but it was definitely a side-effect).

What does "Set Sort Tag" do? I shied off this because I thought it might persist and interfere with later hand-edits or additions. But if it's not a persistent thing, then how does it differ from "Set Playlist Order"?

What I mean by secondary sort keys is that sorting in turn on two different tags (by selecting the corresponding headers in the list display) gave that effect - any items that sort equal on the current key remained sorted (with respect to each other) according to the previous key. That's no longer the case.
Posted by: mschrag

Re: jemplode 69 - 05/10/2004 17:14

Quote:
What does "Set Sort Tag" do?

It is persistent ... I figured that's what you were going for. It will maintain the sort order of that playlist on whatever tag you choose. If you make changes, it will reorder your tunes accordingly. The only difference SHOULD be that Set Playlist Order is a one-time thing, but it sounds like there may be an issue.

Quote:
any items that sort equal on the current key remained sorted

I never wrote that intentionally, so that sounds like a side-effect of whatever the sort algorithm was doing. It should have been the case that if you sorted on Year, then clicked on Artist, it should have resorted everything. It was probably a coincendence of implementation that previously equal fields would not reshuffle. I think QuickSort by default does not guarantee that two equal key comparison won't move.
Posted by: tms13

Re: jemplode 69 - 06/10/2004 12:53

Quote:

Quote:
What does "Set Sort Tag" do?

It is persistent ... I figured that's what you were going for. It will maintain the sort order of that playlist on whatever tag you choose.

Ah, that's what I thought, and not really what I want most of the time (though I do have a couple of playlists that I keep sorted on a combination of three tags - but I guess the above would only use one tag, and remain shuffled with respect to others.

Other playlists, I sort to get a starting point, but often introduce other tunes - for example, an album sorted by track number may get my standard blank track added, to separate the original tracks from the "bonus" tracks on a reissued CD.

Quote:

Quote:
any items that sort equal on the current key remained sorted

I never wrote that intentionally, so that sounds like a side-effect of whatever the sort algorithm was doing. ... I think QuickSort by default does not guarantee that two equal key comparison won't move.

I thought Quicksort was stable by design?

Anyway, if it's possible to make the sort stable again (perhaps by using position as a fallback in your comparator for equal items), then I hereby request such. It would save switching between jemplode versions all the time!
Posted by: tms13

Re: jemplode 69 - 06/10/2004 14:35

BTW, is it right that I now have a bunch of *f files in my fids directories? I thought *f were supposed to be virtual files, and never saved to disk. I'm sure that earlier versions didn't do this.
Posted by: Roger

Re: jemplode 69 - 06/10/2004 14:53

Quote:
BTW, is it right that I now have a bunch of *f files in my fids directories? I thought *f were supposed to be virtual files, and never saved to disk. I'm sure that earlier versions didn't do this.


IIRC, the *F files are intercepted by the empeg protocol endpoint on the player and redirected to the dynamic data area.

I don't think that Hijack's FTP server knows what to do with them.

I think that JEmplode is sending them regardless of the underlying connection method.
Posted by: tfabris

Re: jemplode 69 - 06/10/2004 15:35

Aha, good catch. Mike?
Posted by: tms13

Re: jemplode 69 - 06/10/2004 15:54

Quote:
IIRC, the *F files are intercepted by the empeg protocol endpoint on the player and redirected to the dynamic data area.

I don't think that Hijack's FTP server knows what to do with them.

I think that JEmplode is sending them regardless of the underlying connection method.


I thought that was the case. It explains why the "ignore as child" setting I tried to apply is being lost. The *f files need to go over the Empeg protocol, not FTP, right?

I didn't notice this until I ran rsync after my last update (I only go music shopping every couple of months these days, but I still buy a dozen titles at a time).
Posted by: mschrag

Re: jemplode 69 - 06/10/2004 19:57

Quote:
I think that JEmplode is sending them regardless of the underlying connection method.

This would explain why dynamic data is not being updated by jEmplode.
Posted by: mcomb

Re: jemplode 69 - 06/10/2004 22:27

Quote:
Quote:
I think that JEmplode is sending them regardless of the underlying connection method.

This would explain why dynamic data is not being updated by jEmplode.


D'oh. Thats most likely my fault from the patch I gave you way back when. I seem to remember just excluding the low number virtual fids (less than 110 or something like that).
Posted by: mschrag

Re: jemplode 69 - 07/10/2004 01:43

mcomb: 1 bug, mschrag: 32768 bugs
I have to keep an eye out on your patches, lest you close in on me further
Posted by: tfabris

Re: jemplode 69 - 07/10/2004 01:47

Quote:
mschrag: 32768 bugs


You need to add a sign bit to that bug counter. I think you might have maxed it out.

Aw, darn, that's one more!
Posted by: mschrag

Re: jemplode 69 - 07/10/2004 02:34



So I just checked w/ my Emplode again, and with 3.0a7 + Emplode I can't set marked on or off either. Is it possible there is just a problem with writing dynamic data on the Empeg side or is mine just hosed somehow ...
Posted by: Daria

Re: jemplode 69 - 07/10/2004 03:11

Well, it seems to work from within the player; So the protocol handler code itself is broken? It's be wrong to teach jEmplode to read the stuff out, change the array, and write it back. Right?
Posted by: mschrag

Re: jemplode 69 - 07/10/2004 04:12

Which array? You mean read the raw dynamic data partition out and then write it back? I believe jEmplode actually does read the raw partition, but the Empeg protocol specified that writes happen one at a time on the fid|0xf files. It's certainly conceivable that I could write the entire partition back, but I don't know if I have direct write access to it without hijack help (I believe if you try to write back to the dynamic data FID, it says "no problem" and then ignores you).
Posted by: Daria

Re: jemplode 69 - 07/10/2004 04:28

The array of marks. But isn't it in the flash?
Posted by: Roger

Re: jemplode 69 - 07/10/2004 06:55

Quote:
It explains why the "ignore as child" setting I tried to apply is being lost.


No it doesn't. The "ignore as child" setting goes in the *1 file.
Posted by: Roger

Re: jemplode 69 - 07/10/2004 06:56

Quote:
The array of marks. But isn't it in the flash?


Nope. It's in dynamic data.
Posted by: tms13

Re: jemplode 69 - 07/10/2004 12:11

Okay, I found a couple of playlists that I want a persistent sort on. The Artist ones were straightforward (alphabetically by artist - I use artist to store the sort-order version, surname first), but my Essential Singles collection, which I keep in reverse chronological order, had me stumped. How do I set a persistent sort that's not in the "natural" direction for the key?
Posted by: tms13

Re: jemplode 69 - 07/10/2004 12:12

Quote:
Quote:
It explains why the "ignore as child" setting I tried to apply is being lost.


No it doesn't. The "ignore as child" setting goes in the *1 file.


Er, yes. Forget my comment then. It was probably a one-off, as it's working now.
Posted by: mschrag

Re: jemplode 69 - 07/10/2004 13:24

Yeah, the "reverse" flags is hardcoded to true right now ... Only because those need to be set together, but right now the sort tag = tag name, so some things assume they can just take the value and lookup the NodeTag for it. I just didn't get a chance to fix it so it's like "tagname,direction" and the couple of places that directly use that tag. It's on the list that will probably make the next build. I started to do it for 69 actually, but i cut it because 69 had some big fixes that i wanted to get out quicker.
Posted by: mschrag

Re: jemplode 69 - 07/10/2004 13:24

Quote:
it's working now.

If you see this again, let me know and I'll check it out further ...
Posted by: genixia

Re: jemplode 69 - 07/10/2004 15:41

Something Derrick's just said has given me an idea for a feature request. Can we have a "Clear All Marked Flags" button?
Posted by: mschrag

Re: jemplode 69 - 07/10/2004 16:46

If I could successfully write marked tags back, you could
Posted by: Daria

Re: jemplode 69 - 07/10/2004 16:48

Yeah, I was considering just writing a tool to do it. It should be be writing a block of zeroes at a fixed offset...
Posted by: mschrag

Re: jemplode 69 - 07/10/2004 17:42

DynamicData isn't just "marked" by the way .. it has playcount, lastplayed, and some other stuff in there. Check out (IIRC) dyndata.h (dyndata*.h) in emptool.
Posted by: Daria

Re: jemplode 69 - 07/10/2004 17:54

Quote:
DynamicData isn't just "marked" by the way .. it has playcount, lastplayed, and some other stuff in there. Check out (IIRC) dyndata.h (dyndata*.h) in emptool.


Ok, so the tool would just be a little different. I guess I really should get back to work on scratchlib.
Posted by: mschrag

Re: jemplode 69 - 07/10/2004 18:45

Just didn't want you to zero out all your other data
Posted by: Daria

Re: jemplode 69 - 07/10/2004 20:55

I back up the entire dynamic data slice before I mess with it. I also have a backup of genixia's slice, since we used his player to AutoEQ in my car. I still haven't extracted settings, because I keep saying I'm going to finish scratchlib. Of course, this week my wife has been taking the car anyway, so...
Posted by: SE_Sport_Driver

Re: jemplode 69 - 07/10/2004 22:29

Is there a way to transfer that data from one empeg to another (for AutoEQ)?
Posted by: Daria

Re: jemplode 69 - 07/10/2004 22:37

it's a block of data in the dynamic slice, I could probably work up a shell script that calls dd and ftp for you, since I doubt I will finish scratchlib soon
Posted by: zexpe

Re: jemplode 69 - 29/10/2004 15:42

Mike, are you planning to include some way of allowing us to have secondary, tertiary etc. sub-sorts for our soups/playlists for the next release? Just making sure the sorting algorithm is stable (maybe have an option to use the old algorithm) would be great.

It would make the new sort layers for soups much more powerful if we could, say, add multiple sort layers for each sub-sort. If the sorting algorithm was stable I think this would naturally happen.

The reason I would like this feature is because when I create genre soups I like to have each genre soup playlist sorted by artist-year-album-track# so that I still have the ability to unshuffle around an album when playing a shuffled genre playlist.

Thanks,
Ross
Posted by: mschrag

Re: jemplode 69 - 29/10/2004 16:40

I actually haven't been able to really work on the next version yet, so there's nothing in particular lined up, but this one is definitely on the list and would be a likely candidate.
Posted by: The Central Guy

Re: jemplode 69 - 30/10/2004 01:30

Not sure how much work it would be, but I'd like to request a small feature upgrade for jEmplode70...When drilling down to the dialog box for each song labeled "Tune" (the one that has fields for Title, Artist, Album, Genre, Year, Track #, PIN, and comments), would it be possible to add a field at the bottom next to Ok and Cancel called "Next" that would go to the next tune in the list? There's been quite a few times where that would have been quite handy to have...

Oh well, just my $.02....Thanks, Randy
Posted by: tfabris

Re: jemplode 69 - 30/10/2004 04:12

Sounds cool. I'd like the abililty to go to the next tune with something like Enter or Ctrl+enter, so that if I'm tagging a group of tunes, I can change them in order. Your NEXT button could be mapped to a keystroke like that. Combined with Mike's "Tony Selection" feature which handles the selection of the song title when the box is opened, it could make complete album edits very quickly.
Posted by: image

Re: 69. Initiate off-color jokes mode. - 02/11/2004 06:44

a bug... i did a sync of one directory, and then tried to add another directory while in the middle of it.... the sync froze right after i dragged the files into the window.
Posted by: mschrag

Re: 69. Initiate off-color jokes mode. - 02/11/2004 11:32

I'm probably going to be MIA from jEmplode development for a little while until I get into the groove w/ my new job, so I wouldn't keep your hopes up for a 70 release in the next few weeks ... Consider the bug noted, though.
Posted by: mcomb

Re: 69. Initiate off-color jokes mode. - 02/11/2004 16:35

Is it just me or does sorting not work at all in 69? If I try to set Tag Name to Sort On to 'tracknr' in the main Options dialog the setting isn't saved. If I try to do it in properties for the individual playlist it is saved, but doesn't work. The sorting seems to be completely random. The only thing that does seem to work is alpha sorting.

Maybe it is just that I don't understand the sort changes in version 69, but none of the sort options that I can find seem to work for me.

-Mike
Posted by: wfaulk

Re: 69. Initiate off-color jokes mode. - 10/11/2004 16:12

I seem to have the same problem. Sorting doesn't work. If I hit the sort button more than once, I get a different order every time.

Also, it's filling in some Playlist fields as "Various" when I don't see any reason for it to be doing so.
Posted by: tms13

Re: 69. Initiate off-color jokes mode. - 11/11/2004 15:03

Minor bug for when you get back into JE dev:

"Tony-select" seems to be always on when creating a new playlist, regardless of my configure preference. IOW, if I create a new playlist, I get asked for its name, but if I've already selected some text to enter, it gets usurped by the dialog changing the selection to "New Playlist".
Posted by: zexpe

Re: jemplode 69 - 22/12/2004 15:50

Quote:
Quote:
BTW, is it right that I now have a bunch of *f files in my fids directories? I thought *f were supposed to be virtual files, and never saved to disk. I'm sure that earlier versions didn't do this.


IIRC, the *F files are intercepted by the empeg protocol endpoint on the player and redirected to the dynamic data area.

I don't think that Hijack's FTP server knows what to do with them.

I think that JEmplode is sending them regardless of the underlying connection method.


OK, as a regular jemplode 69 user, does this mean I can safely delete all 3000+ *f files in my fids directory? And will jemplode 69 just recreate them again willy-nilly! ;-)

Ross
Posted by: mcomb

Re: jemplode 69 - 23/12/2004 17:34

Quote:
OK, as a regular jemplode 69 user, does this mean I can safely delete all 3000+ *f files in my fids directory? And will jemplode 69 just recreate them again willy-nilly! ;-)


Yes (he said without actually trying it), and yes. If they really bug you turn off the "Use Hijack when possible" checkbox in the options and then jEmplode should use the empeg's native protocol for transfer which will put new *f files where they belong (won't do anything about the existing ones though). That will slow down your new music uploads a bit.

-Mike