Displayserver 2.0b2 and backup

In reply to:

---

Is there a way I could get a copy of the original mp3list.html template because that seems to be what those PERL scripts need to create a backup with the EMPEG's full directory structure.

Also can't seem to get the perl script to work in win2000. When I double click it an msdos window pops up and then momentarily disappears. Perhaps I didn't install the useragent module correctly. This whole perl thing scares me. A windows version would be great!

---

The original displayserver served up the data in this format. I haven't played with the new one enough to write a compatible module. It should still be on Frank's site (or at least I HOPE it is... I need to grab it now)

You should be able to run both at the same time, just adjust the port number in displayserver 2.0.

RE: perl in Windows... Sorry, I was the one to convert the slashes TO Unix, so I'm afraid I can't help you much there...

I have looked at zmodem, but couldn't find any suitable software for delphi. If anyone finds some freeware zmodem implementation, let me now...

Frank van Gestel

when i execute the perl script with the ip address of my empeg substituted in I get the following response from perl:
Bareword found where operator expected at getmp3s.pl line 25, near "$server = "h
ttp"
(Might be a runaway multi-line "" string starting on line 24)
(Missing operator before http?)
Bareword found where operator expected at getmp3s.pl line 25, near "//empeg"
(Missing operator before empeg?)
Bareword found where operator expected at getmp3s.pl line 26, near "$urlroot = "
http"
(Might be a runaway multi-line "" string starting on line 25)
(Missing operator before http?)
Bareword found where operator expected at getmp3s.pl line 26, near "//empeg"
(Missing operator before empeg?)
String found where operator expected at getmp3s.pl line 43, near "$dest =~ s/[?*
""
(Might be a runaway multi-line "" string starting on line 26)
(Missing semicolon on previous line?)
syntax error at getmp3s.pl line 25, near "$server = "http"
Unmatched right square bracket at getmp3s.pl line 43, at end of line
Unmatched right curly bracket at getmp3s.pl line 96, at end of line
syntax error at getmp3s.pl line 96, near "}"
Execution of getmp3s.pl aborted due to compilation errors.
Any idea how to correct this?

Thanks,

BG

Without seeing it, it looks like an unmatched quote.

send me a copy of it at [email protected] (removing the spam part of course) and I'll take a look at it.

is there ANY chance the Displaysever2.0 will work with the updated release
Yes it does, just don't install the 1.03 kernel...

Ok...for some wacky reason, I can't get the darn thing to install after upgrading to 2.0b3. I'm not using the .mp3, since I removed it from my player earlier, and emplode doesn't like that file so much anymore. I used zmodem to transfer the install.sh and install.tar files to my player, but after making install.sh executable, I can't get it to run. When I type "./install.sh" it tells me there is no so file or directory, even though it appears with a "ls" command in the same directory.

Does the Linux kernal work differently now with 2.0b3? Am I doing something really stupid that should be obvious? I could have sworn that I installed ds2b2 this way before (over 1.03, though).


- Chris
32GB MK2 090000664 Smoke
Queue # 2 (who the heck was 1?)

Take a look at the very first line in the script; it sounds as if the
#!/path/to/interpreter
line is pointing to a file that doesn't exist (at least on your player).
Edit that to point to where your sh/bash executeble resides and you should be in business...

/Michael

Or you edited the install.sh file on the PC, in which case the file needs to be converted to unix format again.
As michael said, the interpreter is misinterpreted, as it now has an extra character at the end...

Frank van Gestel

Greetings!

Thanks!!! I forgot about that, and did not see the ^M appear anywhere. That fixed my other problem, as well.

Paul G.
SN# 090000587 (96GB Smoke)
SN# 030103046 (10GB Blue - Emergency Spare)

Hmmmm...

it sounds as if the
#!/path/to/interpreter
line is pointing to a file that doesn't exist

It points to /bin/bash, which exists.

Or you edited the install.sh file on the PC

I didn't, though. I did extract install.sh on the my PC, but I never opened or edited the file. I just moved it over with zmodem.

- Chris
32GB MK2 090000664 Smoke
Queue # 2 (who the heck was 1?)

Still at a loss for why I can't get DS to install. Still looking to see if anyone can point me to the potential problem.

I just redownloaded ds2b2.zip, extracted it down to the install.sh and install.tar files, moved them over to my player, made the install.sh file executable and tried to run it. It still gives me the same error. I'm thinking that the environment on my empeg is different somehow, but I'm too much of a Linux novice to know how it's different.

I know that..
a) the install.sh was never opened/edited/changed on my PC. I moved it over, along with the install.tar file, without touching it.
b) the first line of the install file point to /bin/bash, and that /bin/bash is still a valid path/filename on my empeg.

Perhaps I glance at the attached log would help some of you gurus tell me what I'm missing. This method is supposed to work, correct? As in..I should be able to move those two files over and install using install.sh, right?


- Chris
32GB MK2 090000664 Smoke
Queue # 2 (who the heck was 1?)

