Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > New and alternative a/v containers

Reply
 
Thread Tools Search this Thread Display Modes
Old 13th October 2021, 19:37   #24701  |  Link
KoD
Registered User
 
Join Date: Mar 2006
Posts: 567
I've just switched from the official release LAVFilters-0.75.1 to the LAVFilters-0.75.1-7 nightly, and run into an issue when playing some bluray ripped ts files over the network (samba shares from another Windows PC). This is with madVR as renderer in MPC-BE 1.5.8.6300 (the most recent 1.5 version). At exactly the same points in the file, the playback starts stuttering massively, queues get depleted to 1-8 in madVR and never recover. These are ts files form a ripped bluray, nothing special about them, they're plain 1080p H264 + pcm 2.0 48KHz files.

The issue does not happen when I play the files from a local SSD, only when playing over the network. I've copied the files on the remote Windows PC from one of its disks to another, but the stutter happens the same way even from the new location, at exactly the same points in the file.

When I transfer the files on the remote Windows PC from one of its disk to another it's a constant >100MB/s transfer rate, so it's not an issue of file fragmentation. When I access the files over the network, it's a constant 80 MB/s transfer rate, with no drops whatsoever. A ping to the Windows PC from the computer that plays the file to the computer that hosts the file shows 2-4ms pings, with no variations. This makes me believe it's not an issue of latency or transfer speed.

And the stutter does not happen with the official 0.75.1, either.

Is there a way to run a debug version of the recent version of lav filters with some tracing enabled to identify where the issue lies?
KoD is offline   Reply With Quote
Old 14th October 2021, 09:56   #24702  |  Link
ryrynz
Registered User
 
ryrynz's Avatar
 
Join Date: Mar 2009
Posts: 3,479
Quote:
Originally Posted by KoD View Post
Is there a way to run a debug version of the recent version of lav filters with some tracing enabled to identify where the issue lies?
Most likely the update to ffmpeg, try running LAVFilters-0.75.1-3 and confirm LAVFilters-0.75.1-4 is where the issue begins.
ryrynz is offline   Reply With Quote
Old 14th October 2021, 10:03   #24703  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,144
There were no significant changes of any kind since 0.75.1 that should effect such behavior, either in LAV or in FFmpeg, since FFmpeg updates are currently coming from a release branch until the next FFmpeg release, which only contains security fixes.
But all nightly builds are available, so you could try to figure out where it started, if anywhere.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders

Last edited by nevcairiel; 14th October 2021 at 10:06.
nevcairiel is offline   Reply With Quote
Old 15th October 2021, 10:35   #24704  |  Link
KoD
Registered User
 
Join Date: Mar 2006
Posts: 567
I repeated my tests and I eventually run into the issue when using the official 0.75.1 version of the LavFilters too, even though previously they worked fine.

I noticed the issue did not happen with other video renderers, only with madVR. And it seems to be triggered by a setting in madVR.

The "madVR settings -> rendering -> general settings" contains two options:
- delay playback start until render queue is full
- delay playback start after seeking, too

I had "delay playback start until render queue is full" enabled since forever, and this does not cause any problem.
I have recently enabled "delay playback start after seeking, too", and unfortunately this seems to be the cause of the sudden stutter and queue depletions in madVR after seeking in the file.

In order to reproduce the playback issue, I kept seeking to the file location where I knew the issue would manifest itself, then I paused the playback to refill the madVR buffers (because the madVR queues get depleted right away after seeking when playing a file over the network), and then resumed playback. Playback would resume, but when hitting certain points in the file the madVR queues would suddenly start to deplete and would not resume by themselves anymore. Pausing the playback would refill them, and on resuming playback everything would work again for a while and then the queue depletion would occur once more, and so on.

I can't really explain why the madVR queue depletion would happen at pretty much the same points in the file. What I can say is they don't happen anymore with that second setting disabled.

The issue only manifests itself on high bitrate content (like a 7GB ts file for a 25 minute anime episode), and not on low bitrate content like a 2 GB 45 minutes TV episode DVD file ripped to a mkv. It also does not happen when playing the same high bitrate file from a local SSD. Maybe the issue is triggered when playing from a SSD too, but it recovers too quickly to notice the stutter, while it never recovers when playing over the network.

