Net Framework Unhandled Exception has returned

[jtcreate]

I've been getting this error popping up every once in...It looks like a conflict with accessing the folder. What do you think?

----> " The process cannot access the file 'C:\Users\Public\Recorded TV' because it is being used by another process."



Thanks

----------------------------------------------------------------------------------------------------------------------------
Error Log

See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.IO.IOException: The process cannot access the file 'C:\Users\Public\Recorded TV' because it is being used by another process.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.Directory.InternalGetFileDirectoryNames(String path, String userPathOriginal, String searchPattern, Boolean includeFiles, Boolean includeDirs, SearchOption searchOption)
at System.IO.Directory.GetFiles(String path, String searchPattern, SearchOption searchOption)
at System.IO.Directory.GetFiles(String path)
at VideoFileList.ClassVideoFileList.ScanMonitorDirectory(Boolean& fileSizeChanged)
at VideoReDoAutoProcessor.Form1.ScanMonitorDirectory(Boolean forceDisplay)
at VideoReDoAutoProcessor.Form1.ScanMonitorDirectory()
at VideoReDoAutoProcessor.Form1.ProcessingLoop()
at VideoReDoAutoProcessor.Form1.button1_Click(Object sender, EventArgs e)
at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Loaded Assemblies **************
mscorlib
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.8793 (QFE.050727-8700)

CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll

----------------------------------------
VideoReDoAutoProcessor
Assembly Version: 1.3.8.0
Win32 Version: 1.3.8.0

CodeBase: file:///C:/Program%20Files%20(x86)/VAP/VideoReDoAutoProcessor.exe

----------------------------------------
System.Windows.Forms
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.5491 (Win7SP1GDR.050727-5400)

CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll

----------------------------------------
System
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.8791 (QFE.050727-8700)

CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll

----------------------------------------
System.Drawing
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.5495 (Win7SP1GDR.050727-5400)

CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll

----------------------------------------
Interop.tivocomLib
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0

CodeBase: file:///C:/Program%20Files%20(x86)/VAP/Interop.tivocomLib.DLL

----------------------------------------
System.Data
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.8762 (QFE.050727-8700)

CodeBase: file:///C:/Windows/assembly/GAC_32/System.Data/2.0.0.0__b77a5c561934e089/System.Data.dll

----------------------------------------
System.Xml
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.8773 (QFE.050727-8700)

CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll

----------------------------------------
Microsoft.VisualBasic
Assembly Version: 8.0.0.0
Win32 Version: 8.0.50727.5483 (Win7SP1GDR.050727-5400)

CodeBase: file:///C:/Windows/assembly/GAC_MSIL/Microsoft.VisualBasic/8.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualBasic.dll

----------------------------------------
Toub.MediaCenter.Dvrms
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0

CodeBase: file:///C:/Program%20Files%20(x86)/VAP/Toub.MediaCenter.Dvrms.DLL

----------------------------------------
Newtonsoft.Json
Assembly Version: 4.5.0.0
Win32 Version: 5.0.6.16206

CodeBase: file:///C:/Program%20Files%20(x86)/VAP/Newtonsoft.Json.DLL

----------------------------------------
System.Configuration
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.5483 (Win7SP1GDR.050727-5400)

CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Configuration/2.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll

----------------------------------------
Accessibility
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.5483 (Win7SP1GDR.050727-5400)

CodeBase: file:///C:/Windows/assembly/GAC_MSIL/Accessibility/2.0.0.0__b03f5f7f11d50a3a/Accessibility.dll

----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.

 

[dlflannery]

Yes, whatever process is depositing videos on that folder is locking it, or perhaps a single file in it, so no other process (e.g. VAP) can access it. I'm assuming this is the folder you've configured as VAP's monitored folder, right? VAP needs to scan this folder every few seconds to detect new videos. Since this error only happens "every once in ..." I can try to program around it by just having VAP skip a scan in which it occurs. However if the folder stays blocked for more than 2 or 3 scans then the basic functioning of VAP is compromised.

Also, when you paste an error message like that you can omit everything starting with
"************** Loaded Assemblies **************"
just to save space, as that info never helps me.

 

[jtcreate]

Gotcha! Ok...That's what I thought, but I wanted to be sure with your feedback. I looked at my setup and I have an idea on how to fix this on my end. Perhaps as a back up, a 1-2 scan skip can be done. An additional idea is for VAP to also reset after an 1/2 hour if three skips are required (since the Folder lock is temporary)...

 

[dlflannery]

Try substituting test executable (not an installer) Ver. 1.39T1 from the linked zip
https://vap.videoredo.net/VAPexe139T1.zip

This should catch the permission error and put appropriate messages in the log window and file. It will keep attempting to scan. The error messages will become fewer and eventually stop until the problem clears, and then a log message will announce that event.

Unfortunately I haven't been able to trigger this error, by trying to modify permissions on test files, so you will have to be the tester. How often does this occur?

 

[jtcreate]

