If people are getting errors in overlapped I/O, doesn't this imply a resource problem in w98?

How much physical memory is installed on the boxes of people experiencing problems? Anyone care to comment?

The sync error being discussed in this thread has nothing much to do with what you do, whether you modify playlists or upload tunes or whatever. As far as I can tell it is only to do with:

1. Running Windows 98SE.
2. Doing a reasonably long synchronise (at least once in a Windows session).

I believe the problem is due to power management changes in 98SE. I've got a version of emplode that reduces the number of times the error happens but doesn't actually completely eliminate it. If you want to try it it's available at http://www2.empeg.com/upgrades/test/interim/private/emplode-0.84.2.zip.

If this doesn't help then try turning off every single power management feature you can find.

I've been investigating the USB driver to find out exactly what needs to be changed but I haven't found anything conclusive yet.

--
Mike Crowe
I may not be speaking on behalf of empeg above :-)

my Win98 box has 160Mb in it so shouldn't be causing a problem.

I've not yet had a chance to try any of the suggestions you've all given - hopefully at the weekend.

Phil

resource problem in w98?

I have 192MB and a large swapfile. So space shouldn't be causing the problems. Last time synching fell over it generated a 0xfffffff3 in stage 5. Then Windows crashed (blue screen) with and error at 0028:FF009611 (if I read my notes right); insufficient resources. Does this help?




Henno
# 00120

Then Windows crashed (blue screen) with and error at 0028:FF009611 (if I read my notes right); insufficient resources.

Ah, this is interesting.

In Windows, most people mistake the word "Resources" to mean "Disk Space and/or RAM". That's not always the case.

In Windows, the term "Free System Resources" refers to the amount of free heap space in (if I remember correctly) USER.EXE and GDI.EXE. Certain windows functions would store pointers in this space. If you ran out of space here (which wasn't much, only 256k or so if I recall), then software would start to crash left and right because all its USER and GDI function calls would start erroring out.

Under Windows 3.1, this used to be a really big problem-- it would run out of FSR's (as we called them) quite frequently. Any program that did GDI calls (such as creating a font or a brush to draw on the screen) could theoretically eat resources if it didn't close out that GDI handle properly. We used to use a "resource meter" utility to monitor our app's usage of FSR's and locate leaks.

In Win 95 and beyond, supposedly they altered the way Windows allocates these resources and I thought they had solved the problem. Although perhaps not. I haven't had to deal with this issue in a long time, so I don't know if it's changed.

Empeg guys: Any thoughts on this?





-- Tony Fabris -- Empeg #144 --
Caution: Do not look into laser with remaining good eye.

Actually, the resource limitation problem is still there in Windows 95 and Windows 98 - the area was just enlarged (effectively). You need Windows NT to completely eradicate it.

I don't believe that emplode is leaking resources. It hardly uses any in the first place! The ones it does use exist for the entire program lifetime.

Did anyone have any luck with the newer version of emplode I mentioned?

--
Mike Crowe
I may not be speaking on behalf of empeg above :-)

Did anyone have any luck with the newer version of emplode I mentioned?

This may not be related to the original thread subject, but I'm still getting sync errors in stage 5, error 0xfffffff3 with the latest emplode you posted the link to. Though, I've been doing something else in the background also - sometimes running MS Visual C++ will make that happen. But back at home I used to get the same sync error even when I left it to sync while I went to sleep. (With no background programs running)

Can you tell what this specific sync error means?

- Kim

This may not be related to the original thread subject, but I'm still getting sync errors in stage 5, error 0xfffffff3 with the latest emplode you posted the link to. Though, I've been doing something else in the background also - sometimes running MS Visual C++ will make that happen. But back at home I used to get the same sync error even when I left it to sync while I went to sleep. (With no background programs running)

Can you tell what this specific sync error means?

It means that the player has run out of memory (RAM, not disk) which is odd. Try this update and see if it helps:
http://www2.empeg.com/upgrades/test/interim/private/developer-beta9c+.upgrade



--
Mike Crowe
I may not be speaking on behalf of empeg above :-)

It means that the player has run out of memory (RAM, not disk) which is odd. Try this update and see if it helps:
http://www2.empeg.com/upgrades/test/interim/private/developer-beta9c+.upgrade

This version seems to work better - I've uploaded couple of CD's to my empeg without that particular sync error. Once I got some other sync error though, but I recall loading some other program in background at that time, so no worries about that.

