Hi everyone.
QUick question: wha happens if by mistake you drop a non-mp3 file in the emplode window and then sync? Does the file get tranfered to the empeg hdd? Does empeg recognize mp3s from other kind of files during sync?

Thank you all

Taym
______________________________
MK II BLUE 12GB 090000923

Files with other extensions than .mp3 will be excluded by emplode, so dragging an entire directory with all sorts of files in them will only transfer .mp3 files.

If you deliberately renamed some files with an .mp3 extension, they will be transfered as well. In this way you could take other files with you. Use displayserver to retrieve the file.

Edwin de Vaan
mk2 rev.7 Trillian # 080000263 6+20Gb blue/red

You took the words right out of my mouth, Edwin. Thanks.

I often rename files to ".mp3" so that I can use the empeg to taxi them home and retrieve them with displayserver. You get more storage space than you would with an iomega drive. Not quite as convenient, but it's certainly cooler to use your car stereo as a file taxi.

A couple of tips:

- Remember that Displayserver only works on Ethernet, so you can't retrieve the file via USB. There is another program floating around on this BBS called "EmpegTaxi" that uses USB, but we're talking about Displayserver here. Since you're using Emplode to send the file to the empeg, you can use USB or ethernet for that. But for getting the file off the empeg with Displayserver, you need ethernet. Keep that in mind as you're planning the taxi operation.

- I always stick my taxi files in the "Unattached Items" folder, to keep them separate from the rest of the files.

- The empeg might try to play those files if they come up in the shuffle, even if you put them in "Unattached Items". If this happens, it won't hurt anything, it will just say that the MP3 file is invalid. Just skip to the next track and unpause it.

- To reduce the chances that the empeg will try to play the file, and to make transfers easier, I always zip my stuff into one large zip file and send that to the empeg.

- If you do the steps carefully, you can even rename the file extension as-you-go. When creating the zip file, name it ".zip.mp3" when prompted for the file name. When retrieving it from displayserver, right-click on it and hit "Save target as..." and remove the .mp3 extension before hitting Save.

- Don't forget to use emplode to delete the zip file from the empeg when you're done.

Now... who was working on EmpegTaxi? Is there a more user-friendly version of it yet?

___________
Tony Fabris

This is exactly what I have been doing too. The zip files are definitely the way to go.

I did have the W2K service pack 2 on there at once stage (still as an EXE file). It came up in the shuffle and the empeg tried to play it (didn’t say MP3 file is invalid as it does for ZIP files). Had to reload the .upgrade to get things going again.

Rod.

ROFLMAO !!!!! So MicroSoft finally did it !!! They created a Linux Virus and it's called Windows 2000 Service Pack 2 !!!

[sounds of someone choking in laughter]

Cheers,
Hans


Mk2 - Blue & Red - 080000431

I got as far as getting a file list off the empeg by taking control of the usb and serial console. Now I can automate the transfer of a file by locating the size from the file list and sending the right command through the serial port.

However...

The empeg -> PC transfer seems to work fine, providing your PC is fast enough. Without a program on the empeg to split the file into chunks and CRC them, I can't ensure the file is actually the same (In most cases it works fine, but I'd like confirmation. At least if you use a zip file you gain some CRC checking)
Direct PC -> empeg transfer seems to generate a file of the correct size, but it's full of junk... =(

As I see it, the choices are...

• Implement a packet protocol with checksum and retry, and use a program on the empeg to generate/receive the packets (Basically what the empeg software does)
  
• Implement the PC side of the empeg protocol in object pascal and use the existing player software to do the packet and file manipulation.
  
• Find a compatible USB PPP driver, and run TCP-IP
  
• Find a kind soul who can compile emptool for win32, and use that to do the transfers
  
• Other

So I'm stuck at the moment, as I know very little C++, and I'm unable to compile emptool or the protocol libs in C++ builder...

If anyone has any ideas it's probably a good idea to start a thread in Programming...