Hmmm, didn't spot anything in your log...

Still thinking it might be a spurious character... Did you 'tab out' the install.sh filename when trying to run it? Might be a wacky character in the filename itself... Try to enter ./inst[TAB] , instead of typing all the name yourself, this'll make the shell expands the filename which should include any invisible character.

Also, though you didn't open it on the PC, try to take a look at that first line with a hex editor (or just open it in Notepad; it should all be one long line with small black squares where linefeeds should be (don't use wordpad or word, as they both autotranslate Unix style linefeeds to Windows style).

/Michael

Still thinking it might be a spurious character...

I'm thinking not. I tabbed out the filename, but that didn't seem to make a difference.

Also, though you didn't open it on the PC, try to take a look t that first line with a hex editor (or just open it in Notepad;

Okay...I just redownloaded (again) the zip from Frank's site, extracted it with winzip down to install.sh and install.tar, and opened install.sh in Notepad (THE Notepad).

I don't see any of the small black squares (though I do know what you're talking about). Looks like windows style linefeeds here. So I guess...somewhere along the way (though I don't understand where it could happen) these characters are being converted. Perhaps this happens when opening the file in Notepad (as in, this newer version of Notepad acts the same way WordPad does in this regard. I'm using Windows 2000 SP2). That's really the only thing I can think of...but then, it wouldn't be a problem if I never opened it up in Notepad. The file should still have the original Unix style linefeeds. How could that change just by extracting the files?

Puzzled...

- Chris
32GB MK2 090000664 Smoke
Queue # 2 (who the heck was 1?)

Okay..I still don't know how, but the linefeeds were being converted to Windows style somewhere during extraction. How this would happen between WinZip and zmodem, I don't know, but there it is.

I wrote a little PHP script to convert the windows style linefeeds to Unix style (it was the first thing I thought of off the top of my head after a long day of writing PHP scripts for work)...

$file=fopen("install.sh", "r");
$text = fread($file,filesize("install.sh"));
fclose($file);
$newtext = str_replace("\r\n","\n",$text);
$wfile=fopen("test.sh", "w");
fputs($wfile,$newtext);
?>

...moved the resulting file over to the empeg, and voila. Now I'm just curious to know how install.sh is being changed (given that the original on Frank's site isn't that way).

Perplexed...

- Chris
32GB MK2 090000664 Smoke
Queue # 2 (who the heck was 1?)

While I'm on a roll here talking to myself...