When a sync error happens, the most annoying thing is not that the sync aborted, but the fact that it usually puts all synced files to "Unattached items" folder. Maybe it could try to assign tunes to playlist after each file is uploaded. Also as an wishlist item, the sync dialog could have a Cancel button :)

Kim

For the first time I attached my empeg to a 98 machine, and got the above error in almost all stages from 1-5. I tried the new emplode, killed off all unneccessary processes, and still had the error when trying to transfer more then 25-50 megs. Finally I stopped the process, and went back to 2000 where I can sync gigs of songs and still use the computer. Something is definitly wrong on the 98 side, as the system was real sluggish while emplode was doing something. Problem is, is it the fault of Microsoft with the USB drivers or with emplode?

My empeg site is:http://24.236.3.131/empeg/

You didn't say whether it was 98 or 98SE. That might be important?

Tony Fabris
Empeg #144

Something is definitly wrong on the 98 side, as the system was real sluggish while emplode was doing something

Could you check how W2000 handles memory during a synch? During a synch I saw unused physical memory steadily decrease from 29MB to a mere 4,096 whole bytes, in just a dozen MP3s. Then W98 made a faint attempt at recovery, freeing up to 16k. When it was down to 4k, I expected synch to fall over anytime, but it didn't ; it transfered the 13 MP3s succesfully.

Henno
# 00120 6GB now, working on an extra 18!

That "free physical RAM" thing has already been investigated by the Empeg folks. I reported it a while ago when I thought it might be a leak in Emplode or its USB driver.

I'm now pretty sure that it's no big deal. There are plenty of other software programs that produce the same apparrent behavior. I think we're just seeing the Windows disk cache filling up, and there's no impact on software performance as far as I can tell. Windows dynamically trades memory between the disk cache, RAM, apps, and the swap file, and for the most part it Does The Right Thing.

I could be wrong, of course. But Mike's pretty sure that Emplode isn't eating Windows RAM because he's specifically tested that.

If you're interested in keeping that RAM free, use Memturbo to keep it clean. I have had Memturbo running during synchs, and even when it's actively defragmenting and recovering RAM, the synchs are not affected and continue to work just fine.


Tony Fabris
Empeg #144

Mike's pretty sure that Emplode isn't eating Windows RAM
I think I remember that conversation, and agree: I take Mike's word on this. But keep in mind that W2000 is claimed to be capable of completing a sizeable synch without crashing ! Hence my curiosity if W2000 manages RAM just as tight as W98 does. It's probably a wild guess, but I've not been able to do more than 20MB of synchs without a crash lately, and haven't seriously considered upgrading to W2000, but if it saves emplode from crashing I may look into it.

If you're interested in keeping that RAM free, use Memturbo to keep it clean
have had Memturbo running during synchs, and even when it's actively defragmenting and recovering RAM, the synchs are not affected
I'll try it. I'll let you know if it helps keeping my emplode from falling over.

Final remark: didn't someone suggest that it wasn't emplode that ran out-of-memory, but the player itself??

Henno
# 00120

Final remark: didn't someone suggest that it wasn't emplode that ran out-of-memory, but the player itself?

Right, but that's a completely different and unrelated issue from the Windows memory. I was specifically responding to your comment in your last post about Windows' "unused physical memory" slowly decreasing.

As far as NT's memory management:

In my overall experience, Windows NT has always had better memory management than 95/98. (Keep in mind that Windows 2000 is just a fancy name for Windows NT 5.0.) Everything is more stable under NT. Errant applications don't bring down the whole system like they do in 95/98. An example: I use NT as my main workstation at work, and I do lots of different things in many windows simultaneously. When one application crashes, I simply shut it down and continue working in the other windows. And the work is mission-critical stuff, too: compiling final software builds, moving huge files around our network, managing network user accounts, etc. I never worry about it, and I've never had a problem where one app has corrupted another app's data or files.

I trust NT much more than the Win98 I run at home. The only reason I run 98 at home is because certain games won't work under NT. After Win2K goes through a couple of service packs, I plan to test all my games on it and see if it's a viable upgrade for my home computer.


Tony Fabris
Empeg #144