Additional playback details would be: video decoding is done using D3D11 hardware acceleration in lav video, on automatic setting (so, native decoding). The GPU is a RTX 3090. The CPU is a Ryzen 5900x, so this should not be a bottleneck either. The video player is MPC-BE 1.5.8.6300. The MPC-BE audio renderer is used for WASAPI exclusive playback (using events). All "trade quality for performance" settings in madVR are disabled. madVR is using Direct3D 11 for presentation, but with "present a frame for every VSync" disabled. madVR "automatic fullscreen exclusive mode" is disabled too (as it makes sense no more on Windows 10 anyway). I have the lav video "Deinterlacing mode = Aggressive", because it would otherwise miss deinterlacing old DVD TV episodes (Star Trek Voyager ones, for example), but this should not matter on the progressive material I experienced the issue, and madVR does not do deinterlacing in d3d11 native mode anyway (I have to disable native d3d11 decoding in lav video when watching such deinterlaced material, by selecting explicitly the GPU to use for decoding, as only then madVR deinterlaces the video content).

One more thing is that using in madVR settings "rendering -> windowed mode -> after last render step = flush and wait (loop)" instead of the default "flush & wait (sleep)" makes the stutter events occur less, and allows more intensive scaling algos to work without frame stutters even on the integrated graphics of a i7 4790K CPU in another system (with all "trade quality for performance" settings disabled there, too). More intensive scaling algos in this case means Jinc for upscaling, SSIM for downscaling, and super-xbr for chroma upscaling, using correct linear light-scaling and with the anti-ringing filter enabled.

Last edited by KoD; 15th October 2021 at 11:09. Reason: additional details
KoD is offline   Reply With Quote
Old 15th October 2021, 16:28   #24705  |  Link
clsid
*****
 
Join Date: Feb 2005
Posts: 5,360
Increasing the queue settings in LAV Splitter could help in your case.
__________________
MPC-HC 1.9.16
clsid is offline   Reply With Quote
Old 15th October 2021, 16:55   #24706  |  Link
KoD
Registered User
 
Join Date: Mar 2006
Posts: 567
Increasing the queue size in lav splitter was one of the things I tried without effect, unfortunately.
KoD is offline   Reply With Quote
Old 18th October 2021, 10:31   #24707  |  Link
vanden
Registered User
 
Join Date: Sep 2007
Posts: 96
Hello,
Here are my previous post
https://forum.doom9.org/showthread.p...58#post1935458
https://forum.doom9.org/showthread.p...23#post1935623

I have a BUG with Windows 10 Enterprise 1903 1909 2004 20H2 21H1 21h2 ...
All other version (from 1809) works normally.
HP DL580G5 PC (4 x Xeon X7460) 32Go Ram and GTX 650 Ti.
I also tested a GTX 770 with Windows 10 Enterprise 21H1 et 21H2 : Same result.
This PC does not support the GTX 960 and GTX 1060 ... impossible to have a GPU decoding!
Test with Nvidia driver 425.31, 456.71, 472.12.
Sound blaster X-Fi Xtreme Audio sound card in analog 24bits / 96Khz.
it works the same if I choose the SPDIF.
Driver XFXA_PCDRV_LB_WIN8_1_05_0001
The tests below are made with Nvidia driver 425.31 (the last to do 3D).

Testing an UltraHD Blu-ray with Windows 10 Enterprise 1809 :
MPC HC 1.9.16 + LAV 0.75.1.4 + MadVR 0.92.17 :
https://i.ibb.co/3FPDQDN/1809.jpg
I took a fullscreen windowed screenshot, because a Windows 1809 screenshot does not work in Exclusive. But in Exclusive it works well.

Test with Windows 10 Windows 10 Enterprise 21H1 (update from Windows 10 2004) :
MPC HC 1.9.16 + LAV 0.75.1.4 + MadVR 0.92.17 :
https://i.ibb.co/Jr4v6K8/21h1-16.jpg
https://i.ibb.co/0hCR3r5/21h1-32.jpg
https://i.ibb.co/5rTVT8b/21h1-128.jpg
I made screenshots in Fullscreen windowed, Windows 21h1 works well in Exclusive. I could have made an exclusive screenshot.
I tried several values for "decoder queue", "upload / dxva / render queue" and "present queue".