Try substituting test executable (not an installer) Ver. 1.39T1 from the linked zip
https://vap.videoredo.net/VAPexe139T1.zip

This should catch the permission error and put appropriate messages in the log window and file. It will keep attempting to scan. The error messages will become fewer and eventually stop until the problem clears, and then a log message will announce that event.

Unfortunately I haven't been able to trigger this error, by trying to modify permissions on test files, so you will have to be the tester. How often does this occur?

Ok....I think the problem is in too parts. Too many files moving into the Monitor folder at the same time and one of the .ts files taking 40 minutes to transfer. The two recording systems doesn't do the conversions. They are too busy with multiple tuners. So I have them transfer to another computer that utilizes VAP and does the conversion. So I am having them download into a public "Temp" folder and then moving them to the monitor folder. So far its working...

I'm getting some other errors from VAP but its related to the NPVR XML thread. So I'll be posting there when I have some samples for you.

 

[dlflannery]

Ok....I think the problem is in too parts. Too many files moving into the Monitor folder at the same time and one of the .ts files taking 40 minutes to transfer. The two recording systems doesn't do the conversions. They are too busy with multiple tuners. So I have them transfer to another computer that utilizes VAP and does the conversion. So I am having them download into a public "Temp" folder and then moving them to the monitor folder. So far its working...
................

That's one part. What is the other one?

Curious: what are "the two recording systems"?

 

[jtcreate]

Well I have two NPVR computers feeding .TS files into a third computer that does the post video processing (VAP). I am not rich so my systems are a bit old. They use to all be Media Centers back when I was running Windows Media Center with the internal Hauppauge Colossus cards. But since I slowly acquired the HD PVR2 boxes and changed to network tuning, I have more flexibility and can record more content. But the HD PVR2 doesn't work with Windows Media Center. So I switched to NVPR. Both NVPR computers can record more content at the same time then my old setup. But the post processing is burdening. So I have them both dumping .ts files into the same monitor folder on the third computer that handles the conversion to .mp4. That saves storage space too.

As far as the problem, it's really just one problem...Too many files. Some files (like a baseball or football game in overtime) taking longer to transfer than other files which doesn't help. Solution was to have them transfer to a temporary sub-folder folder in the public directory first and then move them to the "Recorded TV" subfolder which is my monitor folder (where mediacenter use to dump its recordings).

So far, everything has been working perfectly. I haven't even tested your file change yet. I'll try to get to it over the weekend. I use Datamystic "Filewatcher" to monitor the NPVR recording folders with a batch script which takes care of the transfer.

https://www.datamystic.com/filewatcher/htmlhelp/screens/folders-to-watch.htm

 

[jtcreate]

VAP is locking up when things get busy in the monitor folder.

Try substituting test executable (not an installer) Ver. 1.39T1 from the linked zip
https://vap.videoredo.net/VAPexe139T1.zip

This should catch the permission error and put appropriate messages in the log window and file. It will keep attempting to scan. The error messages will become fewer and eventually stop until the problem clears, and then a log message will announce that event.

Unfortunately I haven't been able to trigger this error, by trying to modify permissions on test files, so you will have to be the tester. How often does this occur?

Unfortunately, VAP keeps locking up when the Monitor folder gets busy and has too many files. I have to use Task manager to kill it and restart it. Some of the files get stuck in "Transferring" mode. If I try to restart it, it gets stuck again. I have to remove all the files from the monitor folder, restart VAP and then feed the files back into the monitor folder slowly. I can't see any problems in the log folder.

 

[dlflannery]

If this is happening with no system or .net errors being displayed, it leaves me totally puzzled. How many video files are in the monitored folder when this happens? At what maximum rate of files-per-second are they being transferred in by Datamystic?
How many instances of the VideoReDo processor task are present in Task Manager when a lockup occurs? Also could you send me a copy of VideoFileManager.xml from your VAP appdata folder as it exists when a lockup occurs?

Also, could you send me the postprocessing script you are using? Such scripts should not start programs without waiting for them to finish or VAP could end up stacking up postprocesses, which could cause complications.

Is VAP configured to do theTVDB.com metadata searches? This can take some number of seconds per file detected in the Monitor folder and might give the appearance of a lockup if a large number of new files were detected in a small time. But it should not cause an actual lockup per my understanding of the code. Anyway you could try disabling theTVDB searches (in the "Other" tab of the Advanced Configuration screen). If that eliminates the problem, it gives me a clue as to how to fix it

On the chance it's related to Datamystic, could you try bypassing that, i.e., let the files be output directly by the NPVR processes into the VAP Monitor folder? If you do that you may need to configure a "Delay before processing" in the "Other" tab of Advanced Configuration to allow time for xml files to be transferred in before processing starts.

 

[jtcreate]