Yes, I found the option in Winzip (that I didn't know existed) that's labeled "TAR file smart CR/LF conversion" and it was enabled. I disabled that and extracted the original archive again, and the linefeeds were not converted. I didn't suspect Winzip would have been changing the files while extracting, though I guess that was the last remaining possibility.

Appeased...

- Chris
32GB MK2 090000664 Smoke
Queue # 2 (who the heck was 1?)

Learn something new every day - I had no idea that WinZip had such an option. Previously, stuff here on the board has been zipped up just to protect from accidental conversion of linefeeds between platforms...

/Michael

Hmmm, "TAR file smart CR/LF conversion" probably means that 'true' zip files are OK, and only tar files are affected...

Edited by mtempsch on 23/10/01 07:12 AM.

Hmmm, "TAR file smart CR/LF conversion" probably means that 'true' zip files are OK

I would imagine so. In this case it was a tar inside of a zip. As a reference, I'm using WinZip 7.0, so I assume any newer version than that would have the option (and apparently enabled by default. Grrrrr).

That's a useful nugget of information, wouldn't you say?

- Chris
32GB MK2 090000664 Smoke
Queue # 2 (who the heck was 1?)

Yep WinZip v8 did the same thing to me. I have a nice (freeware) editor called PFE that showed the problem and let me simply resave the file as a UNIX format file.

(list 6284, Mk1 S/N 00299 4GB blue [for sale]. Mk2 S/N 080000094 26GB blue)

Everyone who had problems with large playlists or playlists that aren't shown, should try the attached binary. It is not advisable to use large playlists (+1000 entries) with displayserver. I just tested a playlist containing 3000 entries, which lets netscape exit with an application error; in IE5.5 it takes about ten minutes to load and causes IE to use more than 64 Mb of memory
This also fixes problems when tags are defined in the metafid without values...
just extract the binary from the zip-file and copy it over the old one.
I'll create a beta3 soon...


Frank van Gestel

In beta 3 you going to make it so we can send the .mp3 file to the empeg using emplode?

I wanna get Display Server on my empeg but of course upgraded to 2.0 before I noticed all of what Display Server could do. Now I'm stuck without it b/c I don't know much about linux or the empeg in general and can't upload the mp3 file that comes with display server.

Of course if someone wants to create a in-depth walk threw on how to do it now without waiting I'd be willing to give it a try. I do have developer installed and I do know how to get into it and get to a shell prompt.

Blue MK2 20 Gig, Slowly getting filled to the brim.

You can go the rather convoluted route of using RZ and SZ (Receive ZModem and Send ZModem). Telnet into the empeg using Hyperterminal, remount one of the partitions in r/w mode (don't forget to umount first). Then, type 'rz' on the empeg to initiate a receive and use Hyperterminal to SZ the file to the empeg.

The real problem with doing this is that the displayserver installer tries to find the .mp3 file in the playlist database (it greps the entire list until it finds a file with the correct file size (very dodgy) then extracts it. It may be possible but I don't know how to add a manually uploaded file to the empeg tracks database.

I ended up doing a manual install by simply copying the actions described in the display server read me e.g. "tar xzfO blah.mp3 install.sh | /usr/bin/bash" (or something similar) etc. I did manage to get it all up and running eventually but unfortunately, it has a tendency to core dump whenever I try to use any of the exciting features like streaming mp3s to my PC.

--
Dean

--
Dean

Works great Frank! Even seems a bit faster than the old one.

Thanks very much

I've unzipped the ds2b2.mp3 with the "TAR file smart CR/LF conversion" DISABLED. I'm ready to upload the install.sh and install.tar files via Transfer in Hypertrm. Can someone assist me in how to 'mount' or 'umount' the drives and what directory I should upload to? From there I would like to launch empackager.exe on the win platform to complete the install.

Thanks in advance for any help.

Have no clue as to directory and/or the empackager (haven't played with it yet), but for remounting writeable, enter the commands
rw followed by
rwm - this command may take some time to execute.
When you're done
ro and
rom in order to remount readonly

/Michael

Quick question for you...where do you find those little minix.gif icons that you use in displayserver?

Thanks.

Hi.

The factory "ro" command includes the equivalent of the "rom" command. And if it wouldn't, the "correct" order of those two commands would be "rom" first followed by "ro", AFAIK.

cu,
sven

The easiest way to install ds2 on the empeg on 2.0 is first downgrade to 1.03, use emplode to upload ds2b2.mp3 to the empeg, then reinstall v2.0 developer-image. After that, connect empeg over serial and start empackager. It should find the file and start the install-program
To install the new executable :
- open hyperterm and start shell

# rw

# rwm

# cd /tmp

- use send-file option in hyperterm to send file ds2b2.mp3

# cd /opt/ds2b2

- check if you are in the right dir

# ls -l

if you see this line :

-rwxr-xr-x    1 root     root        95783 Oct  4 22:48 ds2

it means you've got the old beta2 version
move the old executable :

# mv ds2 ds2.old

- copy the new one to the dir :

# cp /tmp/ds2 ds2

- make the new file executable :

# chmod +x ds2

- check the new file

# ls -l

- output should look like this:

-rwxr-xr-x    1 root     root        93103 Oct 24 23:46 ds2

- remount the disks ro :

# ro; rom ( or rom;ro. I think ro only is sufficient to remount all disks ro, haven't checked)

- reboot empeg (pull plug)

Errr, which kernel do we use for DS under 2.b3?

I've now got the display server working through a manual install thanks to all of your help. Very Nice!

I'm having a little trouble with the script I'm working on. I have a script that allows for download or streaming of an MP3 file, and works most of the time. I haven't had any problems downloading mp3s using the script, but certain songs will stop playing in the middle of the song while streaming.

I'm not having the trouble while using displayserver to stream the same songs from the empeg...only when using my script to stream the songs from my backup copy. It seems to thing the file is smaller than it really is.

Perhaps it's hitting something in the file that it interprets as some sort of EOF character? What does displayserver do to the content data of the file before it is sent, if anything? Is there a header that can help? What headers do you use when getting the mp3 (via m3u)?

Thanks.

A couple more notes about my problem that I noticed...

1. WinAmp always seems to know exactly know how long each song is supposed to be, but will cut out in the middle of a song to move on to the next track.


2. The songs that cut out are all songs over 5:04, as that's the point that the songs will cut out. My script works great for pop radio, but this is a big problem for a progressive rock/metal fan such as myself.

Whether songs are are being sent via a download request or being called by WinAmp from a m3u playlist, the same headers are always sent


header (sprintf("Content-Length: %s",filesize($sendfile)));
header ("Content-Type: application/octet-stream");
header (sprintf("Content-Disposition: attachment; filename=%s",$filename));

So...any ideas what might be causing the stream to only allow for 5:04? As I've said...when I select download instead of playing m3u stream, the entire file downloads fine.

Thanks.

the default timeout value for a TCP-connection in apache is 300 seconds. Try setting the Timeout directive to 600 or more to resolve the problem

I suppose I figured that if the song downloads in a few seconds, that the stream should behave the same way (download ahead of time and store in a temp file, then disconnect while the song finishes playing, and start a new connection for the next song). I didn't think the connection stayed open the whole time, but I guess that would explain it.

Hmmm...well, I'm not using Apache. The app is written in PHP, and it's running on IIS (on my workstation, because there's where all the fids are from using your wonderful ds backup utility). I suppose I should take a look around at the IIS config and see what I can find.

Thanks.