DVDWS - crashing/closing during menu encoding (solution)

[gregat99]

Hey Folks,

I'm new to this forum, but not to DVD Workshop. I've been using it for quite a while, and recently I undertook a large project that required about 80 or so menus with text on them (a DVD based course calendar for a school). Anyways, I found for a while that whenever I tried to burn the project, it would arbitrarily close or crash (causing an error in u32base.dll). I searched the web and these forums for a solution, and found none as to why it would crash during the menu encoding process.

I'm running this on a decent machine too, P4 3ghz with a gig of ram. WinXP, SP2, Radeon 9800, no other open processes during encoding. I guess it's not enough!

For those of you who have run into this problem as well, and are losing their minds envisioning missing a deadline, here's a quick fix to get your project on to a cd.

1) Get your project ready to burn. Save it.

2) Delete half of the menu items you have (or however many is necessary
to keep your computer from generating a program error)

3) After you've deleted them, go to Finish, Burn, and create an ISO file.

4) After the ISO file is completed, go back to the Menu. Hit ctrl-Z to undo your deleting of half the menu items (if this doesn't work, you can re-open your project). **

5) Go back to Finish, and burn the exact same ISO file. DVD workshop will not re-encode menu files inside of the ISO that have already been encoded, therefore your computer wont get bogged down the same, causing a fault in u32base.dll (or causing it to just...close).

6) Burn the ISO file after it's completed. Dance and rejoice.

** when you delete files, DVD workshop automatically updates playlist linking on other menus. Make sure to reopen any menus that you burned in step 3 to check that the linking is correct again. Re-opening them will make DVD Workshop think that there was a change to them, and they will be reburnt.

Is this a roundabout and somewhat redundant way of burning the project? Yes. Did it save my butt and keep me from missing a deadline? Yes. This error in u32base.dll where the computer can't encode all of the menu items isn't limited to just my machine as well, and it has nothing to do with me missing any updates. I'm slightly disappointed in this software, but hey, whatever works.

If anyone has a different solution to this known problem, please reply. I hope that this is helpful - I would have killed to know this a few days ago - I would have gotten a lot more sleep!

Regards,

-Greg

p.s- dear Ulead programmers. S-t-r-e-s-s t-e-s-t. you may want to patch this little fault, or make the updated version of u32base.dll (ver.3) compatable with DVD Workshop. please and thank you.

[Devil]

Interesting. I've never had the problem as I'm not a big menu fan (I think the largest I've done is 16 chapters). The implication of your post is that large menus are resource hogs during encoding. That being so, I'd guess that special menu effects would acerbate the problem, so it would probably be sound advice to keep large menu systems as simple as possible.

On reflection, it stands to reason. If, for example, in MSP, you have 6 still P-in-Ps on a still background, the instant playback would have trouble working (red-lined) and rendering would take quite some time. In a WS menu, it is a lot more complicated than that, with text, frames, playlist, music etc. on top. If I remember correctly (not 100% sure), WS2 is said to be limited to 99 menu items, but I think this is a theoretical limit without reference to the performance.

It would be interesting to find out why this limitation exists. Thanks for bringing it to our attention.

MODERATOR Please make this thread sticky

[rwport1973]

Just a testimonial that this workaround is functional!

I had tried patching DVDWS and tweaking my machine as per instructions, but nothing worked. When I followed the instructions for deleting scenes, burning the .iso, readding scenes and reburning, everything thing turned out like it should have to begin with. I did need to reburn a second time because I lost a few pictures (my project consists of slideshows only).

I am disappointed that the product seems to be buggy, but your suggestion forestalled my asking for my money back!

[Devil]

I am disappointed that the product seems to be buggy, but your suggestion forestalled my asking for my money back!

It may be premature to consider the product buggy. The limitation may well be insufficient available hardware resources for extreme menu systems. As an ex-programmer, I would say that if something works with small files and doesn't with large ones, all other things being equal, then the problem is probably hardware, assuming there are no operating system limitations. In the case in point, the programmers have set an artificial limit (I think 99, but am not sure offhand), so they are aware that there is a problem with large numbers. It is not reasonable to expect them to set the limit to correspond with the minimal hardware config, so they probably set it for the highest state-of-the-art config. Where perhaps they have made an error is that they haven't set a trap to put up an explanation why you have the problem.