I would say no more than 3 files at a time. Most of the time, its just 1 or maybe 2. However, when the lock up occurred, there were 6 other files waiting in the monitor folder for VAP to handle. I'll try stopping the TVDB and see what happens. The VAP postscript is functioning fine. Its not prematurely engaging other processes while it runs. The lock up has happened mid way through the VAP process before the post script was even triggered. So I don't think its anything associated with the post script. I've been using the Datamystics for two years and I've never had an issue. Datamystics doesn't watch anything associated with VAP and it uses a batch script to move the files from the recording system into the VAP monitor folder. It's job is to watch the recording system. I'm pretty confident that the The .Net errors were obviously caused from too much activity taking place in the VAP monitoring folder, along with certain files transferring slowly into the VAP monitor folder. When I reconfigured the Datamystics batch script to transfer recorded material into a temp folder first, the ".net" error cleared up. I've actually triggered the lock up just by manually dumping files into the folder. That just gave me an idea. I'm going to test something.

 

[dlflannery]

If you encounter another lockup I would like to get a better understanding of what that is:
1. Is the VAP UI frozen? E.g., will the monitored file list still scroll? Do other buttons respond?
2. What are the last few log file messages before the lockup?
3. How many VAP processes or VideoReDo processes showing in Task Manager? Also percent disk, cpu and memory usage for each.

 

[jtcreate]

Five VAP processes stuck in "Transferring status". The VAP UI completely freezes up. No buttons respond. Monitor file list does not show changes if I were to remove the files from the directory. Two VAP process are showing up in the Task manager which are Config:1 and Conf:2, It might be the TS files doing it. I send you a link as soon as I figured out which TS file is doing it.

Also, on a separate note...Is there a way for VAP to send error messages through push notification if a file gets stuck in "Transferring" mode after 1-2 hours? I had another case where NPVR ran out of space and sent out more TS files with 0 byte size. I'm working on the space issue.

Thanks.

 

[dlflannery]

If you are running multiple instances of VAP simultaneously you have to give them each distinct monitored and tempQsf folders.

 

[jtcreate]

I double checked and they have different temp folders....I think I found the problem. Apparently when I installed 1.38, the old VAP version was still there. Looks like I forgot to uninstall it.

 

[dlflannery]

And they have different monitored folders, right? What is the purpose of running multiple instances of VAP? There is no speed advantage to doing this since VRD processing has to share the same CPU.

Also, please install the current release, Ver 1.39. I don't support older versions.

 

[jtcreate]

They have different monitor folders. Config#1 of VAP processes the video with Handbrake and renames it. Config #2 simple commercial scans and creates a VPRJ file. It doesn't cut the commercials. The Networks have gotten too creative (especially ABC) in crowding commercials together so that slugs are not detectible or do not exist (no matter how I configure Videoredo. So I simply do the final cut manually. Since the video is already compress into an .mp4, Videoredo just has to remux.

I had problems located version 1.39 on this new server you moved too. The page wasn't coming up. I just tried again. The link you posted appears to be broken.

 

[dlflannery]

I didn't move to a new server. What link to 1.39 do you mean? Ver. 1.40 is the release version now. You must be talking about the link to 1.39T1 posted earlier in this thread (more than a month ago!). I deleted that file from the VRD server because it was superseded by release version 1.40.

 

[jtcreate]

I've been going to the same place to download. But the link kept coming back broken. However, it worked today...Kind of weird. Im going to test with 1.40

 

[jtcreate]

New version is working pretty good so far. But I have notice a another issue. I have two configurations of VAP running. Config#1 handles file renaming and it uses post script Handbrake to compress into .mp4 (in a temp folder. The post script then transfers the mp4 to another designated monitor folder for VAP config#2). VAP Config#2 only does commercial scanning. The output folder of Config#2 (where the VPRJ will appear) is watched by my "watcher program". It watches for any .VPRJ files as a trigger for the next step in filing into library. The watchfolder program routinely watches the output folder every 60 second intervals. I think its conflicting with VAP over the same output folder, because, sometimes when VAP is about to finish a .VPRJ file, VAP config#2 either crashes or the video ends up being sent to the "Failed" folder. It doesn't happen every time. Its random. I can have VAP process the same failed video and it will work fine one minute. Another time, it will fail. So I'm thinking this is the same problem I was having with the monitor folder a few weeks back. The monitor folder was being tied up and VAP was being denied access because of too much activity.

If my suspicion is correct, the one sure way I see to fix it, is to have VAP trigger a Batchscript that takes care of the library transfer and then I just get rid of the "Watchfolder" process. Similar to the handbrake script. That would be preferred. Another possible fix, is for VAP to use a tempfolder for the gradual writing of a VPRJ file instead of using the "OutPut" folder. Right now, VAP just drops into standby mode after it does a commercial scans which is why I incorporated the Watchfolder program.

 

[dlflannery]

I need a better understanding of your process flow. When does the vprj file created by Config #2 get used by VRD to create a final output file, and under control of what program? IOW what does "the next step in filing into library" refer to?

Is Config #2 using Comskip?

What do you mean by 'standby mode' ?

VAP doesn't have a process flow that completes with just creating a vprj file, (and thus would run a postprocess script at that point). Is that what you want? If so I don't understand why.