AmaRecTv3.10/Win10?

[916Area52]

Good morning,
Roy here,

Using Win 10 machines (22H2 version 19045-4529) not connected to the internet and they do not receive updates.
Of late, when I stop the capture using AmaRecTv3.10, I've been getting this error "Write to storage is not possible. Stop the recording. Error code 00000087". So, latley, I've just been just re-capturing the same file over again with no error the second time. This error only rears it's head on occasion, not every time.
Then when I try to play the error(ed) file in VLC I get the attached errors.
Do I need to un-install and re-install the I-Data USB capture card? Regedit?

Thanks in advance for any advice/help,
Roy

[davexnet]

The capture was interrrupted so the index within the file was never created - hence the messages in VLC.
Are you short of disk space? What capture codec are you using?

[The_Doman]

Good morning,
Of late, when I stop the capture using AmaRecTv3.10, I've been getting this error "Write to storage is not possible. Stop the recording. Error code 00000087". So, latley, I've just been just re-capturing the same file over again with no error the second time. This error only rears it's head on occasion, not every time.
Roy

I have had this happening occasionally too, that is/was on a Windows 7 system.
Not sure why/what I was doing exactly at that time.

The capture was interrrupted so the index within the file was never created - hence the messages in VLC.

You can then try to load the avi into Virtualdub and let it rebuild the index, that worked for me a few times to recover a capture.

[916Area52]

@ davexnet... Thanks for the reply,
I've used less than half of a 2TB HDD at this point. And the codec is HuffYUV_x64_v2_1_1.msi.

Been doing a little poking around the net. So far I've been leaning towards this as a solution...

https://primaryerror.net/0x00000087-error_is_substed-windows-error-solved/

and... https://www.youtube.com/watch?v=acxCueZ2dVQ .

Not done poking around though.

Any thoughts on this?

[916Area52]

@ The_Doman...
"You can then try to load the avi into Virtualdub and let it rebuild the index, that worked for me a few times to recover a capture."
I've just re-captured, and it didn't return with the error. It's a head scratcher for me.

Also, I've ask AmaRecTv to produce a report on each capture to see if I could nail down the problem. Of coarse the error has not happened again since. Maybe asking AmaRecTv for a report was the solution, LOL.

[davexnet]

@ davexnet... Thanks for the reply,
i've used less than half of a 2tb hdd at this point. And the codec is huffyuv_x64_v2_1_1.msi.

Been doing a little poking around the net. So far i've been leaning towards this as a solution...

https://primaryerror.net/0x00000087-error_is_substed-windows-error-solved/

and... https://www.youtube.com/watch?v=acxcuez2dvq .

Not done poking around though.

Any thoughts on this?

sfc /scannow is a command to verify the integrity of the Windows system files.
No harm in trying it.

Regarding the HUffyUV codec, make sure you have it set to capture YUY2 instead of RGB.
It uses less space, transfer throughput to the hard drive is less, making it easier for the hardware to keep up.

[916Area52]

@ davexnet,
"sfc /scannow is a command to verify the integrity of the Windows system files.
No harm in trying it.

Regarding the HUffyUV codec, make sure you have it set to capture YUY2 instead of RGB.
It uses less space, transfer throughput to the hard drive is less, making it easier for the hardware to keep up."

Thank you. I'm still learning.

[916Area52]

Back again, with an update regarding my "Error code 00000087"...
One of my work stations popped up with my nemesis "Error code 00000087". By this time I had been asking AmaRecTv for reports. The attached is what it gave me, both error and no error are attached. I can't decipher/see where or how the error occurred or why. Perhaps someone here can check it out and let me know if I'm missing something.
Thanks in advance,
Roy

[TimA-C]

Running the SFC /scannow command (elevated cmd window) is a good idea, but I'd run chkdsk first to make sure that your file & directory structure is OK. (Also elevated cmd window) If SFC finds anything then it's a good idea to reboot and rerun SFC until it gives a clean bill of health. (I have a feeling that SFC expects internet access for some of the repairs it does, so it might not be able to fix everything it might find? But still useful to have a possible issue confirmed, either way) Also, have you checked the SMART status of the drive - you said it was an HDD rather than a SSD, so I'm assuming it's a mechanical drive? If you haven't got anything to show you the SMART status of the drive then I'd suggest CrystalDiskInfo from this rather good little website I know . . . VideoHelp.com. You might have heard of it? (If you don't want to connect to t'internet then download the zip file onto a usb memstick on a different machine.) DO THIS FIRST! If you do have a failing drive then you don't want to stress it more than necessary before you have a chance to backup anything important on it.