In my overall experience, Windows NT has always had better memory management than 95/98. (Keep in mind that Windows 2000 is just a fancy name for Windows NT 5.0.) Everything is more stable under NT. Errant applications don't bring down the whole system like they do in 95/98. An example: I use NT as my main workstation at work, and I do lots of different things in many windows simultaneously. When one application crashes, I simply shut it down and continue working in the other windows. And the work is mission-critical stuff, too: compiling final software builds, moving huge files around our network, managing network user accounts, etc. I never worry about it, and I've never had a problem where one app has corrupted another app's data or files.

---

out of curiosity, are you running W2000 rc2 or W2000 final? I've had more crashes then I care to remember since upgrading to the final version of w2000; w2000 rc2 was SOO much more stable for me which is wierd, as nothing else has changed... The only thing I can attribute it to is directx7 support which was broken in the beta, but supposedly complete (hence breaking my machine) in the full release... (during many crashes, ctrl-alt-delete simply refuses to bring up the task manager...)
-mark

...proud to have one of the first Mark I units

out of curiosity, are you running W2000 rc2 or W2000 final?

Well, for my main work machine, it's NT4 service pack 6. I've only tried RC2 of Win2k so far, but not in a long-term usage environment.

Interesting to hear about your problems with the RTM version. Like I said, I'll wait through a couple of service packs before fully commiting to it. As much as I praise NT, I still prefer to let the rest of the world beta-test the release version for a while first. :-)

Your problem with Ctrl-alt-del not bringing up the Task Manager is interesting. In NT4, I have literally never had that problem. Then again, since I can't run any DirectX games under NT4, I've never been in a situation where the screen is completely locked up by an app. I guess that's probably what's happened to you: A directX game locks up, and although you can get the task manager to come up, you can't see it because the screen is grabbed by DirectX. That's been a problem under 95/98 for a long time. The addition of DirectX to NT5 just brings the problem right along with it.



Tony Fabris
Empeg #144

Last night I synced a total of 5 gigs across two sessions. The first was while I was actively using the computer, and the second while I slept. The computer stayed responsive at all times. All the files were coming off the network, and unlike 98 SE, didn't cause any problem for the sync process. Checking task manager, emplode stayed under 10% cpu usage, and about 4 megs of memory usage.

Also, Windows 2000 is the official name for the product. It was NT 5, (I still have the developer release around here somewhere), but MS decided to change it to 2000 to fall in line with a goal of a unified Windows for consumers and businesses, then about two weeks after the name change, MS said it's for business only. I'm guessing it's due to the problems showing up in beta with more consumer type programs and devices. After that though, the programers did a good job of supporting consumer things. They even are releasing an update a month to add complete support for more consumer programs. For February, it's a games update, insuring that they work as they do in 98. (I'm happy as I own several of the games in the update).

Honestly, I think 2000 is perfectly suited for consumers. I've ran it since the pre beta days (But not much as I found way too many show stopper bugs), and ever since Beta 3, it really started to show it's self as an organized mess that works. In the RC stages, things stabilized (No more hunting down that admin tool anymore that didn't make it into the MMC yet), and at that point it was unlike the 9x RC's. The RC's I have seen for 95 and 98 were downright ugly. 2000's RC process was quick, and ensured things worked well. RC2 was the first time I used 2000 as my primary OS, and I have no plans on changing that now. I guess something good does come out of throwing decent programmers at a project for a few years. And keep in mind that services packs 4-6 for NT 4 all exist because of the development team for 2000 fixing problems and backporting fixes.

Sorry to go on about something mostly non-empeg related, but I have a feeling my notes will influence people on the boards to look at upgrading to 2000. And for the time being, it will mean more reliable syncs to the empeg as well for those experiencing problems in 98 SE.

My empeg site is:http://24.236.3.131/empeg/

Checking task manager, emplode stayed under 10% cpu usage, and about 4 megs of memory usage

Do you have a way of monitoring free physical RAM during a long USB synch operation on Win2k? I'm curious if the same thing happens to you as it does for me... the gradual decrease of free physical RAM.

Also, Windows 2000 is the official name for the product. It was NT 5...

WHATever!

I like to call it NT5 anyway, for several reasons:

1) I'm sick and frigging tired of all this "name-your-product-after-the-year" crap. Especially since everyone decided to start doing it in the same year. This is software, damnit, not cars. I say, bring back the real version numbers.

2) It's easier to type "NT5" than "Win2k".

3) It serves as a reminder that the operating system was, and still is, NT at heart, regardless what the box says. There's still a big difference between the NT core and the 95/98 core, and it's important to keep that difference in mind at all times.