I did a clean installation (blank disk / USB key Windows 10 21H2) same results !
MPC HC 1.9.16 + LAV 0.75.1.4 + MadVR 0.92.17 :
https://i.ibb.co/9s6rCFD/21h2-16.jpg

Test with Windows 11 Enterprise 22000.194 ((update from Windows 10 21H1) update from Windows 10 2004) :
MPC HC 1.9.16 + LAV 0.75.1.4 + MadVR 0.92.17 :
https://i.ibb.co/3CcKYNC/22000-194.jpg
When it works it's OK ... but sometimes there is nothing to do, even after a reset of the graphics card (reset CRU Or MadVR "Custom modes" "remains GPU") you have to restart for it to work ...

I did a clean installation (blank disk / USB key WIndows 11 22468) …
MPC HC 1.9.16 + LAV 0.75.1.4 + MadVR 0.92.17 :
https://i.ibb.co/vLw7Nt3/22468.jpg
And the miracle it works nickel! even a little better than Windows 10 1809 !! a little less resource on the cpu.

I did a clean installation (blank disk / USB key WIndows 11 22000.282) it works the same (WIndows 11 22468).
MPC HC 1.9.16 + LAV 0.75.1.4 + MadVR 0.92.17 :
https://i.ibb.co/HrTM4jZ/22000-282.jpg

The only solution is to switch from Window 10 1809 to Windows 11 ... if this is possible with the final version ... ??

Last edited by vanden; 19th October 2021 at 22:53.
vanden is offline   Reply With Quote
Old 18th October 2021, 13:56   #24708  |  Link
clsid
*****
 
Join Date: Feb 2005
Posts: 5,360
Test with DXVA Checker:
https://bluesky-soft.com/en/DXVAChecker.html

In your Windows 10 screenshots the GPU is labelled as "GPU 2" and "GPU 1". So there might be an unwanted GPU 0 with generic MS driver.

Tip: with D3D11 hardware acceleration in LAV you can choose the GPU that it should use.
__________________
MPC-HC 1.9.16
clsid is offline   Reply With Quote
Old 18th October 2021, 23:54   #24709  |  Link
vanden
Registered User
 
Join Date: Sep 2007
Posts: 96
Quote:
Originally Posted by clsid View Post
Test with DXVA Checker:
https://bluesky-soft.com/en/DXVAChecker.html

In your Windows 10 screenshots the GPU is labelled as "GPU 2" and "GPU 1". So there might be an unwanted GPU 0 with generic MS driver.
Tip: with D3D11 hardware acceleration in LAV you can choose the GPU that it should use.
it's the same with windows 10 1809 ...
I redid the test in GPU0: it still works well.
https://i.ibb.co/CJ752kS/1809-GPU0-128.jpg
I redid the test with Windows 10 21H2 in GPU0: it doesn't work better ...
https://i.ibb.co/TkKk8Zq/21h2-GPU0.jpg
https://i.ibb.co/MsBdm6N/21h2-GPU0-16.jpg

But I wonder where it came from ... in fact it's CRU (Custom Resolution Utility). When I do restart64 the GPU increases by 1 ...

Last edited by vanden; 18th October 2021 at 23:57.
vanden is offline   Reply With Quote
Old 19th October 2021, 00:28   #24710  |  Link
clsid
*****
 
Join Date: Feb 2005
Posts: 5,360
Your "working" 1809 screenshots show high CPU usage. So why do you think hardware accelerated DECODING is active there? Are you just looking at the GPU usage graph in task manager? That is WRONG!!! The newer Win10 versions do not show all activity in the graph. Change DXVA scaling in madVR to something else, and you will probably see the GPU 3D usage increase.

