Post Record action advice?

[mvallevand]

If you only want to move file to your NAS after recording you can use the Archive function, it will also remove folders when appropriate.

The noise probably isn't related to switches.

Martin

[three6zerocool]

I will look into the archive function, thanks.

I think that xcopy switch combination does indeed have an effect, as the NAS goes bonkers with those original switches active.
(my enclosure literally starts rattling from the vibrations, so not sure what's  occurring, but the noise from seeking is 'loud', and ONLY does it when those switches are active)
I was thinking it was doing verify at the same time as it was copying, don't know.

Perhaps it is the order, rather than the switches themselves?

I found another postprocessing.bat file on the forums, and used the xcopy switches from that thread.
The difference is night and day.  (oddly enough some switches are the same, but capitalized, so maybe thats the difference.)

[gEd]

Also discovered that these xcopy switches  /z /j /y /i /h    in the script make my NAS go mental and make the loudest seeking noises imaginable and takes an eternity to actually copy the files.
I changed them to /e /f /J /Y and the file copy is now virtually silent, and it copies the files super-fast. (like a 16GB recording in less than 30 seconds)

It was probably the /z flag which "Copies over a network in restartable mode." that was causing the problem. it sounds like it was writing a block of data and also writing a checkpoint record that was causing the problem
https://learn.microsoft.com/en-us/window...ands/xcopy

As Martin pointed out, watching show whilst recording prevents the script from shifting to the NAS.

This issue may be addressable. I've got some logic in another script that will retry deleting the original source folder (multiple times with a delay) if the first attempt to delete it fails (due to an in progress watching of the show)

Of course it still leaves the folder behind, so, that's the one little issue to clean up.

Should be fixable if we use the rmdir command as this only works on empty folders (source: https://learn.microsoft.com/en-us/window...ands/rmdir)
I'll have a think...

[mvallevand]

Because the actual reason for needing this whole process has never been determined I wouldn't take out the /z it should only be handling network errors without exiting.

Martin

[gEd]

Because the actual reason for needing this whole process has never been determined I wouldn't take out the /z it should only be handling network errors without exiting.

Martin

The OP confirmed that removing /z fixed his performance problem (it can only be this switch, the /e and /f switches don't do anything important). My initial suspicion was that it was /j (Copies files without buffering. Recommended for very large files. This parameter was added in Windows Server 2008 R2) but given that he is getting good performance with this switch still set, rules this out I believe.

There are plenty of posts on the web where people have indicated that using /z kills performance such as this one for roboocopy (which I presume has a similar restart mechanism as xcopy).
The /Z switch writes a header block to the file to track how far it has gotten in the copy. It has to update this header after every write, which is slow. Without restarts the header doesn't have to be written, thus the copy is much faster.

[mvallevand]

I am not saying the /z isn't having problems. What I was meaning is I think there could be other problems and the /z may not be the cause but an effect. We still don't know why he can't write directly given the performance stats presented.

Granted xcopy was replaced and obsolete 16 years ago and who knows how it works these days with new technology.

I probably should not have got involved in this thread anyway so I will sign off now.

Martin

[three6zerocool]

I would like to thank both you and Martin for your insights.

I have taken both of your advice, especially Martin's advice regarding checking the network configuration, as it should be capable of recording directly to the NAS to begin with.

Looking into both the Virtual NextPVR hosted Windows-11,  and my second NextPVR running on Windows 10 bare metal,   I noticed that the Windows 10 machine seems to work much better in terms of recording and playback from the NAS.

Did a few speed tests, and got near identical results from both machines accessing the same NAS.
Perhaps Windows 11 has issues in this regard.

Anyway, input from both of you highly appreciated.

I have my primary NextPVR server using the NAS as a normal recording destination, and my 2nd NextPVR server using the postprocessing.bat configuration, so will experiment with it.