DirectShowSource could not open as...

[TCmullet]

Attached is a short (less than 1 sec) MP4 clip that i cannot open in DirectShowSource. MediaInfo does show it as AVC video and AAC audio. Could perhaps someone here kindly suggest a way to open it, please? It HAS to be opened by DirectShowSource, as DSS has features I need to properly process it. (Of course the real file is much larger, but this attached sample is enough to demonstrate the error.)

It plays fine in SMPlayer, VLC player, and Windows Media Player.

Edit: I should have included in the title that this is a VFR file and the reason for which I need to use DirectShowSource instead of my usual DGSource.

[FranceBB]

I would strongly suggest you to use a better indexer, like FFMpegSource2, LWLibavVideoSource, LSMASH or DGAVCDecode.
DirectShowSource uses your internal codec installed in the OS to decode the video and it's thought to be not as frame accurate as other indexers; for this reason I consider it to be ok-ish for quick and dirt view, but you should use better alternatives when they are available.
That said, if you really wanna use DirectShowSource to open pretty much any source, make sure you have the LAV Filters (Decoders) installed.
If you want, you can install the K-Lite Codec Pack which installs pretty much any codec you need (including the LAV Filters / Decoders).

Cheers,
Frank.

[tebasuna51]

I can confirm than:

A=LSMASHAudioSource("C:\tmp\2018-09-21.1900.wv.MS-v-FL.1sec-sample.mp4")
V=LSMASHVideoSource("C:\tmp\2018-09-21.1900.wv.MS-v-FL.1sec-sample.mp4") # MOV,MP4,3GP
or
A=DirectShowSource("C:\tmp\aud_graph.grf", video=False) # audio only (LAV Audio Decoder, video renderer removed)
V=DirectShowSource("C:\tmp\vid_graph.grf", audio=False) # video only (LAV Video Decoder, audio renderer removed)
AudioDub(V, A)

works without problem.

[TCmullet]

I would strongly suggest you to use a better indexer, like FFMpegSource2, LWLibavVideoSource, LSMASH or DGAVCDecode.
DirectShowSource uses your internal codec installed in the OS to decode the video and it's thought to be not as frame accurate as other indexers; for this reason I consider it to be ok-ish for quick and dirt view, but you should use better alternatives when they are available.
That said, if you really wanna use DirectShowSource to open pretty much any source, make sure you have the LAV Filters (Decoders) installed.
If you want, you can install the K-Lite Codec Pack which installs pretty much any codec you need (including the LAV Filters / Decoders).

Cheers,
Frank.
I specifically have to use DSS because it's a darn VFR video. And I've learned that it can have certain extra clauses so as to read:
DirectShowSource("2018-09-21.1900.wv.MS-v-FL.1sec-sample.mp4", fps=59.94, convertfps=true)