MPC-HC will show "H/W" in the status bar when hardware accelerated decoding is active. It is as simple as that.
__________________
MPC-HC 1.9.16
clsid is offline   Reply With Quote
Old 19th October 2021, 05:25   #24711  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,144
A 650 Ti is far too old for HEVC hardware acceleration. In general HEVC isn't supported before Pascal (1000 series), with one exception, the GM206 chip used in the 950/960 (but no other 900 series cards). Most definitely not in 600 series.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 19th October 2021, 09:46   #24712  |  Link
vanden
Registered User
 
Join Date: Sep 2007
Posts: 96
Quote:
Originally Posted by clsid View Post
Your "working" 1809 screenshots show high CPU usage. So why do you think hardware accelerated DECODING is active there? Are you just looking at the GPU usage graph in task manager? That is WRONG!!! The newer Win10 versions do not show all activity in the graph. Change DXVA scaling in madVR to something else, and you will probably see the GPU 3D usage increase.

MPC-HC will show "H/W" in the status bar when hardware accelerated decoding is active. It is as simple as that.
Quote:
Originally Posted by vanden View Post
This PC does not support the GTX 960 and GTX 1060 ... impossible to have a GPU decoding!
Quote:
Originally Posted by nevcairiel View Post
A 650 Ti is far too old for HEVC hardware acceleration. In general HEVC isn't supported before Pascal (1000 series), with one exception, the GM206 chip used in the 950/960 (but no other 900 series cards). Most definitely not in 600 series.
Yes that's it and as already said 900 and 1000 impossible on it.
vanden is offline   Reply With Quote
Old 19th October 2021, 15:52   #24713  |  Link
el Filou
Registered User
 
el Filou's Avatar
 
Join Date: Oct 2016
Posts: 836
There were changes to the CPU scheduler in 1903 (notably to better support architectures like Ryzen that can have different latencies between different cores from the same socket), this definitely looks like a Windows scheduler issue. I don't know if it would even be possible for the application (LAV + madVR) to fix that.
Maybe the fact it's Windows Enterprise has something to do with it too, of course using Pro you would only get half the sockets.
I would try posting this in a more general-purpose Windows forum to see if maybe people know settings to fine-tune the CPU scheduler to make it behave more like 1809.
That Xeon won't be officially supported by Windows 11, but maybe with a clean install from a ISO it will install.
__________________
HTPC: Windows 10 20H2, MediaPortal 1, LAV Filters/ReClock/madVR. DVB-C TV, Panasonic GT60, Denon 2310, Core 2 Duo E7400 oc'd, GeForce 1050 Ti 466.27

Last edited by el Filou; 19th October 2021 at 15:56.
el Filou is offline   Reply With Quote
Old 19th October 2021, 16:09   #24714  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,144
The decoder queue appears to be full, thats where LAVs involvement ends. In any case, LAV is not designed for multi-CPU systems, and I do not plan to put any effort into such setups either. You could try to externally constrain it to one CPU to avoid high latency between CPUs, but thats all I got.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 19th October 2021, 16:48   #24715  |  Link
vanden
Registered User
 
Join Date: Sep 2007
Posts: 96
Quote:
Originally Posted by el Filou View Post
There were changes to the CPU scheduler in 1903 (notably to better support architectures like Ryzen that can have different latencies between different cores from the same socket), this definitely looks like a Windows scheduler issue. I don't know if it would even be possible for the application (LAV + madVR) to fix that.
Maybe the fact it's Windows Enterprise has something to do with it too, of course using Pro you would only get half the sockets.
I would try posting this in a more general-purpose Windows forum to see if maybe people know settings to fine-tune the CPU scheduler to make it behave more like 1809.
That Xeon won't be officially supported by Windows 11, but maybe with a clean install from a ISO it will install.
Yes I read that: https://borncity.com/win/2019/06/30/...ased-amd-cpus/
https://www.reddit.com/r/intel/comme...e_favored_cpu/
https://www.anandtech.com/show/11550...7800x-tested/7
https://www.tomshardware.fr/windows-...estion-du-cpu/


https://i.ibb.co/RvQ1zqk/1809-21-H2-22000.jpg
the 1st difference between (1507 to 1809), (1903 to 21H2) and Windows 11 is that the processors are not managed the same.
the second difference is also the use of the GPU (45% 1809, 31% Windows 11) when at (1903 at 21H2) it does not go up because : dropped frames ...