Jazz
(List 112, Mk2 12 gig #40. Mk1 4 gig #30. Mk3 1.6 16v)

Without a program on the empeg to split the file into chunks and CRC them, I can't ensure the file is actually the same

First of all, I've never had a problem with EmpegTaxi feeding me a bad file. I've used it a bunch of times. Second of all, I only ever use zipfiles, so the lack of a checksum is no problem (for me).


Direct PC -> empeg transfer seems to generate a file of the correct size, but it's full of junk... =(

Not a problem, because you don't need to use "your" method for sending files to the Empeg. The empeg already has a perfectly good method for sending files to it through Emplode. All those things you listed as work-arounds... you don't need them. You only need Emplode.

By the way-- in version 1.1 of emplode, you will get to see the FID when you look at a column of files, making retrieval easier if you're using this kind of method.

Anyway, another option to look at is to dig into the open-source code for Emptool and see how it sends the files. You could use some variation of that method. Hugo keeps hinting that the emptool sources could be fairly easily modified into a taxi program if you so desired.

In any case, would you mind releasing that version of EmpegTaxi that controls the serial port and makes it easier to retrieve files? All I'd need is a way to easily grab one file out of "Unattached Items" and then I wouldn't need Displayserver any more. (I can use EmpegTaxi to retrieve the files right now, but I hate having to muck about at the bash prompt to do it.)

___________
Tony Fabris

Not a problem, because you don't need to use "your" method for sending files to the Empeg. The empeg already has a perfectly good method for sending files to it through Emplode. All those things you listed as work-arounds... you don't need them. You only need Emplode.

Yes, I agree for EmpegTaxi you can use empload... But I was aiming to write a USB connection object to be used for bi-directional connections (e.g. displayserver over USB). I could try to re-implement the empeg protocol from the emptool source, but C++ is not my primary language (it's probably down there at number 12!)

As to the next release, well I've got it searching by title. It needs cleaning up a little (i.e. error handling) but I should have something within a few days...

Jazz
(List 112, Mk2 12 gig #40. Mk1 4 gig #30. Mk3 1.6 16v)

As to the next release, well I've got it searching by title. It needs cleaning up a little (i.e. error handling) but I should have something within a few days...

I await the release anxiously!


___________
Tony Fabris

I await the release anxiously!

Wait no longer.. =)

http://nrg.nu/files/empegTaxi.zip

I'll announce it in general later, when I confirm that it works for other people than me... =)

Jazz
(List 112, Mk2 12 gig #40. Mk1 4 gig #30. Mk3 1.6 16v)

Thanks!

I've run into a snag...

I'm running additional software on the unit that requires more "Q"s than the default empeg configuration. There's the initial drop-to-shell from the player, but then it runs a script that needs at least one more Q to get out of its wait-for-button-press thing.

Is there a way you could get it to send a few extra Qs in succession? I think that I'm not the only one running extra shell scripts at player exit, and I think they are mostly all designed to exit with an additional Q.

I'm pretty sure that extra Q's at the bash prompt won't hurt anything...

___________
Tony Fabris

Also... heh...

My player's prompt from bash is called by a shell script, so it has different prompting than Empeg's. Instead of saying "empeg:/empeg/bin#", it says something like "bash:/empeg/bin#".

Perhaps all it needs to look for is "/empeg/bin#" for its initial connection?

___________
Tony Fabris

Crap, my prompt doesn't say what I thought it did. It simply says:

bash-2.03#

Yuck.

Wonder how you'd work around that in EmpegTaxi? Maybe allow the "search for" string to be configurable? Or just look for #? Yikes, I dunno!

___________
Tony Fabris

export PS1="empeg:\w# "


Roger - not necessarily speaking for empeg

I'm sure that's one of those newfangled linux commands I don't understand.

Guess I'll try sticking that in my init and see what it does, eh?

___________
Tony Fabris

For some reason the zip file is getting corrupted when I download it with IE. It works fine with Netscape 6 through, odd it's usually the other way around...

__
Unit serial number 47 (was 330 in the queue)...

I should of guessed you would break it... =)

If it times out, press cancel, and it will try to continue as if it received the correct string.

I'm working on a version with configurable prompt and q... =)

Jazz
(List 112, Mk2 12 gig #40. Mk1 4 gig #30. Mk3 1.6 16v)

That's odd... As I downloaded it with Ie5.5 to check it uploaded correctly...

Jazz
(List 112, Mk2 12 gig #40. Mk1 4 gig #30. Mk3 1.6 16v)

I'm working on a version with configurable prompt and q... =)

Wohoo! Thanks!


___________
Tony Fabris

I tried it a couple of times before giving up and trying Netscape, odd.

__
Unit serial number 47 (was 330 in the queue)...

Again, GetRight comes to the rescue. My initial click with IE didn't work right away, so I canceled it and ran GetRight, got the file fine.

___________
Tony Fabris

It seems pretty fast, I guess that's because it doesn't have the overhead of the tranfer protocol that emplode has.

Very impressive.

__
Unit serial number 47 (was 330 in the queue)...

Well this is going well...

I've finished the coding and testing of the new version, to find my web host has stopped responding (at least from here).
So I can't upload the new version... =(
I can't attach it to the BBS either, as it's a bit too big...

Ho Hum...

Jazz
(List 112, Mk2 12 gig #40. Mk1 4 gig #30. Mk3 1.6 16v)

You could e-mail it to me if you wanted. :-)

___________
Tony Fabris

By the way. After I installed 1.03 from scratch (fixing the Q and prompt), the Alpha2 version you posted earlier never finds anything. It acts like it works ("searching drive0, searching drive1, finishing, waiting for command"), but never finds anything, even just the letter "e".

Ah, I see. You need to insert the full file name, not just a substring. Okay, I understand that now. Substrings would be nice for the future, but I understand the way it is now. Cool.

___________
Tony Fabris

It matches from the beginning of the title, so it will do a substring (sort of)

It's because of the way I use grep... When the new version appears, you can watch the serial debug console to see what it does... =)

Jazz
(List 112, Mk2 12 gig #40. Mk1 4 gig #30. Mk3 1.6 16v)

Cool, just used the new one you e-mailed me. Serial debug is cool. Substring search works well as long as you know it's the start of the file name.

My only remaining wish is that it would save whatever string you last entered into the "search" box so I don't have to retype "taxi" every time.

This is an amazing cool utility now, thanks!

___________
Tony Fabris

Well my WebHost appears to have returned, so I've uploaded a new version.
It now remembers the last "Search For" correctly as well as the configuration...

http://nrg.nu/files/empegTaxi.zip

Jazz
(List 112, Mk2 12 gig #40. Mk1 4 gig #30. Mk3 1.6 16v)

Yep, as someone else said... it's like rubbing a lamp around here.

Thanks a million!

___________
Tony Fabris

By the way, I've tried replacing the "prompt" text with just a poundsign ("#") and it seems to work fine in my case. So no matter whether I've put a fresh copy of 1.03 or 1.1 on the player, or I've put in my custom init, or whatever, it still works.

Oh, and one other thing... if I hit the "close" button without first hitting the disconnect serial/usb buttons, the program locks up.

___________
Tony Fabris

That's odd...
Pressing close does the same as pressing both disconnect buttons, then quitting...

Glad to hear the configurable prompt works properly... =)

Jazz
(List 112, Mk2 12 gig #40. Mk1 4 gig #30. Mk3 1.6 16v)

Pressing close does the same as pressing both disconnect buttons, then quitting...

Well, I can reproduce it pretty reliably on both my home and work computers. One is '98, the other is '2K.

On both of those systems, there is a long pause as it tries to process both disconnects, and then it never seems to get around to closing the main window. After the two buttons get done disconnecting, the main window responds sluggishly (I can drag its title bar around), but I can't close it. Eventually, it either crashes on its own or I have to task-kill it. Either way, the error is pretty severe- some sort of memory error or page fault.

___________
Tony Fabris

Now that I think about it, that sounds like an old cascading-event problem like one might get in VB. I assume Delphi is similar.

Perhaps it's one of these kind of scenarios:

- You press close button.
- WindowClose code says "If (connected) then (disconnect) and (wait for disconnect) then (try closing again)".
- Disconnect routines take longer than expected.
- WindowClose code tries to terminate the window process but it can't because there's still active code in the disconnect routines.

Depending on how it's written, that might put the code into an infinite re-entrant loop where the WindowClose routine keeps calling itself. Eventually the process crashes when it runs out of stack space.

I don't know if that's what's happening or not, I just thought the behavior looked like that's what was happening. I've seen it in VB too many times now.

___________
Tony Fabris

Hey, Jazzwire. Does EmpegTaxi have a file-size limit?

I just tried to snag a file off the Empeg that was over ten megabytes in size, and it refused to get the file size. The File Size column stayed at "TBA" even though it ran through the motions of getting the file size.

___________
Tony Fabris

It shouldn't have any limit..
The file I was testing the transfer with was over 20 megs...

Can you try getting the file size, then look at the serial console and run the exact ls command from Hyperterminal (without the "> /dev/usb" bit). I'd like to see the result, as it's the only thing I can think of that could be causing a problem...


Jazz
(List 112, Mk2 12 gig #40. Mk1 4 gig #30. Mk3 1.6 16v)

The empeg is complaining that the file doesn't exist. This is what I see in the serial debug window:

ls -lQ /drive1/fids/65c0 > /dev/usb
ls: "/drive1/fids/65c0": No such file or directory

The file in question exists on drive0, not on drive1. Perhaps there's something fishy in the code that decides which drive contains which files?

___________
Tony Fabris

I don't know if this is how EmpegTaxi works, but the *1 file and the *0 file are not necessarily on the same disk.


Roger - not necessarily speaking for empeg

I don't know if this is how EmpegTaxi works, but the *1 file and the *0 file are not necessarily on the same disk.

I hope the info is in the database, so that both drives are tried only if the player rebuilds it, right?

Dragi "Bonzi" Raos
Zagreb, Croatia
Q#5196, MkII#80000376, 18GB green

Oops... Guess who assumed they were... =)

I'll fix my oversight tonight...
(Guess who doesn't have a two drive empeg... ;)

Jazz
(List 112, Mk2 12 gig #40. Mk1 4 gig #30. Mk3 1.6 16v)

ROFL!

Cool, thanks for the help, Roger, and thanks for the great utility, Jazzwire.

___________
Tony Fabris