Finally, if you're running Win10 then presumably there's a fair amount of "horsepower under the hood"? Have you tried either Lagarith or UT Video as alternatives to HUFFYUV? They're both more efficient than HUFFYUV and should (In my experience) give you smaller files with no loss in quality, but they do need a little more processing power to both encode & decode, which is why HUFFYUV was often recommended when older, slower PCs were more common. I'm just thinking that if there's less disk interaction then maybe . . . ?

Just another thought popped up, is it possible that your drive is SO fragmented that AmarecTV is struggling to keep up with the stream of captured data? Might be worthwhile seeing how fragmented Windows thinks that drive is? (If it's a mechanical drive) Even if it's just to cross off another possible issue.

Good Luck!

Edit: Er . . . slightly embarrassing . . . CrystalDiskInfo doesn't seem to be on VH! Apparently it's not quite as good a website as I thought it was . . . ! (It's still a pretty good website! ) I'd look at either the maker's site or Sourceforge. (Please note: I have no connection with the makers/owners of CrystalDiskInfo or, as far as I'm aware, anyone who works for them. Or Sourceforge.)

[916Area52]

@ TimA-C…

Agreed, VideoHelp.com is an awesome site!

What I have to work with and have done so far…

“Horse power”? Such as it is…

Asus H110M-C motherboard (1151 socket)
Intel Core 17-7700K Processor
32G DDR4 2133

My OS is on a dedicated SSD. On this drive, I’ve done cmd as admin with, “dism /online /cleanup-image /restorehealth”, and then, “sfc /scannow”. Came back good/no problems.

My capture drive is a Seagate BarraCuda 2TB Internal Hard Drive HDD – 3.5 Inch SATA 6Gb/s 7200 RPM 256MB Cache (less than a year old). I never let the HDD get more than fifty percent full before I process (AviDemux) the captures out to another drive. Also, this HDD is put through a regular “health check-up” using EaseUsPartion.

Side note… Has this school of thought changed? When these work stations were built, I opted for HDDs for capture as opposed to SSDs. Believe I read somewhere, (can’t remember where, VideoHelp.com, maybe, lol) that because of the way files are written (bad timing/in chunks) to SSDs, they are less desirable than HDDs for capture.

I’m thinking that the capture HDDs are slowly failing. Thank you for the heads-up regarding chkdsk and SMART. I’ll download and check them out with SeaTools/Legacy Tools. Then see if it’s time to change them out.

Never considered another codac. Something to look into.

Hope I didn’t miss anything.

Thank you for taking the time to respond,
Roy

[Alwyn]

Just another thought popped up, is it possible that your drive is SO fragmented that AmarecTV is struggling to keep up with the stream of captured data?

You do not need to defragment drives under Win10. Go to Windows Tools, open the defragger, and see how much fragmentation you have. You'll have Zero, maybe 1% on every drive.

[Alwyn]

Side note… Has this school of thought changed?

Not here. Never had a problem with capturing to all manner of HDDs for over 15 years (all mine are 7200). Capture bitrates are way below the HDD speeds.

From your AmarecTV report, you've got a lot of duplicated frames there. Have a look at the last line:

VT=02:30:30.059s(270619f), Cap=270564f( 0D), Enc= 3.215ms, Siz= 358KB( 53%)KEY, Drp=0, (+)80, (-)4, Buf= 1, o

The +80 are duplicated/inserted frames. Scroll through the file and you'll see when the dupes occur.

I don't know whether that is the cause of or as a result of your 87 error. Normally, that number of dupes would be because of lack of stabilisation eg TBC or other stabiliser. You can use VDub to go to the frame number and see duplicate following it.

Is your 87 error consistent with different tapes?

[lollo]

Side note… Has this school of thought changed? When these work stations were built, I opted for HDDs for capture as opposed to SSDs. Believe I read somewhere, (can’t remember where, VideoHelp.com, maybe, lol) that because of the way files are written (bad timing/in chunks) to SSDs, they are less desirable than HDDs for capture.

That's a complete bullshit.

SSD for capturing are even better than HDD. There is not a single technical reason to support that non sense (I design ICs for both hard disk drives (Seagate and Western Digital) and solid state drives (Toshiba and Samsung))

[916Area52]

@ Alwyn...

"Not here. Never had a problem with capturing to all manner of HDDs for over 15 years (all mine are 7200). Capture bitrates are way below the HDD speeds."

Good to know when/if I do a replacement.

"From your AmarecTV report, you've got a lot of duplicated frames there. Have a look at the last line:

VT=02:30:30.059s(270619f), Cap=270564f( 0D), Enc= 3.215ms, Siz= 358KB( 53%)KEY, Drp=0, (+)80, (-)4, Buf= 1, o

The +80 are duplicated/inserted frames. Scroll through the file and you'll see when the dupes occur."

I see that, now...

The same Dr T VHS was captured twice, first capture gave the 00000087 error, the second capture did not. The same workstation w/a JVC HR-S7800U and no values were adjusted.

Duplicated frames is a bad thing (not trying to be funny, I don't know)? I now pay closer attention to the logs (still learning how to decipher). Some of the logs show +360, and the captures look fine, to me.

"I don't know whether that is the cause of or as a result of your 87 error. Normally, that number of dupes would be because of lack of stabilisation eg TBC or other stabiliser. You can use VDub to go to the frame number and see duplicate following it."

I'm leaning towards a hardware issue that is causing the 87 error.
I'll give Vdub a go, can't hurt.

"Is your 87 error consistent with different tapes?"

Error 87 has just recently reared it's head. It has never been consistent. Wish it was, it may be easier to run down.

Thank you for taking the time to respond,
Roy

[916Area52]

Side note… Has this school of thought changed? When these work stations were built, I opted for HDDs for capture as opposed to SSDs. Believe I read somewhere, (can’t remember where, VideoHelp.com, maybe, lol) that because of the way files are written (bad timing/in chunks) to SSDs, they are less desirable than HDDs for capture.

That's a complete bullshit.

SSD for capturing are even better than HDD. There is not a single technical reason to support that non sense (I design ICs for both hard disk drives (Seagate and Western Digital) and solid state drives (Toshiba and Samsung))

Ok then...

Will be having a look at the SSDs. Any recommendations come to mind? Perhaps a SAMSUNG 870 EVO 4TB 2.5 Inch SATA III Internal SSD (MZ-77E4T0B/AM)?

Thank you for taking the time to respond,
Roy

[Alwyn]

Duplicated frames is a bad thing (not trying to be funny, I don't know)?

Only if you notice them!

[lollo]

Will be having a look at the SSDs. Any recommendations come to mind? Perhaps a SAMSUNG 870 EVO 4TB 2.5 Inch SATA III Internal SSD (MZ-77E4T0B/AM)?

Samsung EVO are nice devices, but if you have a performant HDD for capturing there is no reason to change. It is absolutely adequate.

i was just saying that SSD are the same (even better) for that purpose.

[lollo]

Duplicated frames is a bad thing (not trying to be funny, I don't know)? I now pay closer attention to the logs (still learning how to decipher). Some of the logs show +360, and the captures look fine, to me.

Inserted frames happens when a frame does not arrive at the expected time, and then the capture software duplicates the previous frame in an attempt to keep audio/video synch. It could or could not also hyde a frame being dropped.

It is a synthom that the incoming video signal is no stable (time base corrected) in time, which is not good. It is strictly dependent on the conditions of the tape.

Having 1 or 2 inserted frame in 1 hour is accettabie. More than that is not good in principle, and may lead to a/v asynch and bad visual quality in moving scenes.

[The_Doman]

Of late, when I stop the capture using AmaRecTv3.10, I've been getting this error "Write to storage is not possible. Stop the recording. Error code 00000087".

My capture drive is a Seagate BarraCuda 2TB Internal Hard Drive HDD – 3.5 Inch SATA 6Gb/s 7200 RPM 256MB Cache (less than a year old).

When these work stations were built, I opted for HDDs for capture as opposed to SSDs. Believe I read somewhere, (can’t remember where, VideoHelp.com, maybe, lol) that because of the way files are written (bad timing/in chunks) to SSDs, they are less desirable than HDDs for capture.

Never considered another codec. Something to look into.

It is sure worth trying another codec before you change all your setup.
I personally always preferred Lagarith (over HUffyUV) just because of the smaller files/lower data rate and also playing more easily over slow storage media.
As the problem always seems to occur when you manually STOP the capture i don't believe it is a problem with the storage itself but something with ending/closing the file where something goes wrong.
Possible AmaRecTv3 behaves better when using another codec?

As i mentioned, it happened on me too occasionally with AmarecTV, and that is on a Windows 7 system.
But sure not as frequently as you seem to experience.

Assuming you are not capturing to your system drive any normal HDD should be fast enough to keep up easily when you capturing (SD).
Of course not uncompressed, but who would want do that really.
I sometimes capture in DV/Lagarith (Vdub/Scenalyzer/Amarec) over USB2 using old 2,5 HDD's without any speed problems.

[916Area52]

@ Alwyn...

"Only if you notice them! "
Lol, More truth than fiction there. It has been mentioned, on more than one occasion by fellow travelers that I don't have an eye for critiquing captures.

Also, thank you for this thread, and all that had/has participated.
https://forum.videohelp.com/threads/413286-Frames-Dropped-Inserted-Duplicates-and-the-AmarecTV-log

[916Area52]

@ lollo...

"Samsung EVO are nice devices, but if you have a performant HDD for capturing there is no reason to change. It is absolutely adequate.

i was just saying that SSD are the same (even better) for that purpose."

Always like not having to spend money if I don't have to.

[916Area52]

@ lollo...

"Inserted frames happens when a frame does not arrive at the expected time, and then the capture software duplicates the previous frame in an attempt to keep audio/video synch. It could or could not also hyde a frame being dropped.

It is a synthom that the incoming video signal is no stable (time base corrected) in time, which is not good. It is strictly dependent on the conditions of the tape.

Having 1 or 2 inserted frame in 1 hour is acceptable. More than that is not good in principle, and may lead to a/v asynch and bad visual quality in moving scenes."

That definition of the AmaRecTv logs make them more understandable/sense to me. I don't seem to have an eye for visual critiquing, but I consider myself hyper-sensitive when it comes to a/v synch. My captures look ok, to me, no matter what the AmaRecTv logs reflect. Guess in this case, my ignorance is bliss.

[916Area52]

@ The_Doman...

"It is sure worth trying another codec before you change all your setup.
I personally always preferred Lagarith (over HUffyUV) just because of the smaller files/lower data rate and also playing more easily over slow storage media."

Thank you, TimA-C and others for the heads-up on trying another codec. Using Lagarith now, and is now my new codec. No different than HUffyUV regarding the AmaRecTv log. The capture is comparable, to me, and, is easer on my system.

"As the problem always seems to occur when you manually STOP the capture i don't believe it is a problem with the storage itself but something with ending/closing the file where something goes wrong."

You may have something there. The error does not always happen when I manually stop the the capture, but often enough for me to try and run it down. I'll start letting the AmaRecTv timer run out and see if solves my error 87 nemesis.

"As i mentioned, it happened on me too occasionally with AmarecTV, and that is on a Windows 7 system.
But sure not as frequently as you seem to experience."

Time will tell. Windows 10 has it's challenges as well, when it comes to capturing. You either love it or hate it.

"Possible AmaRecTv3 behaves better when using another codec?"

Will see. Lagarith is now my new go to codec.

"Assuming you are not capturing to your system drive any normal HDD should be fast enough to keep up easily when you capturing (SD).
Of course not uncompressed, but who would want do that really."

As mentioned, my OS is on a dedicated ssd drive and the captures go to separate hdd.
I archive my collection as .avi captures then, .mp4 them for my travels.

"I sometimes capture in DV/Lagarith (Vdub/Scenalyzer/Amarec) over USB2 using old 2,5 HDD's without any speed problems. "

Very nice

Thank you for taking the time to respond,
Roy

[lollo]

My captures look ok, to me, no matter what the AmaRecTv logs reflect. Guess in this case, my ignorance is bliss.

I said "may lead". Inserted frames are an attempt to keep a/v synch (and that there is something wrong in the signal). It may work or not. Only you can judge the end results. In any case, I would not accept a capture with many inserted frames as good. YMMV.

[916Area52]

My captures look ok, to me, no matter what the AmaRecTv logs reflect. Guess in this case, my ignorance is bliss.

I said "may lead". Inserted frames are an attempt to keep a/v synch (and that there is something wrong in the signal). It may work or not. Only you can judge the end results. In any case, I would not accept a capture with many inserted frames as good. YMMV.

Understood

[916Area52]

@ The_Doman...

"As the problem always seems to occur when you manually STOP the capture i don't believe it is a problem with the storage itself but something with ending/closing the file where something goes wrong."

I do believe you solved my 00000087 error.

I do have a habit of stopping the VCR and AmaRecTv when the capture is complete, and before the VCR has had a chance to rewind. Lesson learned, will not do this in the future.

Thank you, and to all of you who have takin the time to respond,
Roy

[916Area52]

At the risk of getting sideways in this thread, I started another thread about dropped frames.

https://forum.videohelp.com/threads/416516-What-am-I-missing-%28dropped-frames%29#post2756879

Thanks again,
Roy

[The_Doman]

I do believe you solved my 00000087 error.

I do have a habit of stopping the VCR and AmaRecTv when the capture is complete, and before the VCR has had a chance to rewind. Lesson learned, will not do this in the future.

Intresting, but I don't understand exactly how you (possibly) have solved the problem now?
Starting and stopping captures in between i also do very often, specially when testing/trying out settings or skipping unneeded parts of video.
Rewinding a tape should logically have nothing to do with it.
But possible having a stable/unstable image (no signal/end of tape noise etc.) on your capture device can have an effect on how AmarecTV reacts to it?
Also different capture devices can react different when there is no clear/stable video signal present.
Here i regularly feed all my video trough a Panasonic DVD recorder (as "surrogate TBC"), so the video signal is always perfectly stable during playback/no signal/tape noise or other disturbances when i use my Dazzle DVC100 with AmarecTV or Virtualdub.

You also could try/use the "segmented capture option" on AmarecTV, but it is not seamless, you will lose frames.

From another related AmarecTV topic:
JVC VCR vs Panasonic ES15 vs AmaRecTv

Frustrating indeed when your capture program unexpectedly stops and you end up with an unfinished/unfinalized capture file you then need to recover/rebuild.
That is why i always like the seamless segmented capture feature of ScenalyzerLive so much.
It can capture in "finished" segments which can be joined/merged afterwards without losing any frames.
That is also so convenient when you doing "marathon" long captures and easily can keep/delete the parts you want.
I really miss that feature, seamless segmented capture, in VirtualDub/AmarecTV.
The old AVi_io also did this perfectly.

[916Area52]

@ The_Doman...

"Intresting, but I don't understand exactly how you (possibly) have solved the problem now?"

Not exactly sure either. Have not had an 87 error up to this point since these steps have been takin, .i.e. cmd as admin with, dism /online /cleanup-image /restorehealth, then, sfc /scannow, codec change and not interfering/stopping the capture prematurely. Knock on wood, Lol.

"From another related AmarecTV topic:
JVC VCR vs Panasonic ES15 vs AmaRecTv
Originally Posted by The_Doman View Post
Frustrating indeed when your capture program unexpectedly stops and you end up with an unfinished/unfinalized capture file you then need to recover/rebuild.
That is why i always like the seamless segmented capture feature of ScenalyzerLive so much.
It can capture in "finished" segments which can be joined/merged afterwards without losing any frames.
That is also so convenient when you doing "marathon" long captures and easily can keep/delete the parts you want.
I really miss that feature, seamless segmented capture, in VirtualDub/AmarecTV.
The old AVi_io also did this perfectly."

Checked out ScenalyzerLive. The .avi file size of 2 or 4 GB limitation leaves me out.

[lollo]

Not exactly sure either. Have not had an 87 error up to this point since these steps have been takin, .i.e. cmd as admin with, dism /online /cleanup-image /restorehealth, then, sfc /scannow, codec change and not interfering/stopping the capture prematurely. Knock on wood, Lol.

You can stop a capture at whatever time without introducing issues. You do not have to wait until the tape ends (if I have understood your description). Something is wrong with your system.