Quote:
Originally Posted by nevcairiel View Post
The decoder queue appears to be full, thats where LAVs involvement ends. In any case, LAV is not designed for multi-CPU systems, and I do not plan to put any effort into such setups either. You could try to externally constrain it to one CPU to avoid high latency between CPUs, but thats all I got.
I can select the number of cpu (By LAV or by the task manager) = it's worse !
it works very well with Windows 10 (1507 to 1809) and also with some Preview and developer of Windows 11.


but in my old post I tested EVR in bilinear algorithm:
http://vandenk.free.fr/Evr.jpg
On 1809 it works well :
http://vandenk.free.fr/1809-EVR-Bill-FSdirec3d.jpg
On 20H2 it works as well :
http://vandenk.free.fr/20h2-EVR-Bill-FSdirec3d.jpg

But look at the diferentes GPU usage 1809=44% 20H2=90% ...

Last edited by vanden; 19th October 2021 at 17:21.
vanden is offline   Reply With Quote
Old 19th October 2021, 17:21   #24716  |  Link
chros
Registered User
 
chros's Avatar
 
Join Date: Mar 2002
Posts: 2,199
Quote:
Originally Posted by KoD View Post
Additional playback details would be: video decoding is done using D3D11 hardware acceleration in lav video, on automatic setting (so, native decoding). The GPU is a RTX 3090. The CPU is a Ryzen 5900x, so this should not be a bottleneck either. The video player is MPC-BE 1.5.8.6300. The MPC-BE audio renderer is used for WASAPI exclusive playback (using events). All "trade quality for performance" settings in madVR are disabled. madVR is using Direct3D 11 for presentation, but with "present a frame for every VSync" disabled. madVR "automatic fullscreen exclusive mode" is disabled too (as it makes sense no more on Windows 10 anyway)...

One more thing is that using in madVR settings "rendering -> windowed mode -> after last render step = flush and wait (loop)" instead of the default "flush & wait (sleep)" makes the stutter events occur less, and allows more intensive scaling algos to work without frame stutters even on the integrated graphics of a i7 4790K CPU in another system (with all "trade quality for performance" settings disabled there, too). More intensive scaling algos in this case means Jinc for upscaling, SSIM for downscaling, and super-xbr for chroma upscaling, using correct linear light-scaling and with the anti-ringing filter enabled.
After last render step -> "flush & wait (sleep)" uses more CPU (visible in task manager), try out "don't flush" everywhere first (according to madshi's recommendation), it works fine here with discrete GPU (see my signature), although the performance gain is negligible with this fast GPU (I can't use e.g. NGU Sharp low vs med for chroma with HDR10 pixelshader) and there's no rendering avg/max stats on OSD (but I consider this cosmetics).
__________________
Ryzen 5 2600,Asus Prime b450-Plus,16GB,MSI GTX 1060 Gaming X 6GB(v398.18),Win10 LTSC 1809,MPC-BEx64+LAV+MadVR,Yamaha RX-A870,LG OLED65B8(2160p@23/24/25/29/30/50/59/60Hz) | madvr config

Last edited by chros; 19th October 2021 at 17:27.
chros is offline   Reply With Quote
Old 20th October 2021, 00:31   #24717  |  Link
vanden
Registered User
 
Join Date: Sep 2007
Posts: 96
Quote:
Originally Posted by nevcairiel View Post
The decoder queue appears to be full, thats where LAVs involvement ends. In any case, LAV is not designed for multi-CPU systems, and I do not plan to put any effort into such setups either. You could try to externally constrain it to one CPU to avoid high latency between CPUs, but thats all I got.
Well finally I redid the test, is it working !!
I was wrong !

but by LAV that is not enough, it must be done with the task manager on MPC HC like this :
https://i.ibb.co/QDcGvcz/Affinit-2.jpg
After you have to find the core that is the least used and we can re-light 1 ... impossible to do directly.
https://i.ibb.co/YjQhBWq/Affinit-3.jpg
The result under Windows 10 21H2 :
https://i.ibb.co/LQD7W3b/21H2OK.jpg