"...uses your internal codec installed in the OS to decode the video and it's thought to be not as frame accurate as other indexers..." It is certainly extremely frame accurate when the several video players play the file (assuming directshow is what the players are using). So when I see the players playing it right, and DSS has the convertfps feature (which i've SEEN to solve the VFR problem before), it makes sense to use DSS this time.

I've had K-lite installed in past systems, but I'm not crazy about it. I can't remember why, but vaguely recall it may have messed up a system. I DO have ffdshow with "audio decoder configuration". It has AAC set to "libavcodec". (vs "disabled" or "libfaad2") Does this tell us anything?

Is THIS what I need?
https://www.fosshub.com/LAV-Filters.html

[TCmullet]

I can confirm than:



works without problem.
I suppose I could obtain GraphEdit and learn to use it. However, does it have a "convertfps" feature? (This is the reason I felt I needed to use DSS as DSS has that feature.)

[TCmullet]

And besides... If SMplayer, VLC, and WMP can ALL play these VFR files in perfect sync anywhere throughout the file, shouldn't we be able to access whatever system resources THEY are accessing and use them for the same purpose, albeit in Avisynth rather than a media player?

[sneaker_ger]

ffms can convert vfr to cfr as well:
E.g.
DirectShowSource("2018-09-21.1900.wv.MS-v-FL.1sec-sample.mp4", fps=59.94, convertfps=true)
is similar to
a=ffaudiosource("2018-09-21.1900.wv.MS-v-FL.1sec-sample.mp4")
v=ffvideosource("2018-09-21.1900.wv.MS-v-FL.1sec-sample.mp4", fpsnum=60000, fpsden=1001)
AudioDub(v, a)

[sneaker_ger]

And besides... If SMplayer, VLC, and WMP can ALL play these VFR files in perfect sync anywhere throughout the file, shouldn't we be able to access whatever system resources THEY are accessing and use them for the same purpose, albeit in Avisynth rather than a media player?
The problem is that we are mapping variable framerates into a "system" that's purely designed for constant framerates (AviSynth/AVI). Either you convert to CFR or you "copy" the timestamps outside of AviSynth from source to target file.
http://avisynth.nl/index.php/VFR

[TCmullet]

ffms can convert vfr to cfr as well:
E.g.
DirectShowSource("2018-09-21.1900.wv.MS-v-FL.1sec-sample.mp4", fps=59.94, convertfps=true)
is similar to
a=ffaudiosource("DirectShowSource("2018-09-21.1900.wv.MS-v-FL.1sec-sample.mp4")
v=ffvideosource("2018-09-21.1900.wv.MS-v-FL.1sec-sample.mp4", fpsnum=60000, fpsden=1001)
AudioDub(v, a)
Does that code work with my sample file? Are you implying that DSS won't blow up IF it's fed directly to ffaudiosource, even though it DOES blow when fed directly to Avisynth?

[TCmullet]

The problem is that we are mapping variable framerates into a "system" that's purely designed for constant framerates (AviSynth/AVI). Either you convert to CFR or you "copy" the timestamps outside of AviSynth from source to target file.
http://avisynth.nl/index.php/VFR
Yes. I realize that. But it seems to me that if VLC, etc. can properly sync the VFR audio and video, then we should be able to as well, THEN apply frame duplication-decimation as needed for our CFR environment.

Edit: I got to realizing later that my question here is partly irrelevant. I was driving to work thinking about this; the matter of PTSes guiding a player. It dawned on me that the players are playing the frames at a variable rate!! I was assuming it dups-and-decimates like WE WANT to do, but as a mere player, there's no reason why it would have to do that. It can simply play the video and audio chunks at whatever timestamp the files says to EVEN if it is variable! So I apologize for this digression.

[sneaker_ger]

Does that code work with my sample file? Are you implying that DSS won't blow up IF it's fed directly to ffaudiosource, even though it DOES blow when fed directly to Avisynth?
Sorry, I made a copy&paste-mistake. It would blow up. Corrected now.

[tebasuna51]

I specifically have to use DSS because it's a darn VFR video.

Like sneaker_ger say you the same can be done with FFMS2 or LSMASH.

BTW to recode VFR video I extract the timecodes/timestamps of video, recode the video without add/delete new video frames (without ConvertFPS) and after restore the timecodes when mux.

[TCmullet]

ffms can convert vfr to cfr as well:
E.g.
DirectShowSource("2018-09-21.1900.wv.MS-v-FL.1sec-sample.mp4", fps=59.94, convertfps=true)
is similar to
a=ffaudiosource("2018-09-21.1900.wv.MS-v-FL.1sec-sample.mp4")
v=ffvideosource("2018-09-21.1900.wv.MS-v-FL.1sec-sample.mp4", fpsnum=60000, fpsden=1001)
AudioDub(v, a)
Good news, this works. Bad news, when I substitute the full 1.5 GB file from which I had cut the sample (using AviDemux), I now get an error: FFaudiosource: no audio track found

In both cases, the .ffindex file was built. Any ideas as to what's happening??

Edit: I created some more sample files, each starts from the beginning of the original file:
1min
10min
15min
20min
1 min and 10 min work fine. But 15 min and 20 min have the error.

When I create a file that is the last 5 minutes of the 15 min. file, the error occurs. Makes me think something is funky in the file that Avidemux (and all players) forgive, but ffaudiosource does not.

I created a file that starts at 15 min. in and goes to the end of the program. Total minutes is 55 min. And it WORKS. Sooo.... what glitch could be in a file that would cause ffaudiosource to say "no audio track found"?
...
I used Avidemux to save audio to PCM and use wavsource(). Yes, a data corruption exists at 11:22. I'm able to manually get around it in Avisynth. But I still wonder why the "no audio track found" message, when there IS one, but simply has a bad spot.

[StainlessS]

Wanna try this.

GetSeq.avsi

# GetSeq.avsi

Function GetSeq(String vFn,String "aFn",Val "fpsNum",Val "fpsDen") {
/*
Req:- RT_Stats, FFMS, LSmash.

Specify FrameRate using fpsnum (Numerator) and fpsden (Denominator) # *** INGNORED if AVI ***
num only, eg fpsnum=25.0, FrameRate = 25.0 FPS
num & den, eg fpsnum=24000 fpsden=1001, FrameRate = 23.976 FPS (Both should be type Int).
neither specified FrameRate = UnDefined, ie whatever source filter thinks it is.
ALWAYS:- use named args if using fpsnum/fpsden, argument order may change.
*/
Function IsISOFileName(String s) {s=RT_GetFileExtension(s) Return(s==".mov"||s==".mp4"||s==".m4v"||s==".3gp"||s==".3g2"||s==".mj2"||s==".dvb"||s==".dcf"||s==".m21")}
Function IsRiffFileName(String s) {s=RT_GetFileExtension(s) Return(s==".avi"||s==".wav")}
myName="GetSeq: " aFn = Default(aFn,"") aFn = (aFn=="") ? vFn : aFn
Assert(vFn!="",RT_String("%svFn Cannot be ''",myName)) vFn = vFn.RT_GetFullPathName IsRiffV = vFn.IsRiffFileName IsIsoV = vFn.IsISOFileName
Assert(aFn!="",RT_String("%saFn Cannot be ''",myName)) aFn = aFn.RT_GetFullPathName IsRiffA = aFn.IsRiffFileName IsIsoA = aFn.IsISOFileName
c=0 a=0
def = fpsnum.Defined ? (fpsden.Defined ?1:0) : (!fpsden.Defined) ? 2 : -1 # 0=NumOnlyDef, 1=BothDef, 2=NoneDef, -1=DenOnlyError
Assert(0<=def,myName+"Cannot specify framerate using fpsden only")
# Rate=num : Rate=num/den : Rate=Undefined
num=(def==0) ? Round(fpsnum * 1000): (def==1) ? Int(fpsnum) : RT_Undefined
den=(def==0) ? 1000 : (def==1) ? fpsden : RT_Undefined
#
Try { # 1st Try specialized AVI
c = (IsRiffV) ? vFn.AviSource : NOP
(c.IsClip) ? RT_DebugF("AviSource opened Video\n '%s'",vFn,name=myName) : NOP
} catch (msg) { RT_DebugF("Catch: %s",msg,name=myName) }
Try {
a = (c.IsClip && c.HasAudio && aFn==vFn) ? c : (IsRiffA) ? aFn.WavSource : NOP
(a.IsClip && a.HasAudio) ? RT_DebugF("%s opened Audio\n '%s'",(c.IsClip && c.HasAudio && aFn==vFn)?"AviSource":"WavSource",aFn,name=myName) : NOP
} catch (msg) { RT_DebugF("Catch: %s",msg,name=myName) }

# Next try specialized ISO LSMash
Try {
IsOpenV=(c.IsClip && c.HasVideo)
c = (IsIsoV) ? LSMASHVideoSource(vFn,fpsnum=num,fpsden=den) : c
(IsIsoV) ? RT_DebugF("LSMASHVideoSource opened Video\n '%s'",vFn,name=myName) : NOP
} catch (msg) { RT_DebugF("Catch: %s",msg,name=myName) }
Try {
IsOpenA=(a.IsClip && a.HasAudio)
a = (IsIsoA) ? LSMASHAudioSource(aFn) : a
(IsIsoA) ? RT_DebugF("LSMASHAudioSource opened Audio\n '%s'",aFn,name=myName) : NOP
} catch (msg) { RT_DebugF("Catch: %s",msg,name=myName) }

# Next try FFMS2
Try {
IsOpenV=(c.IsClip && c.HasVideo)
(!IsOpenV) ? FFIndex(vFn) : NOP
c=(!IsOpenV) ? FFVideoSource(vFn,fpsnum=num,fpsden=den) : c
(!IsOpenV) ? RT_DebugF("FFVideoSource opened Video\n '%s'",vFn,name=myName) : NOP
} catch (msg) { RT_DebugF("Catch: %s",msg,name=myName) }
Try {
IsOpenA=(a.IsClip && a.HasAudio)
a=(!IsOpenA) ? FFAudioSource(aFn) : a
(!IsOpenA) ? RT_DebugF("FFAudioSource opened Audio\n '%s'",aFn,name=myName) : NOP
} catch (msg) { RT_DebugF("Catch: %s",msg,name=myName) }

# Next try LSmash non ISO Video
Try {
IsOpenV=(c.IsClip && c.HasVideo)
c = (!IsOpenV && !IsIsoV) ? LWLibavVideoSource(vFn,fpsnum=num,fpsden=den) : c
(!IsOpenV && !IsIsoV) ? RT_DebugF("LWLibavVideoSource opened Video\n '%s'",vFn,name=myName) : NOP
} catch (msg) { RT_DebugF("Catch: %s",msg,name=myName) }
Try {
IsOpenA=(a.IsClip && a.HasAudio)
a = (!IsOpenA && !IsIsoA) ? LWLibavAudioSource(aFn) : a
(!IsOpenA && !IsIsoA) ? RT_DebugF("LWLibavAudioSource opened Audio\n '%s'",aFn,name=myName) : NOP
} catch (msg) { RT_DebugF("Catch: %s",msg,name=myName) }

Assert(c.IsClip, RT_String("%s failed open on\n '%s'",myName,vFn))
(!c.HasAudio && a.IsClip && a.HasAudio) ? AudioDubEx(c,a) : c
(!HasAudio) ? RT_DebugF("Audio failed Open on\n '%s",aFn,name=myName) : NOP
return Last
}

EDIT: Oops, cockup with the names fpsnum/num fpsden/den. Fixed.

GetSeq_Test.avs

######
#GetSeq_Test.avs
######

#FN="10Bit_Standard8_Scan_16FPS.avi" # This 10 bit dont load with Avisource(), [leastwise not on my system, codec v210, and no audio]
#FN="ALTEST2.mp4"
#FN="heima_720p_500.mp4"
FN="tears_of_steel_1080pwebm.webm"

FN=RT_GetFullPathName(FN)

Getseq(FN,fpsnum=33000,fpsden=1001) # Test 33000/1001
Info


EDIT: DebugView output

00000040 22:24:39.471 InitExternalPlugins:
00000041 22:24:39.471 InitExternalPlugins: Auto load plugins script ENTRY
00000042 22:24:39.471 InitExternalPlugins:
00000043 22:24:39.471 InitExternalPlugins:ShowAvsInitInfo:
00000044 22:24:39.471 InitExternalPlugins:ShowAvsInitInfo: VersionString = 'AviSynth+ 0.1 (r2900, MT, i386)'
00000045 22:24:39.471 InitExternalPlugins:ShowAvsInitInfo: Avisynth Bitness = 32
00000046 22:24:39.471 InitExternalPlugins:ShowAvsInitInfo: ProcessName = 'C:\Program Files (x86)\DAUM\PotPlayer\PotPlayerMini.exe'
00000047 22:24:39.471 InitExternalPlugins:ShowAvsInitInfo: OSVersionString = 'Windows 7 (x64) Service Pack 1.0 (Build 7601)'
00000048 22:24:39.471 InitExternalPlugins:ShowAvsInitInfo: OSVersionNumber = 6.100000
00000049 22:24:39.471 InitExternalPlugins:ShowAvsInitInfo: CPUName = 'Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz / Yorkfield (Core 2 Quad) 6M'
00000050 22:24:39.471 InitExternalPlugins:ShowAvsInitInfo: Cores = 04:04 (Phy:Log)
00000051 22:24:39.471 InitExternalPlugins:ShowAvsInitInfo: CPU Extensions = 'MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1'
00000052 22:24:39.471 InitExternalPlugins:ShowAvsInitInfo: Total Memory = 12221MB
00000053 22:24:39.471 InitExternalPlugins:ShowAvsInitInfo: Avail Memory = 9890MB'
00000054 22:24:39.471 InitExternalPlugins:ShowAvsInitInfo: Screen Res = 1920x1080
00000055 22:24:39.471 InitExternalPlugins:ShowAvsInitInfo: Screen BitPerPixel = 32
00000056 22:24:39.471 InitExternalPlugins:ShowAvsInitInfo: Time = 'Monday 22 July 2019 22:24:39[GMT Daylight Time]'
00000057 22:24:39.471 InitExternalPlugins:ShowAvsInitInfo:
00000058 22:24:39.471 InitExternalPlugins:AvsInit_Load_CPP_Plugin: DGDecode.DLL LOADED OK
00000059 22:24:39.471 InitExternalPlugins:AvsInit_Load_C_Plugin: ffms2.dll LOADED OK
00000060 22:24:39.487 InitExternalPlugins:AvsInit_Import_Avsi: ffms2.avsi IMPORTED OK
00000061 22:24:39.487 InitExternalPlugins:AvsInit_Load_CPP_Plugin: LSMASHSource.dll LOADED OK
00000062 22:24:39.830 GetSeq: FFVideoSource opened Video
00000063 22:24:39.830 GetSeq: 'D:\GetSeq_Test\tears_of_steel_1080pwebm.webm'
00000064 22:24:40.017 GetSeq: FFAudioSource opened Audio
00000065 22:24:40.017 GetSeq: 'D:\GetSeq_Test\tears_of_steel_1080pwebm.webm'


And for another audio-less 10 bit file

00000127 22:28:31.526 GetSeq: Catch: AVISource: couldn't locate a decompressor for fourcc v210
00000128 22:28:31.526 GetSeq: (D:\GetSeq_Test\GetSeq_Test.avs, line 26)
00000129 22:28:31.604 GetSeq: FFVideoSource opened Video
00000130 22:28:31.604 GetSeq: 'D:\GetSeq_Test\10Bit_Standard8_Scan_16FPS.avi'
00000131 22:28:31.604 GetSeq: Catch: FFAudioSource: No audio track found
00000132 22:28:31.604 GetSeq: (D:\GetSeq_Test\GetSeq_Test.avs, line 55)
00000133 22:28:31.619 GetSeq: Catch: LWLibavAudioSource: failed to get the audio track.
00000134 22:28:31.619 GetSeq: (D:\GetSeq_Test\GetSeq_Test.avs, line 67)
00000135 22:28:31.619 GetSeq: Audio failed Open on
00000136 22:28:31.619 GetSeq: 'D:\GetSeq_Test\10Bit_Standard8_Scan_16FPS.avi

[TCmullet]

I've been using DGSource for most of my files, which are from my capture device (Hauppauge) and are CFR. I have a skeleton set up to use that in most cases. But cases where there is VFR (variable frame rate) video, I use this:

a=ffaudiosource("2018-09-21.1900.wv.MS-v-FL.1sec-sample.mp4")
v=ffvideosource("2018-09-21.1900.wv.MS-v-FL.1sec-sample.mp4", fpsnum=60000, fpsden=1001)
AudioDub(v, a)

I had a theory... Why do I need to use DGSource even for CFR videos? I have to separate the video from the audio (saving to .wav), whereas ffaudiosource can get it directly from the video (.mp4 or .TS) as per the above example. The conversion to CFR is harmlessly redundant.

I ran a serious test on one file, running it both ways. The scripts were virtually identical. Sound sync was slightly different but nothing I couldn't tweak for each script. I run the output from VirtualDub out to a file with MagicYUV codec. The test results are SHOCKING! My normal DGSource and .wav took 48 minutes. The one with ffvideosource took only 20 minutes! WHY LESS THAN HALF??? It's true that .wav takes more space and more I/O time than audio that stays compressed (and read via ffaudiosource). Perhaps I ought to test using the audio converted to .wav then open IT with wavsource(), for a fair comparison of ffvideosource to DGSource. But still, I am shocked by the current results and am inclined to shift all my processing to ffvideosource() Why is ffvideosource over TWICE the speed. of DGSource?

Update: I did one more run with ffvideosource. This time the audio came via .wav and wavsource(). Perhaps some of the savings was ffaudiosource getting audio directly from the compact aac within my TS file. Actually it wasn't. This run took only 22 minutes, very close to the 20 minute run! SO... why is ffvideosource so much faster than DGSource? I experienced the scrubbing problem of ffvideosource, which is understandable. I suspect DGSource is more sophisticated allowing the fully frame independent scrubbing. But if my editing needs are few, then scrubbing is not a problem as long as ffvideosource is accurate. The thing that made me question the need for DGSource was that ffvideosource is building it's OWN index, parallel to the one I manually create via DGIndexNV. So ffvideo SHOULD be just as frame-accurate, right? So my main question remains... why is ffvideosource so much faster? TIA to all.

[MeteorRain]

Regarding dgsource speed. It uses your graphics card video decoder to decode, while ff is likely to use your CPU to decode.
If there's an obvious difference on speed, it would be a performance difference between your graphics card video decoder and your CPU.

What's your graphics card, and what's your CPU?

[TCmullet]

Regarding dgsource speed. It uses your graphics card video decoder to decode, while ff is likely to use your CPU to decode.
If there's an obvious difference on speed, it would be a performance difference between your graphics card video decoder and your CPU.

What's your graphics card, and what's your CPU?

Graphics? Terrible. So bad by today's standards that I'm embarrassed to say. (And I'd have to dig around/figure out what I have.) CPU? Moderately good (but old). A Xeon 4-core, 8-thread workstation. Thank you for solving the mystery. I was starting to wonder if that might be the solution. Actually, I had a clue from a different thread where I was talking about DGSource not being able to decode H.265, and Don himself refuted me. And through that discussion, my archaic graphics adapter got flushed into embarrassing view. (To me, it was slick. Bought it from a used PC rebuilder--biggest I had had--same guy that sold me the Xeon. And this was only 3 years ago. But the world went by too fast for me.)

[TCmullet]

And of course, the CPU utilization is running only 22%, as ff is not multithreading and therefore it's using only one real core out of my 4 real cores. But it's still faster than with my DGSource environment.

One special plus with DGSource is that when I was ransomware attacked 2 years ago and the system was chock full of "gigaquads" of video files waiting for me to work on, I discovered months later that both DGSource and Mpeg2Source would SKIP OVER the corrupted (encrypted) header to find that other than the 1st few seconds, the rest of the video and audio was INTACT! Gee, was I thrilled to discover THAT! I don't have $6000 to pay an evil extortioner.

[Groucho2004]

And of course, the CPU utilization is running only 22%, as ff is not multithreading and therefore it's using only one real core out of my 4 real cores. FFVideoSource is multi-threaded.

[videoh]

One special plus with DGSource is that when I was ransomware attacked 2 years ago and the system was chock full of "gigaquads" of video files waiting for me to work on, I discovered months later that both DGSource and Mpeg2Source would SKIP OVER the corrupted (encrypted) header to find that other than the 1st few seconds, the rest of the video and audio was INTACT! Gee, was I thrilled to discover THAT! I don't have $6000 to pay an evil extortioner. Great to hear! Did the other source filters have a problem with those files?

[StainlessS]

when I was ransomware attacked 2 years ago and the system was chock full of "gigaquads" of video files waiting for me to work on, I discovered months later that both DGSource and Mpeg2Source would SKIP OVER the corrupted (encrypted) header to find that other than the 1st few seconds, the rest of the video and audio was INTACT! Gee, was I thrilled to discover THAT! I don't have $6000 to pay an evil extortioner.

Had you already (DG)Indexed the files (prior to extortion) or were they indexed after they were made 'non-playable' ?

[ie was it the pre-existing indexing that enabled defeat of blackmailer, or did they index ok even after being obfuscated].

EDIT: I assume that DgSource also indexes files akin to DgIndex.

EDIT: And I dont suppose that you still have samples of the obfuscated files, or do you ?
And what types of files worked OK, VOB ? [I'm guessin' VOB or TS or Mpeg2 Program Stream], and were there any file types that generally did not work OK.

[TCmullet]

Hi Stainless (if you're still around to read this and are still interested). Sorry I didn't notice your post with questions back then. DGSource etc. were able to build their index AFTER the video file (TS, M2TS, or whatever) was encrypted. And I'm not sure if I saved any of the damaged video files. (Would take a lot of hunting to check.)

In the years since this episode, I am saddened as I hear other reports of ransomware attacks. I don't know if most attacks were via Remote Desktop. But it is a relative EASY set of steps to go through to prevent Windows from being attacked in that way. ALL the loopholes were open in my case. Some of the loopholes were CRIMINAL NEGLIGENCE by Microsoft in setting up the defaults for login retry counts. It's not even easy to change them (as it's not well-documented), so all the more reason why MS should have set defaults that would not allow easy invasion by RDT invaders. The losses I had ended up being very irritating only, unlike the life-threatening disasters these criminals cause to many victims.

[StainlessS]

Would take a lot of hunting to check.
No sweat, I'de actually forgotten all about it.