Honestly, I think 2000 is perfectly suited for consumers.

Only after everyone weeds the old games out of their collections. There is still some older software (especially old DOS games) that flat-out won't run on the NT kernel. The only work-around for these folks is a dual-boot system. I have some of that software on my 98 system right now and I'm seriously thinking about just kissing it goodbye so that I can run a pure Win2k system when I decide I'm ready.

And keep in mind that services packs 4-6 for NT 4 all exist because of the development team for 2000 fixing problems and backporting fixes.

Good point. Sad, but true.

Glad to hear that synchs work so well in Win2k. Although such behavior seems to indicate that there's something going wrong in either: a) Win98, b) USB drivers under Win98, or c) Emplode. In any of those three cases, the Empeg folks need to locate the trouble and implement fixes or work-arounds before the Mark2's ship. Not an easy task under Windows- it's so hard to track down bugs in that OS because of how all the different pieces of the puzzle interact...



Tony Fabris
Empeg #144

Do you have a way of monitoring free physical RAM during a long USB synch operation on Win2k?

Taskmanager should be able to show this to me as well. I am currently clearing some space off the empeg to put other music on, and should be doing a gig sync here soon. I'll watch (and log) it to see what happens.

I like to call it NT5 anyway, for several reasons

I have to agree with these. Personally, I was wishing for NT 5 back before NT 4 SP3 came out. As far as naming computer programs, it has all gotten out of hand. You have the Solaris 2.6 -> 7 jump. Then theres the Linux version scheme, and MacOS. (8.3.4.2.3.4.5.5.4.4.8). And keep in mind that MS put "Built on NT technology" all over the place.

Only after everyone weeds the old games out of their collections.

I have a 166 system with my Voodoo 2 in the corner for all my old games. I tend to rack up enough old parts to do this every once in a while. As far as DOS compatibility goes, keep in mind 98 is the last MS OS to have it. Windows ME (Yet another horrible name) kills off (Or attempts to) all realmode DOS things. Installing the developer release (MS's worst name for Alpha) on a seperate partiton still made 98's DOS support start acting up.

Also keep in mind the average consumer out there dosen't have the old stack of programs. Most home computer users have bought their first computer just in the past two years, all to join this oh so wonderful internet revolution. (I'm glad we got beyond SLIP before the internet got popular. I'd go insane trying to support it)

My empeg site is:http://24.236.3.131/empeg/

Final remark: didn't someone suggest that it wasn't emplode that ran out-of-memory, but the player itself??

Hmmm.... I'm beginning to wonder if we are all looking at the wrong end of the link. Henno, didn't you mention recently that you were running to the end of your available disk space on the empeg?

Could we be seeing the result of a lack of swap/track storage space on the empeg, causing some failure at the empeg end (eg, the player can't rebuild a music database because of lack of space, thrashes trying to free something up. times out??), which then gives back a "completed I/O" response at the emplode end, which is either incorrectly reported or not reported at all?

It seems there has been a rash of people reporting this recently - I wonder if it's beacuse people are only now starting to completely fill their empeg disks, and it is tickling a number of bugs at both ends of the link?

Final remark: didn't someone suggest that it wasn't emplode that ran out-of-memory, but the player itself??

didn't you mention recently that you were running to the end of your available disk space on the empeg?

this thread is starting lo loads to slow that I start a new thread on this with subject 'Memory Errors?'
see there




Henno
# 00120

I was actually able to narrow down my w2k problems... (and w2k is just as easy to type as nt5, if not easier since w2k are easier to type:) )

Ever since upgrading to the full release, ONE PERTICULAR function that used to work crashes me, everytime.. It's the buttin in photoshop 5.5 which used to load up imageready and transfer the image to that application - clicking on it now freezes my computer, with no hope from ctrl-alt-delete... mouse cursor moves for a bit, but eventually locks up.

Wierd eh? I'm staying away from that button:) That's not all of my crashes though - just ™ of them.. I still think RC2 was more stable then the release...
-mark

...proud to have one of the first Mark I units

Hi all,

I'm actually running Win98SE (boo), and I'm seeing this exact error as well.

The reason that I'm posting is that it seems a bit random - not really anything to do with long load times. It crashed after one file!

Cheers,

Paul.


Paul Haigh, 6GB, Blue
Reg: 4120 - Serial 00254