Last edited by vanden; 20th October 2021 at 00:34.
vanden is offline   Reply With Quote
Old 22nd October 2021, 20:45   #24718  |  Link
KoD
Registered User
 
Join Date: Mar 2006
Posts: 567
Quote:
Originally Posted by chros View Post
After last render step -> "flush & wait (sleep)" uses more CPU (visible in task manager), try out "don't flush" everywhere first (according to madshi's recommendation), it works fine here with discrete GPU (see my signature), although the performance gain is negligible with this fast GPU (I can't use e.g. NGU Sharp low vs med for chroma with HDR10 pixelshader) and there's no rendering avg/max stats on OSD (but I consider this cosmetics).
It's normal to see increased CPU usage, because it uses a loop to check for the D3D device flush to be completed instead of yielding the thread execution and letting the OS to wake the thread when it's done. Using "flush & wait (loop)" is definitely more responsive than (sleep) though, so I'll keep using it. The stutters happen with "flush & wait (sleep)" too, anyway. It's trying to fix this issue that made me switch to "flush & wait (loop)" in the end.

Regarding the stutter issues, they happen no matter what I do. The solution I thought I found was no solution at all, the stutter-after-skip-forward still happens. And it happens with MPC-VR as well, it's not just with madVR.

The buffer-depletion causing stutters happen as soon as I skip forward in a high-bitrate file in MPC, like when I play ts ripped BluRay files. All files with LPCM 2.0 audio have this issue. Pressing quickly arrow up 4 times (forward 20 sec for each press) and right once (forward 5 sec for a press) is enough to trigger the stutter. The video renderer queues get depleted, and the file stutters. Pausing the file and letting the buffers fill again and then resuming playback works for a while, but soon it starts happening again out of the blue. I can repeat this pause and resume playback many times, but as long as I don't close the file for playback, the stutters come back after a while.

The only way to keep watching the file stutter-free is to close the file and open it again (I have "Remember File position enabled in the player settings, so it starts playback from the location where I closed the player). As long as I don't skip forward or backward in the file, the stutters don't happen anymore until the end of the playback.

I tried many things, but nothing gets rid of this behavior when playing files over the network in MPC-BE or MPC-HC. I thought it might be my external USB DAC, but playing sound over the TV speakers has the same issue. I thought it might be a bug in the MPC audio renderer, but using the DirectSound audio renderers has exactly the same issue.

I thought there might be an issue with the server or the network connectivity but that's not it either. Latency measurements to the network server while playing a file shows no variations in latency at all. The transfer speed is as high as a Gbit connection allows. CPU usage monitoring on the server shows minimal usage (not surprisingly as it's an overpowered Windows PC for a file server task, running Windows Server).

The playback PC is again too overpowered to have this kind of issue. And it happens with no other processes in the background (I don't have social media apps or such running in the background, nor hardware monitoring software).

I simply don't understand why network playback has such kind of issues on such hardware, but that's how it is.

This is not a recent issue. It's been happening for years, but I had a i7 4790K system until this year, and thought that maybe it was due to that. It was not, apparently. Network playback is just as unreliable on the new system as it was on the old one when using MPC, lav filters and madVR.
KoD is offline   Reply With Quote
Old 22nd October 2021, 22:22   #24719  |  Link
clsid
*****
 
Join Date: Feb 2005
Posts: 5,360
Are you playing actual .ts files? Then the solution would be to remux into .mkv.

MPEG-TS container does not have a seek index for quick seeking, so the splitter needs to parse a lot more data when seeking.
__________________
MPC-HC 1.9.16
clsid is offline   Reply With Quote
Old Yesterday, 16:47   #24720  |  Link
flossy_cake
Registered User
 
Join Date: Aug 2016
Posts: 24
Hello

Is my understanding correct that: LAV Video D3D11 hardware acceleration could work to accelerate decoding of HEVC on older GPUs which don't natively support HEVC decoding?

I am trying to get accelerated HEVC decoding on an old R9 380 which doesn't support it natively.

Thanks

Last edited by flossy_cake; Yesterday at 17:13.
flossy_cake is offline   Reply With Quote
Reply

Tags
decoders, directshow, filters, splitter

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 10:49.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.