Does anyone know if there's any difference in running displayserver with Winamp (or WMPlayer) from a W2k machine and from a W98SE machine?

The reason I ask is that I followed the 'Picker/Displayserver for Dummies' and the picker works boffo. At home (W98) the streaming to winamp (latest ver) works flawlessly (as it did when I had the 1.01 & displayserver installed), while at work the music will play for a while, quits, then sometimes come back by itself, sometimes needs emplode to touch the empeg & sometimes needs a cold boot to bring it back up. The front display works fine the whole time (although it's usually off/sleeping). I've tried two different network wall jacks (and wires) so I've ruled out cabling.

When emplode won't connect to the empeg (the cold boot condition) I get the error message 'unable to connect to your empeg (error 0xx)'. It's funny because it sees the IP address as an empeg, but then refuses to connect.

Thoughts?

A very confused,
-Zeke



just say you weren't paying much attention...

Your description of the problem confused me a little bit. Let me see if I understand it...

You're streaming songs from Displayserver across the network into WinAmp on your PC. At home it works fine, but at work, the data stream sometimes locks up, requiring a cold boot of the empeg before any TCP communication (either Emplode or Displayserver) will work properly again? Is that the problem?

First of all, how sure are you that it works OK at home but not at work? I seem to remember Frank saying that displayserver (in its current version) might have a memory leak. If it's sending songs across the network, it might take large quantities before you noticed a problem. Maybe you don't listen to enough songs at home to make it happen? I don't usually stream from displayserver, but I'm trying it now using Win2k and Winamp on my work computer and it's going OK so far.

If you're sure it only happens at work, my first shot-in-the-dark guess is that it would be somehow related to the increased traffic on your work LAN. Displayserver and/or the empeg's TCP software might be responding to more requests on your work LAN than they would on your home LAN. As I understand the way these thing works, even if the requests weren't intended for the empeg, its software still has to process them in a limited way. Perhaps Displayserver can't handle that on a busy lan with a lot of broadcast tracffic? Frank, do you have any insights?

In any case, the differences between win98 and win2000 shouldn't have anything to do with it, assuming I understand the problem correctly.

___________
Tony Fabris

Hmm. If I screw around enough (open and close playlists, start downloads and cancel them, open and close the java applet, etc.), I can make Displayserver quit responding. But emplode still works over TCP/IP. We could still be looking at the same problem, though.

___________
Tony Fabris

If you're sure it only happens at work, my first shot-in-the-dark guess is that it would be somehow related to the increased traffic on your work LAN. Displayserver and/or the empeg's TCP software might be responding to more requests on your work LAN than they would on your home LAN. As I understand the way these thing works, even if the requests weren't intended for the empeg, its software still has to process them in a limited way. Perhaps Displayserver can't handle that on a busy lan with a lot of broadcast tracffic? Frank, do you have any insights?

You are right in the way that the software(IP-stack) will filter all broadcast traffic for processing, but if the destination port is not responding, no real processing takes place. I've run about 10 copies of empegapplet at the same time, on the busy company-network, without any problems. Maybe a high collision-rate could cause the problems?
Another cause which is costing trouble-shooters a lot of time lately, is the use of intruder-detection software or HTTP virus-scanners. I've seen problems where such a program was causing failing drive-mounts ( blackice ). I spent a lot of time figuring that one out. Blackice bad, very bad... If you want some code to get a good laugh from blackice-users, mail me

I don't know if winamp uses the general proxy-settings, I know mediaplayer does. Have you checked the proxy settings?
As for the cold boot thing: I guess the company you work for has a switched network with multiple VLANs defined. In combination with DHCP, this can cause some time to happen to let switches "learn" MAC-addresses and let them spread this knowledge between all switches.

Frank van Gestel

Frank, Tony,
Answering questions as they were posed:

1. The displayserver/empeg does not always require a cold boot, only sometimes. I'd put the failure percentages as spontaneous reconnect after a few minutes: 65%, emplode connects to empeg and displayserver starts again: 20%, cold boot required:15%.

I am not DEAD certain about the home/work thing. I do listen much more at work, but I ran it for about 45 minutes at home with no problem (I usually just listen to the source library on my hard drives).

Traffic & Topologies: Home traffic is virtually Nil. Home topology is two PC's. Mine is a dual home w/the cable modem (am running Black Ice but the internal adresses are excepted from its rules) and the empeg is on the 10/100 hub along with the PC's. Work topology is an unsegmented, unswitched LAN with two logical repeaters (god**n 3com stopped selling a superstack II that uplinked to the two I already had so I had to use the 100bT uplink port to a Linksys box). Network collision rates are low, there's about 12-15 pc's active at any time doing mostly database accesses. Network saturation usually less than 20%. The internet traffic is low as we've only got two lines from our T-1 for data. All the machines except the servers, printers & T1 router are DHCP clients and part of the Active Directory. There's two AD domain controllers.

My workstation does run Internet and Download filtering (McCaffee VirusScan latest version & DAT). I've turned these filters off with no change to the spontaneous quitting.

Both Winamp an Media player have the same behavior with displayserver.

I use empeg only with static IP's. When I move between my home and work I use the USB to change the IP address for the location I'm at. At work I've set the empeg to an address that's outside my DHCP scopes (I've got two DHCP servers-both W2K with non-overlapping scopes within the same subnet, cheap redundancy).

Another detail which may have no bearing whatsoever: my last incarnation of displayserver did not use the -noauth parameter, so I edited all my playists to be http://ttt:[email protected]/ so winamp could work (mediaplayer was smart enough to ask for the login, winamp just failed without this tweak).

All proxy settins for both winamp and WM were left at the defaults.

When I look at the system page in displayserver I see for or five threads for displayserver when I'm the only one using it. Is this correct? There also appears to be very little (~250k) free memory. I've got about 1.5GB left free on the empeg drive if that makes any difference.

Still baffled. A memory leak seems an interesting possibility as the severity of it could account for the three different failure modes, but I'm not a programmer.

I hope some of this might be helpful.

-Zeke

just say you weren't paying much attention...

Have you seen any errors on the serial port through hyperterminal? You may need to bounce the eth0 interface. I had trouble where it would give strange behavior (along with the "neighbor table overflow" error), but I have been using ifconfig to set the ethernet port down and up, then running displayserver, and it seemed to fix the situation. I don't know if it could be a related problem, but it might be worth a try...



Paul G.
SN# 090000587 (40GB Green)

Paul,
Did it fix the problem for good, or do you have to do this every time you use displayserver? I didn't see any errors when updating to 1.02/picker/displayserver. Other than those sorts of things, I don't use Hyperterminal much. I'm fairly new to Linux and did use ifconfig to set up my test linux box at work, but haven't used it with empeg. I assume by bounce you mean turn off & turn back on the eth0 adapter on the empeg?

-Z

just say you weren't paying much attention...

Greetings!

I don't have picker installed, and I normally launch displayserver manually. I have not modified the original init files, so I need to do this command each hard boot on the network. At one point I tried the displayserver init file, but that was before multidisk support and (after the first aid was convinced that I had not had a major heart attack) I removed / restored the original configuration...

Before I started doing this, I would get lockups on the ethernet port and errors on the serial port for "neighbor table overflow". Some of the other documentation on the board suggested setting the ethernet port to down, then up (basically taking it off line then on line). This is (theoretically, I don't know enough to be certain) because the loopback connector needed to be configured / installed first, and it wasn't by default.

So, when I get to the office, I go into the empeg, run the commands:

cd /usr/local/d* (I am a lazy typer)
ifconfig eth0 down
ifconfig eth0 up
./displayserver noauth

Since I have been doing that, I am having much more stable results from the ethernet port. I no longer see those errors.

I don't know if the problem I had is causing or is related to your issue. It can't hurt to look though. My first recommendation is to hook up hyperterminal at work, and just watch for any errors. That will be a good step. Also, you might as well grab the debian distribution from here. You do not need to load the entire distribution, just unzip it and grab the files you need. I took netstat, ifconfig and a few other small goodies. Whatever the network problem, these will be useful in diagnosing and repairing it, but are not part of the standard developer load.

I hope this helps...

Paul G.
SN# 090000587 (40GB Green)

Paul,
I'll give it a look w/hyperterm Monday AM. I've even got an extra serial cable since for some reason they sent me three (maybe for just such an occasion!). If your steps help I'm going to try and put them in as one of the picker options.

-Zeke

just say you weren't paying much attention...

Here at work with the following updates:

Hyperterminal doesn't show anything when the displayserver stops responding.

Empeg initialized with the following output to Hyperterm:
Adding Swap: 16596k swap-space (priority -1)
e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
ext2fs_check_if_mount: No such file or directory while determining whether /dev/
hda4 is mounted.

--- Running Picker... ---

The fourth option was chosen.
Vol-adj is on.

--- Picker Complete. ---

Press q now to terminate to a shell prompt.

Running Player...
Using non-standard cache size 168 (adjustment 12)
empeg-car 1.02.

I also noticed that the empeg's drive is active while Winamp is trying to connect to song after song. Perhaps Winamp is not patient enough while waiting for the stream?

I haven't observed any hard locks ups this afternoon. The delay between songs (sometimes a song quits mid-way) and the displayserver coming back is between 20 seconds and 2 minutes.

I've attached my system stats from displayserver. This snapshot was taken with Winamp streaming and my browser as the only connections to the empeg.

Does anyone know which 'input' Winamp 2.73 uses? I tried adjusting the caching in the in_mp3.dll module but it had no aparent effect.

Any ideas?

-Zeke

just say you weren't paying much attention...

The "No such file or directory while determining whether /dev/hda4 is mounted" is normal, since you only have one disk drive.

I don't get the cache message on my system. Perhaps that's related? Isn't CONFIG.INI the file that controls the cache? Anyone?

And I don't think the caching in Winamp has anything to do with it.

___________
Tony Fabris

I think I remember seeing notes about setting the ds cache somewhere in the install docs. I'll poke around those and see what I see. I didn't fiddle with them to start with. What do you think Frank, worth a shot?

-Zeke

just say you weren't paying much attention...

everything looks pretty normal to me.
The process-list is showing the following displayserver processes :
1 X state R : the process generating the process-list
1 X state Z : zombie process that gets removed when applet is killed
3 X state S : one process to serve the applet-data, one process to send ir-codes and one process to accept new socket-connections.

If I were you I would start sniffing the net...
BTW, can you ping the empeg when the interruption occurs?

Frank van Gestel

Frank,
I can ping when it's interrupted. I also just noticed that the PID's are incremented when it comes back. For example just now it went from 83 & 84 (R & S respectively, 80 was zombied) before the pause to 89, 90 & 91 (S, R, S respectively) after.
-Z

just say you weren't paying much attention...

It's worth a try, though lowering or deleting the value will leave less memory for displayserver.
For normal use the default isn't a problem. If you've got a lot of clients streamin MP3's of your empeg and opening applets, it gets more important to have enough memory available...

Frank van Gestel

I also just noticed that the PID's are incremented when it comes back

That's normal too. Actually it's not normal, but it was the fastest and easiest way to setup a TCP-server. It's one of the reasons to rewrite the whole thing.
It goes like this :
- process A waits for connection
- new connection - fork - process B is created
- process A handles request
- process B waits for connection
and so on...

Another thing you can try :
try telnetting to port 80 and type : "GET /"
followed by two newlines
it should give you back the index-page...

Frank van Gestel

What do you think, more or less cache?

-Zeke

just say you weren't paying much attention...

What do you think, more or less cache?

Well, If you want to be sure, start out with a reducecache of 64, the empeg will read the disk more often, but you will have plenty of memory for diplayserver.

I've run with 32,48 ad 64, without any problems. Right now I haven't got a reducecache parameter set, which allows me to download three songs simultaneously. I'm not fast enough to download the fourth...

Frank van Gestel

Thanks. I'll give that a shot in the morning.

-Zeke

just say you weren't paying much attention...

Frank,
There was no ReduceCache parameter set in the config.ini file. I added it and set it to 32 for starters. I beat on it some with three copies of IE and two Winamps and it took a while for one of the threads to lock up (the other kept going though & streaming music). I'll see how it goes tomorrow (I only get to fiddle at the end of the day) & let you know.

-Zeke


Just had it quit again while reading posts. Are these messages in Hyperterm usual?

exit
Running Player...
Using non-standard cache size 168 (adjustment 12)
empeg-car 1.02.
VM: killing process displayserver
VM: killing process displayserver
VM: killing process displayserver
VM: killing process displayserver
VM: killing process displayserver
VM: killing process displayserver
VM: killing process displayserver
VM: killing process displayserver
VM: killing process displayserver
VM: killing process displayserver
VM: killing process displayserver
VM: killing process displayserver

Edited by Ezekiel on 03/04/01 11:55 PM.

Displayserver has a memory leak in it which is causing this behavior. After a certain amount of activity, it locks up and shuts down.

Sean

Aaah so! This makes a lot of sense now. Did I miss a thread somewhere?

-Z

just say you weren't paying much attention...

There was a thread where I was trying to back up my empeg using httrack. It would get 1/3 of the way done with all the mp3s then it would crash. I would just reboot the empeg and keep going. I finally got most of them copied back.

Sean

Sean,
I read that thread, but this problem is different. I can listen to maybe 3-4 songs max before it craps out, no where near the 4 GB limit mentioned. I'm not loading it up with a lot of connections either. I am getting pretty frustrated though! I've used no, 16, 32 and 64 for the cache with no appreciable change is performance.

I have noticed one very strange item. When connecting one time via emplode my empeg came up as empeg-car for the COM entry and RAGE (the name of my empeg) for the tcpip entry. The COM port has inexplicably stopped responding to emplode or Hyperterm even after rebooting the empeg a few times (I've triple checked the settings in both the control panel and in Hyperterm). I'll try a cold boot of my workstation later, but it takes a while so I don't want to do it now.

I'm running out of ideas.

-Zeke

just say you weren't paying much attention...

I don't know what the problem can be. I think network settings were already discussed in this thread, but is your network at work very saturated with traffic?

Sean

There was no ReduceCache parameter set in the config.ini file


Using non-standard cache size 168 (adjustment 12)

this would suggest you had it set to 12

You should see the value you set in the ini file in the boot messages...

look here for a description of the reducecache parameter

the "VM: killing process" message does indicate there is a memory shortage. Since the player app runs realtime and has it's memory locked, other processes are killed when memory runs sparse...
One thing which should give you exclusion about a memory shortage, is connecting the player to serial, open a terminal-session and stop the player-app.
Displayserver will run with allmost all of the memory available...

Frank van Gestel

Sean - it happens even when everyone's gone home for the night, so I don't think saturation is the problem.

Frank - my 'ReserveCache' is set to 12 (as I found it). I had mistakenly set this to 32 with bad results. I've got 'ReduceCache' set to 16 at the moment (and ReserveCache back to 12). I've attached my config.ini file, which I've been editing with UltraEdit to avoid the end of line problems pointed out. Three songs seems to be about the limit.

The config.ini file I'm editing resides in the /empeg/var directory which I believe is the right place. I use Hyperterm and do the following: cd to the /empeg/var, rw, rwm, cp config.ini config.old, rz the edited config.ini file, ro, rom, exit, reboot power. Please let me know if this is not right. I'm using Displayserver 1.1 dated Feb.16.

I'll try it with the player quit and see how that goes.

-Zeke


just say you weren't paying much attention...

Frank,
It still cuts out with the player quit (at the bash prompt in HT). Attached is a system shot just after it came back from a hang. The free memory is still very small, which is puzzling as the player's not running. I see that the cache is upwards of 8MB. Is this as it should be?

Meanwhile I'll keep it running with the player quit to see if there's any improvement in the hang frequency.

-Zeke

just say you weren't paying much attention...

this gets me thinking: Is there a difference between reducecache and reservecache?
I've got reducecache from the developers-site and reservecache from Mike's post...
Anyone?

Frank van Gestel

The free memory is still very small, which is puzzling as the player's not running.

This is pretty normal, linux allocates memory for the filesystem-cache dynamically; as much as possible. If a request for a memory-page comes in, the filesystem-cache just reduces in size.

If the problem still only arises on the company-network, I think there is something wrong at a lower layer... You stated before that emplode was also unable to connect during a hang, is this still the case?

BTW, have you tried using the IP-address of the empeg instead of the hostname; perhaps DNS-problems...

Frank van Gestel