View Full Version : XviD-1.1.0-Beta1
Sharktooth
17th January 2005, 18:15
Yes it was there even in previous builds...
Once you restore the decoder defaults it won't "move" anymore...
_rEuTeL_
17th January 2005, 18:29
yes, but if you enable deblocking again, it happens again and again
Sharktooth
17th January 2005, 18:35
...i know...
Marcel
17th January 2005, 18:41
Originally posted by Sharktooth
Well, yes coz the encode must respect the "max bitrate" for that profile...
So if a fixed quantizer encode exceeds a xxxx bitrate the VBV should lower it to respect the profile...
IMHO 1pass with VBV is useless.
I like to encode short funny clips for my mobile (Nokia 3650), 208*1xx pixels, 12.5 or 15 FPS. File size doesn't matter, so I go for Q5 or Q6. In some scenes this throws the bitrate above 200 kbit/s, where the SmartMovie Player starts to cry for more performance (but I didn't find any Socket 775 inside the phone yet, any help on that? ;)). That's a case where 1pass with VBV is useful - or did I get the whole VBV idea wrong?
Sharktooth
17th January 2005, 18:56
I'm saing i dont know if a CORRECT 1 pass VBV is possible, but i dont think it is.
VBV is not only something that gets enabled or disabled...
Tri
17th January 2005, 19:01
Selecting XviD in VirtualDub and clicking the "about" button shows the GPL License with a "Dismiss" button. Is that intended? :confused:
Marcel
17th January 2005, 19:25
Originally posted by Sharktooth
I'm saing i dont know if a CORRECT 1 pass VBV is possible, but i dont think it is.
VBV is not only something that gets enabled or disabled...
Because with VBV you have to answer the same question as with a target size / target bitrate for the whole video: How many bits for frame x? ?
So I better go for a 2pass encode with fixed quantizer, if I want to have a sensible use of VBV.
Luminaria
17th January 2005, 19:47
What is VBV exactly? I noticed that on the tab containing the @ profile recomendations but am not really sure what purpose it serves.
JarrettH
17th January 2005, 20:03
Nice profiles too:D
ObiKenobi
17th January 2005, 20:16
Originally posted by Luminaria
What is VBV exactly? I noticed that on the tab containing the @ profile recomendations but am not really sure what purpose it serves.
It's used so that the video stream's bitrate doesn't overwhelm the buffer of the decoder. It's really only useful when you are playing the encodes on a hardware player or a PDA.
peteag
17th January 2005, 21:24
Does XviD contain all features of the ASP-standard now or is it far away from this (4mv, slices etc.)? Same the decoder?
LordIntruder
18th January 2005, 05:09
Originally posted by ObiKenobi
It's used so that the video stream's bitrate doesn't overwhelm the buffer of the decoder. It's really only useful when you are playing the encodes on a hardware player or a PDA.
I was going to ask the same question. Is that really only for a question of hardware? Someone said above that he gets a better compression with this option on.
By enabling this option, what am I supposed to get?
I will of course test this option but it is just to know what basically this new one is intended for.
Thanks :)
ObiKenobi
18th January 2005, 05:23
Originally posted by LordIntruder
I was going to ask the same question. Is that really only for a question of hardware? Someone said above that he gets a better compression with this option on.
By enabling this option, what am I supposed to get?
I will of course test this option but it is just to know what basically this new one is intended for.
Thanks :)
That's what the option is used for, it has nothing to do with compression level. It's so the decoders buffer doesn't get overwhelmed by spikes in the bitrate causing stuttering playback. I don't ever use the option so I have no clue what it does to compressibility, but I remember one time I had forgotten to turn it off when I had done a new install of XviD and it made the quality go down a noticeable amount.
BoNz1
18th January 2005, 06:34
BTW for all the people wanting to know about 1 pass VBV and whether or not it is worthwhile or not, I urgue you to think about the world beyond your DVD rips :P. You definitely need strict VBV if you want to do any kind of streaming. I guess you would need some sort of look ahead though too so it wouldn't be a completely blind one pass. Anyway, is it just me or would it not be cool to see streaming XviD? I'm sick of all these proprietary streaming garbage. Oh, well it will probably happen one day when someone needs it.
madness
18th January 2005, 07:41
Hi all, when I encode videos in xvid I tend to have closed gov enabled, but on this beta I found the closed gov option is gone. Is it been disable for this beta or it got replaced Rate-Distortion mode decision for bvops?
Thanks.
ObiKenobi
18th January 2005, 07:42
Originally posted by madness
Hi all, when I encode videos in xvid I tend to have closed gov enabled, but on this beta I found the closed gov option is gone. Is it been disable for this beta or it got replaced Rate-Distortion mode decision for bvops?
Thanks.
I'd be willing to bet its now just a default option.
AsTimeGoesBy
18th January 2005, 12:30
I have installed Xvid 1.1 beta yester evening.... :)
So if i have understand correctly the posts here in this thread, enabling this VHQ feature also for b-frames may improve quality, right!?
Edit: i found something about this in a post by Sharktooth (http://forum.doom9.org/showthread.php?&threadid=88525)
Another thing, is there any possibility to overtake my zone settings from Xvid v1.0 to v1.1?
Till now i only had to re-activiate the encoding jobs in VirtualDub's job list but that doesn't work any longer. Also copying and pasting registry strings doesn't work any longer... :(
I have a problematical vide to encode and i'm wondering how Xvid 1.1 will solve it with just the same zone settings.
peteag
18th January 2005, 16:15
which format does xvid use: 4:1:1, 4:2:0 o.s. ?
Koepi
18th January 2005, 16:58
YV12 is defined as planar Y'CbCr 4:2:0.
The registry settings between 1.0.x and 1.1.x are incompatible. you can take the zones alone from the 1.0-registry export and import those to the settings in 1.1.x.
AsTimeGoesBy
18th January 2005, 18:27
Originally posted by Koepi
...
The registry settings between 1.0.x and 1.1.x are incompatible. you can take the zones alone from the 1.0-registry export and import those to the settings in 1.1.x. Thanks, i suppose i only must separate values with "zone" in the name!?
Ok, i will try it (again)... ;)
_____________
Edit:
If you are doing this, not only take values beginning with the string "zone". There is also a value called "num_zones" you should save, otherwise it's very probable that the number of zones displayed in the Xvid configuration window is not correct.
loni_blues
19th January 2005, 00:40
Hi,
I am getting some colour artifacts in B&W scenes (remnants of colour in some parts of the picture after a sudden change in the movie from colour to B&W). Sorry if this isn't new, but I hadn't noticed it before.
Regards,
loni_blues
Koepi
19th January 2005, 01:05
Originally posted by loni_blues
Hi,
I am getting some colour artifacts in B&W scenes (remnants of colour in some parts of the picture after a sudden change in the movie from colour to B&W). Sorry if this isn't new, but I hadn't noticed it before.
Regards,
loni_blues
This happens if a scene change isn't detected as such (thus the I-frame is missing so the picture gets "all b/w").
Let's see if sysKin has an idea how to solve this. Most probably you have a source where the difference between the coloured scene and the b/w scene is minimal, so there's no clear cut/scene change when switching from colour to b/w?
Cheers Koepi
RadicalEd
19th January 2005, 01:35
Well, the obvious answer would be to add a special case to scenechange detection involving the zeroing of the chroma planes. For now, you could just make the b/w segment a zone.
Koepi
19th January 2005, 09:55
...and force the keyframe that way. Good idea. (Not even a need for using greyscale encoding - there shouldn't be any colour artefacts in the original, right? ;) )
Cheers
Koepi
Dams
19th January 2005, 10:14
Is this build can be called "stable" as I use only VBV for my home standalone player (Keyplug 4810) , because I don't use any "pro" feature like BF or other things like this ?
Is VBV before this build , worked only on first pass ?? (- {core}: VBV support in 2pass mode )
I use actualy Nic build 13/12/04 compiled 8.1 Intel
Ps : I've got an Duron 1.6@2.2 Ghz
SirCanealot
19th January 2005, 12:48
Is anyone having any problems with rate control?
I have a file I want to encode to about 925kbs, but I'm having to set it to around 880kbs to hit my target filesize.
I have VHQ4(+B-Frames) on, Trellis Quant on, quants set to 2-31, chroma motion on, MSP on 6, cartoon mode on, and everything else is just about defaults.
If there isn't a probolem, I guess there might be some sort of problem with my first-pass data - I think I'll run another one...
CruNcher
19th January 2005, 16:47
Don't use cartoon mode it's bugged
SirCanealot
19th January 2005, 17:12
Originally posted by CruNcher
Don't use cartoon mode it's bugged
Just in this version? :/
Sharktooth
19th January 2005, 17:38
I feel confident it will be fixed before the final release.
OMINUS
19th January 2005, 18:40
something i am confused about
when i want to encode a full b/w movie do i have to enable both
<begin with keyframe> and <greyscale> or just <greyscale>?
lark
19th January 2005, 18:47
just grayscale.
but enabling begin with keyframe doesn't hurt, since the 1st frame will be key anyway...
regards
t :)
Marcel
19th January 2005, 19:45
Originally posted by Marcel
I like to encode short funny clips for my mobile (Nokia 3650), 208*1xx pixels, 12.5 or 15 FPS. File size doesn't matter, so I go for Q5 or Q6. In some scenes this throws the bitrate above 200 kbit/s, where the SmartMovie Player starts to cry for more performance (but I didn't find any Socket 775 inside the phone yet, any help on that? ;)). That's a case where 1pass with VBV is useful - or did I get the whole VBV idea wrong?
Resorted my thoughts.
VBV adjustments can only be done by selecting a profile, right? This leaves me with 654720 bits of buffer size and a bitrate of 128 or 384 kbit/s. First too low, second too high.
Maybe I should stick with 1pass, target bitrate of 200 kbit/s or something like that (should depend on the number of pixels per frame) and minimum quantizer = 5 (Q4 gives no visual improvement over Q5 on that tiny 4096 colors screen). All these VBV values are a matter of intense testing, as the video player is not based on hardware, but on software.
Prettz
19th January 2005, 21:02
Originally posted by peteag
Does XviD contain all features of the ASP-standard now or is it far away from this (4mv, slices etc.)? Same the decoder?
No one more knowlegeable than me has bothered to answer you so I'll take a crack at it.
I believe that Xvid does support all of the defined ASP features. It's had 4mv for years, has b-frames and s-frames with 3 warp-point GMC (if that's what you meant by "slices"), Q-pel, custom quant matrices, adaptive quantization, reduced resolution, and allows you to limit the encoder to a certain profile and level. I think that's everything.
bond
19th January 2005, 21:16
regarding mpeg-4 asp, xvid doesnt support error resilience, thats it i think ;)
bREAkDoWN
19th January 2005, 21:48
Originally posted by madness
Hi all, when I encode videos in xvid I tend to have closed gov enabled, but on this beta I found the closed gov option is gone. Is it been disable for this beta or it got replaced Rate-Distortion mode decision for bvops?
Thanks.
Good question, but i haven't still found the answer. Can someone of the xvid gurus ;) answer?
Bye!
squid_80
19th January 2005, 22:02
Originally posted by bREAkDoWN
Good question, but i haven't still found the answer. Can someone of the xvid gurus ;) answer?
Bye!
I'm no guru, but looking at vfw/src/codec.c it would seem that yes, closed gov is now always on if bframes are enabled.
RadicalEd
20th January 2005, 00:38
Originally posted by Prettz
No one more knowlegeable than me has bothered to answer you so I'll take a crack at it.
I believe that Xvid does support all of the defined ASP features. It's had 4mv for years, has b-frames and s-frames with 3 warp-point GMC (if that's what you meant by "slices"), Q-pel, custom quant matrices, adaptive quantization, reduced resolution, and allows you to limit the encoder to a certain profile and level. I think that's everything.
Reduced res isn't a feature of ASP, and incidentally isn't supported by XviD anymore.
XviD lacks some of the other rate control mechanisms besides VBV (namely VCV and VMV), but they're largely inconsequential.
riggits
20th January 2005, 09:10
Originally posted by SirCanealot
Is anyone having any problems with rate control?
I have a file I want to encode to about 925kbs, but I'm having to set it to around 880kbs to hit my target filesize.
I have VHQ4(+B-Frames) on, Trellis Quant on, quants set to 2-31, chroma motion on, MSP on 6, cartoon mode on, and everything else is just about defaults.
If there isn't a probolem, I guess there might be some sort of problem with my first-pass data - I think I'll run another one...
I've gotten undersized encodes from changing the min. quantizers to 2. Back to 1 and I get perfect size every time. Cartoon mode also gimps things a bit.
Jackzeripper
24th January 2005, 11:53
Hello,
Many many thanks for the VBV support on XviD1.1 beta. It’s a great feature that seems to work perfectly (2 tests OK : bitrate beyond 3000k in AS@L4).
The new DNX profile with 4000k max bitrate is quite good for standalones.
Thanks for your great work !
A french fan
TripleA
24th January 2005, 14:39
Hello.
I'm cooking a one DL DVD collection of the Lord of the Rings trilogy Special Extended Edition.
I'm getting corrupted frames with XviD-1.1.0-Beta1-16012005 (Koepi's build, if it makes a difference. And January 16th is my birthday, btw, so thanks for the gift!;)). I noticed this corruption in the second and third parts, but not the first. Though they were all encoded in sequence in one session using essentially the same settings (credits treatment differed for Return of the King).
I checked an earlier encode made using XviD-1.1.-127-13102004 and the same frames are OK. But I haven't watched an entire encode made using the earlier build yet, so I cannot be sure the issue is not present elsewhere. I'm planning to watch a re-encode of Return of the King ASAP and I'll report then, but it may take some time since I have finals and stuff.
It looks like it could be bad RAM. But I'm quite sure my RAM is OK since it was extensively tested using MemTest86+ not too long ago (a 3 day run, if I remember correctly, less than 6 months ago). And my system is reasonably stable: it got through two passes of the entire LotR trilogy without a restart, for example. In fact, I don't remember the last time it crashed. So I'm pretty sure the hardware is OK.
Both XviD-1.1.-127-13102004 and XviD-1.1.0-Beta1-16012005 encodes were made using the same settings (manually re-entered after uninstall/reinstall of XviD, if you're wondering), so I'm pretty sure the bits of the software related to me are OK as well.
But I keep an open mind.
All the data related is still on my HDD. And I'm willing to help anyone who wants to investigate this in any way I can.
Here are links to a sample frame (frame #69472 of region 2 DVD set of the Two Towers SEE):
Source: http://img186.exs.cx/img186/211/frame69472source6xm.png
XviD-1.1.-127-13102004: http://img197.exs.cx/img197/5933/frame69472xvid11127131020042qh.png
XviD-1.1.0-Beta1-16012005: http://img169.exs.cx/img169/1161/frame69472xvid110beta116012005.png
Edit:
Forgot to mention XviD settings, originally. Silly me. Here:
Profile @ Level == unrestricted
Quantization type == H.264
Adaptive Quantization == 1
Interlaced Encoding == 0
Quarter Pixel == 1
Global Motion Compensation == 1
Reduced Resolution == 0
B-VOPs == 1
Max. cons. BVOPs == 5
Quantizer ratio == 1.50
Quantizer offset == 1.00
Packed bitstream == 0
Closed GOV == 1
Pixel Aspect Ratio == Square
Motion search precision == 6
VHQ == 4
Use VHQ for BF == 1
Chroma motion == 1
Turbo == 1
Frame drop == 0
Max. IF Int. == 132
Cartoon Mode == 0
All Quantization min == 2
All Quantization max == 31
Trellis == 1
Credits at const. quant == 20
Credits at Weight == 0.25 for Return of the King
Athlon XP default optimizations in effect.
YV12 AVISynth script is the source. But I don't see how that could be related considering the source frame is OK, as decoded by VDubMod (v1.5.10.1 build 2439, in case that matters).
Can't think of any other info that might be relevant. Let me know if anyone needs anything. I really want to know what's causing this. If it's my PC that's broken, I want it fixed. And if it's me, well, I want that fixed ASAP too: can't b0rk in finals season! ;)
Mug Funky
24th January 2005, 16:45
I have a file I want to encode to about 925kbs, but I'm having to set it to around 880kbs to hit my target filesize.
i get this a little. i've done a bit of testing (and i was kinda hoping someone else would notice this so i knew i wasn't mad).
i _suspect_ that VHQ b-frames are the culprits, but i only got this hunch while reading this thread here, and i'm embarrassed to say that in all my test encodes i didn't once disable VHQ b-frames :)
one thing i've noticed is that the cleaner the source, the more accurate the rate-control is. this is very strange, but thinking out loud it does indeed seem like the b-frames might be causing this somehow (b-frames are quanted higher, therefore more noise will be removed from them and not considered during ME? but when there's no noise to start with, the deviation is much smaller? am i even close?)
if you've got any real noisy video, play with that and see what happens. i'll do that too i guess :)
BTW, thanks y'all for this xvid milestone. without you guys, we'd all be using Divx (TM) or, god forbid, WMV.
[edit]
okay, looks like VHQ bframes doesn't hurt ratecontrol. it's something else :(
anyone can test this by adding noise to a source, or possibly just using a noisy source and sharpening it. shoot for smaller frame-sizes (my machine is slow, so i'm doing tests at 320x240, which may not be representative of xvid's performance on larger frames).
[edit 2]
tried it on full pal d1, interlaced, with the same result.
i also tried a few other versions (including 1.0.x), and they all seem to be thrown off by the amount of noise in an encode. i guess it's fine if your movie is long enough, as i've never encountered really undersized encodes for full-length stuff. anything over about 5 minutes long is pretty solid for 2-pass. i might have to set a long, noisy encode going to check this out (bladerunner springs to mind)
[edit 3]
tried the first few chapters of the good, the bad and the ugly, r4 PAL, using varying lengths to see if the undersizing improved with the length of the encode. it looks like it does somewhat.
all encodes start at frame 4329, and target bitrate is always 1000kbps . scene is when it fades up from the opening titles to some guy's face... i confess i haven't actually seen this film, but i figured "it's old, so it'll be grainy", and i couldn't find blade runner. as it turns out, the clip isn't all that grainy, but the picture shakes a tad and there's spots on the film in parts, as well as a fair bit of mosquito noise.
1000 frames, 821kbps
2000 frames, 837kbps
4000 frames, 907kbps
8000 frames, 929kbps
i'd call the 929kbps encode an acceptable deviation from target bitrate, but that's 5 mins 20, which is a bit long for a ratecontrol to stabilize. if you're encoding music clips, or doing a movie by chapters (not that anyone would do it like that...), this could be a problem.
settings: 2-pass, target 1000kbps, h.263 matrix, VHQ1+bframes, turbo mode, fast 1st pass, halfpel, no GMC, no AQ, no chroma motion (no difference with these on though). i haven't tested trellis yet.
Jan Marijniszoon
24th January 2005, 17:31
I might have seen the same bug as the person above...
I was encoding the Matrix (re-mastered and PAL version) just for fun.
I encoded the dojo-fight, the lobby, the trinity chase, neo stopping bullets and the fight with smith in the subway.
Everything went fine, except there is an error in the subway sequence. I used the newest XviD to decode. I also tried libavcodec both in Windows and Linux (with mplayer), but it gave the same error.
I used this script for the scenes:
LoadPlugin("DGDecode.dll")
LoadPlugin("warpsharp.dll")
MPEG2Source("matrix.d2v")
Crop(0,80,-0,-80)
sxsinput = last
targetwidth = 1024
targetheight = 416
sxsinput.Lanczos4Resize(targetwidth*4, targetheight*4)
XSharpen(255, 255)
Lanczos4Resize(targetwidth, targetheight)
And I used this settings for XviD:
SINGLE PASS with QUANT 3
Profile UNRESTRICTED
MPEG-CUSTOM --> Didees SixOfNine Max=20.qmatrix
Adaptive Quantifisation
Quarter Pixel
GMC
B-VOPS: 2
1.50
1.00
Packed bitstream = OFF
Closed GOV = ON
Aspect Ratio DEFAULT
Chroma motion = ON
Motion search = 6
VHQ = 4
VHQ for b-frames = ON
Frame drop ratio = 0
Maximum I-interval = 250
Cartoon Mode = OFF
All Quant restrictions are MIN 2 and MAX 20
Trellis = ON
Chromo optimizer = ON
And finally, here you can find the screenshots:
http://members.lycos.nl/LudoSanders/video-images/
I hope this didn't sound too lame or something. But I think XviD is so great, that I should help in case this might be an important bug.
b0b0b0b
24th January 2005, 18:23
I think they need a clip from your xvid encode to debug
Didée
25th January 2005, 09:20
I did a full movie encode (only 1 up to now :o) with Koepi's build, and experienced no errors.
Jan Marijniszoon, you should cross-check if the same errors occur on the same frames when you encode the same script again with the same settings.
Your 4*SSXSharpen-script is somewhat memory consuming, and I see no SetMemoryMax() in your script. It could well be possible that e.g. Windows did some strange things while swapping memory in&out ... especially if did anything else with the PC, during encoding.
edit: Swapped end by and, Xoepi by Koepi, ...
Jan Marijniszoon
25th January 2005, 11:00
I left the PC entirely alone during this encode.
Could you explain me more about that max memory setting?
Isn't it very strange that Windows (I use Win2k with the latest updates) should cause an error just like that?
I say this, because I also encoded alot of scenes from Reloaded and Revolutions with exactly the same script. I only used XviD 1.0 with them and there was never any error to be spotted.
Koepi
25th January 2005, 11:28
Originally posted by Didée
edit: Swapped end by and, Xoepi by Koepi, ...
I assure you that I'm not Xsexual or anything like that :D Thanks for changing that! ;)
Jan Marijniszoon:
Can you test the same script and sequence with another codec and check for an error in that place? Also, as Dideé noted, something fishy can happen if your system isn't absolutely well tuned and swapping is going on. So a second test with the same script and xvid-1.1-beta1 to recheck that it wasn't something random would be nice.
[Some background to this recommendation: computer components get affected by aging, too. Just because your system worked well until now doesn't mean that i.e. the memory is still 100% in order. Imagine you overclocked your system for playing a game or so, and now your system is back to normal settings. Due to the higher temperature your chips were working at, the aging of the components did accelerate by a noticable amount (rule of thumb: 10°C hotter means only half the longevity of a microchip if operated always at that temprature.)
If you did use a higher voltage for your chips it gets even worse, current CPUs/memory chips use structures that small that the electron flux can lead to material weakening. And so on.]
You used a custom quant matrix. Is the error reproducable with MPEG or h263 quantisation?
Thank you for testing that,
cheers
Koepi
EDIT: corrected "migration" to "flux". That's quite a difference %)
Didée
25th January 2005, 11:34
I didn't say "that IS the cause", I said "that *could* ... ".
Isn't it very strange that Windows (I use Win2k with the latest updates) should cause an error just like that?General rule: never trust Windows.
I say this, because I also encoded alot of scenes from Reloaded and Revolutions with exactly the same script. I only used XviD 1.0 with them and there was never any error to be spotted. If you have a scene that produced erroneous frames, please repeat that encoding with the very same script, codec settings, etc. If the errors are 100% reproduceable, then the problem can be tracked down. If the errors are not reproduceable but random,
then the cause is random.
BTW, if you like 4*SSXSharpen, you might like this (http://forum.doom9.org/showthread.php?s=&threadid=84196) even more - same quality if not better, only that it's a little faster ;)
edit: should learn to refresh before submitting posts ...
yaz
25th January 2005, 15:36
Originally posted by Didée
If you have a scene that produced erroneous frames, please repeat that encoding with the very same script, codec settings, etc. If the errors are 100% reproduceable, then the problem can be tracked down. If the errors are not reproduceable but random,
then the cause is random. sounds good but what if different ppl produce the same error but each only once? :-)) ok ...
i had the same problem as triplea and jan had. it had happened at a high motion scene and looked exactly the same as on jan's pictures. at a moment the high motion part of the scene fall apart to moving blocks. as the quantizers were raised extremely on that part.
my 1st guess is(was) vbv as only that relases produce such problems which officially has working vbv. so, now i'm on testing different profiles up to 'unrestricted'.
my next guess is the rate-controll part which was cleared a week ago or so. but, amof, i don't know how to test that part.
the bests
y
Didée
25th January 2005, 15:59
Got your point, yaz - and I think you got mine.
I know there were quite a few bug reports about latest build from koepi, most or all about corrupted or blocky frames. But if one hundred people just state "look here: bad frames! That's a bug!" and nothing else, it doesn't help all too much in tracking the bug ...
But my quote (should) stay true: if bad frames are produced indeed by the codec, then the errors should be 100% reproducable when repeating the *very same* encoding setup - there's not much room for "chance" on the encoding side :)
So, if repetition of the very same encoding shows no errors, or errors in a different place, then probability is high it's something else, but not the codec.
BTW, didn't CruNcher report "Cartoon Mode" were a little br0ken?
yaz
25th January 2005, 16:19
@didée
yes, u're right, an error must be reproducible so as to track down. no doubt. i'm back on testing (and reproducing:-)
the bests
y
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.