Runtime error 35601 - Element not found?

Healey

New member
Ok,

I know it must be something simple, but........

There were references to this error in other threads that it would occur when you are trying to load a project file if one of the directory pointers /locations of ifoedit, etc had changed.... but, if I go back & try to load a previously saved project (eg: I've just finished working on dvd "a", and want to load dvd "b" or "c"'s project to do more work on), I get this error without fail, and nothing has changed!
If I bring up DS initially, it appears to load the prior project's info (ie, if I click Next, without an additional rip, I can see all the titles / menus)
I see that when I try to load a previous project it will change the source drive to what it was for that project (which still exists & has the same image loaded), but DS appears to throw this error just before it completes loading the project....
Knowing that some of the information is stored in the registry, I've even gone so far as to delete the DVDStripper key, so that there are no remnants of information, but alas.... :(

Any / all ideas are welcome...

Thanks in advance!
 
I can't really help Healey :(

@TMG, maybe the project should just save the Temp and Destination folder location and the setting for every item

you could reload that project and if the destination folder is invalid then it will ask for you to specify a new one. Obviously it will check that the Temp folder is valid and that the items are exactly the same

I would think that should eliminate most errors as long as the original Temp folder and files have not been modified in any way at all
 

Healey

New member
MackemX said:
I can't really help Healey :(

@TMG, maybe the project should just save the Temp and Destination folder location and the setting for every item

you could reload that project and if the destination folder is invalid then it will ask for you to specify a new one. Obviously it will check that the Temp folder is valid and that the items are exactly the same

I would think that should eliminate most errors as long as the original Temp folder and files have not been modified in any way at all
Thanks for the reply MackemX .....
So, if I understand your note to TMG, DS checks the contents of the Temp folder for the originally DVD Decrypted files from dvd "a", against the saved project file. But, because these files have been actually been overwritten with the new files from dvd "b" when I run DS, I would need to back up my Temp folder when it had the dvd "a" content, and then copy all the contents back in when I go back to work on dvd "a"...correct? That would also explain why I get the Element not found error, as it cannot find the files associated with the previous project in Temp...correct #2?

Thanks for your help! :)
 
Healey said:
Thanks for the reply MackemX .....
So, if I understand your note to TMG, DS checks the contents of the Temp folder for the originally DVD Decrypted files from dvd "a", against the saved project file. But, because these files have been actually been overwritten with the new files from dvd "b" when I run DS, I would need to back up my Temp folder when it had the dvd "a" content, and then copy all the contents back in when I go back to work on dvd "a"...correct? That would also explain why I get the Element not found error, as it cannot find the files associated with the previous project in Temp...correct #2?

Thanks for your help! :)
Hi Healey!

yes, this is correct, obviously DVDStripper can only process data that is available on the harddisk, it would be a bit much saving all the dvd content in the project files :D So only some info is stored in the projects, like the paths used, filenames, sizes, your selection and stuff like that. So if you use the same temp paths (and backup paths) for your different projects the actual data gets overwriten, rendering older profiles useless, unless you rerip the dvd you made this profile for.

But the easiest solution is to use different paths for each dvd you are going to process if you plan to do more then one dvd and want to return to them at a later point in time.

And you are also correct that the runtime error is caused because DVDStripper tries to access items that are no longer available in the set paths when you have used them for another dvd already. Sadly there is no simple solution to avoid this from within DVDStripper, so it will stay up to you, the user, to take care that the files used for the project are still valid. Sorry for the inconvenience.

Greetnx
 
Solution!

I found an answer to the problem - so, if you just want the solution, skip to the last paragraph.
______________________
Unfortunately, this error happens even when the directories have not been modified, moved, changed, or another DVD worked on in the interim.

Example: While working on a current DVD, I closed the program out after saving my project for the second time. When I went back to reload the project I got the infamous Runtime error 35601. Some background may be due:

OS: Win XP Pro SP1
Hardware: 2 x AMD 2400 MP, 1024 MB RAM
Directories:
DVDStripper exe: C: drive
Temporary Path: G:\DVD\DVDStrip_Temp\
Dest. path: F:\Backup\DVD Backup\DVDStrip_Dest\
Backup Path: G:\DVD\DVDStrip_Backup\
(All three are separate physical hard drives)

When I saved the project file (*.prj) to my F:\Backup\DVD Backup the FIRST time (i.e. the .prj file did not exist) I was able to reload the project. When I made a subsequent save using the SAME file name, the trouble began. When I attempted to reload the file after saving the project the second time, I got the error.

I went back and started over, this time saving the project file in two separate locations. What I found, through trial and error was that as long as I saved the project in a new location, or with a new name, I was fine. In other words, I could not resave a project. Once I saved the project and reloaded, I could not save the project to the SAME file - I had to create a new file, and then I could reload.

I could delete the project file I had just opened, and then reuse the name and it would work fine too.

!!!! Bottom line: If when you go to save, DVDStripper asks "*.prj already exists. Do you want to replace it?" ANSWER NO!! :) And either delete that old file and save, or just save to a new file. Then you'll be fine. This is key if you have it set to save project before processing, and you've already saved the project while working on it. Because whenyou click on yes to save the project before processing, if you overwrite that save file, you're screwed if you have to reload.
 
timekills said:
I found an answer to the problem
Hi!

good work debugging there....
though this shouldnt happen, it obviously does... guess i was just lucky when testing that this never happened to me....

anyways, THIS is a bug, opposite to when contents have been changed. So i will fix it in the next update of DVDStripper.

Thnx for reporting timekills!

Greetnx
 

pak2

New member
Reference the "Run-time error '35601'" bug.

TMG indicated he will fix this bug, but in the meantime here is a little more information. I save work as I go and this bug stung me repeatedly until I investigated it. The bug is isolated to a particular operation. The error occurs when you make a change to "Keep" (restore) a previously "Removed" item on either of the "Item" lists in DS, and then save the new project configuration back over the existing project file name. At that point you can no longer load that project file. You don't have to close DS to encounter this, nor request "Process". If you re-save the project a few times as you work during a single session in DS, and you have restored items between saves, you will find you can't reload the project file even if you haven't closed DS.

Note that the same error does not occur if you only "Remove" items and then re-save the project to the same file name (?). The error does not occur if you simply change button properties of menu items, save the new menu VOB files, and then re-save to the same the project name. While interesting, my short-term memory isn't good enough to utilize these nuances.

A variation of this is to accidently save over an unrelated project using the same name --> you double the yield of the explosion --> obviously, you lose the other project, but the bug causes you to lose the current project as well !!

So "timekills" has it right. The safe procedure is to never re-save over the top of an existing project file.
 
Top