Jump to content

Stargazers Lounge Uses Cookies

Like most websites, SGL uses cookies in order to deliver a secure, personalised service, to provide social media functions and to analyse our traffic. Continued use of SGL indicates your acceptance of our cookie policy.

sgl_imaging_challenge_banner_solar_25.thumb.jpg.f1d5d01d306644f613efd90ef96b314c.jpg

noah4x4

Improve Windows Remote Desktop - disable RemoteFX compression.

Recommended Posts

I wasn't sure where to post this tip....it is probably of most use here....

Many of us with observatories or indoor Mission Control use Windows 10 Pro Remote Desktop to control a scope side computer running camera and scope control software from a second computer indoors. This works superbly at 1080p resolution.

However, I have struggled for a year trying to perfect a wireless solution that works with 4K UHD cameras terminating in a 4K UHD display.  Until now, whilst cat 6 cable does work fine, wireless even at 5Ghz 802.11ac has struggled with some lag and poor performance. I have spent a fortune upgrading wireless adapters and range extenders, but this isn't the issue!

Here is a solution;

1.  Seperate your dual band network into distinct 5Ghz and 2.4 Ghz channels.

This is easy with  (say) a BT Home Hub. If you don't do this, it can be a bit hit or miss whether your 5 Ghz wireless adapters connect to the right channel. You will now see TWO channels, one at 2.4 Ghz with a suffix like <hub name> and another at 5 Ghz named <hub name -5>. Connect your 5Ghz adapters to the latter. If your internal adapters are merely 2.4Ghz, you can disable them via Device Manager and plug in a USB version costing around £5. Note that at 5 Ghz wireless range might drop. If so, a Netgear EX8000 wireless extender is recommended as it employs 'mesh' technology. 

2. ONLY if you have a fast network, and powerful CPUs and quality graphics card, try DISABLE 'RemoteFX compression' in RDP.

This allows uncompressed screen data to flow across RDP.  I have found this improves performance whether using 802.11ac wireless or cat 6 cable. What RemoteFX compression appears to do is limit effective RDP speeds to under 10Mbps (due to translation times). That is crazy if you have 433 Mbps adapters,  and an 802.11ac network (or catv6 cable). Unleash the beast! Send across uncompressed data! The issue is not with speed or bandwidth, it is an artificially imposed limit in RDP.

To do this type 'Edit Group Policy' in the Windows 10 Pro search box (doesn't work in Win 10 Home). You need to drill down through about five levels of Windows Configeration Folders, and Administration Templates and Remote Desktop Services/Host folders to find a utility named <Edit RemoteFX Compression>. In that, your options are <disable> compression or <enable> a compromise mode.

If you don't know how to do this try Googling 'Disabling RemoteFX Compression' to find a lengthy Microsoft tutorial. Or visit https://docs.microsoft.com/en-us/windows-server/administration/performance-tuning/role/remote-desktop/session-hosts .

I deliberately don't here state the quick route sequence to access this deeply embedded network utility command because you are delving deep into developer/administrator territory and do need to understand what you are doing and how to revert to your original RDP settings if your network can't handle these levels of uncompressed screen data. We don't want any novice attempting this on a cheap Compute Stick on an inadequate network!

3.  When employing RDP from your computer indoors, select <WAN 10 Mbps> or <LAN 10 Mbps> as appropriate via <Options><Experience>. The default <auto-select my connectivity> often selects too low an option. The irony here is you can select this and still not enjoy faster speeds unless you have edited/disabled RemoteFX compression.

I now have Atik Infinity plus CPWI software running in an end to end 4K UHD system terminating in a 4K UHD monitor. Over 802.11ac wireless it is now rock steady.  Over cat 6 cable my system is now turbo powered. If you don't need RemoteFX Compression, don't let it restrict your network performance. It is evidently set to ensure it works on lowest common denominator networks. If you have a fast network/CPU, disable RemoteFX compression and finally release the beast of 4k UHD over RDP.

 

Edited by noah4x4
  • Thanks 1

Share this post


Link to post
Share on other sites

This looks very interesting - thank you for posting.

I run RDP between an Win10Pro laptop and Win10Pro NUC (the latter alongside the mount). The NUC is hardwired into the network via a switch whereas the laptop connects via wireless (although on occasion I hardwire that too). I suffer a lot with image quality at the laptop which can be frustrating when trying to do a remote focus operation - stars literally come and go on the laptop display although I am sure they are (would be) present on a NUC attached display if there was one.

The 'static' parts of the display are fine, it is just the dynamic parts that can be very blocky and hard to use/look at.

I'll keep you posted.

Thank you :)

Share this post


Link to post
Share on other sites
1 hour ago, stash_old said:

Please dont do this if you use RDP over the internet .

Plus better read all this as well https://docs.microsoft.com/en-us/windows-server/administration/performance-tuning/role/remote-desktop/session-hosts

Agreed, very wise, and that is why I posted the same link and expressed other cautions about this not being for novices.

But why would anybody want to run RDP over the slow Internet? It is true that with TeamViewer and other 'free' solutions you must run their equivalents over the Internet because (for example) TeamViewer want to check that you are not using it for commercial purpose. To get 'peer to peer' the current version TeamViewer subscription is around £30 per month (making Win  10 Pro a bargain). Older versions of TeamViewer still offer it free (so don't upgrade!). Others, more dubious might want to steal your data given that RDP potentially creates a vulnerable gateway (I once installed some freeware and my AV and Firewall went berserk). But both of my Intel NUCs are dedicated to astronomy, and never get used for email or banking, so there is no worthwhile data to steal. 

However, this is a sensible caution about this type of software. But I don't think disabling RemoteFX compression has any impact on this particular vulnerability. In fact, although it should help resolve the WiFi issues highlighted by Adrenaline, I have chosen to use cat 6 cable with RDP with neither computer connected to the Internet. I am then no longer vulnerable to Windows Updates, Notifications or any other c**p that is now imposed upon consumers (which annoy me more).  I installed a semi-permanent cat 6 capability when I couldn't get Windows RDP to work over wireless with 4k UHD data. If you Disable RemoteFX compression then wireless or cable RDP should work better over superior networks (like 802.11ac if wireless) as you are receiving uncompressed data. As I said, over cat 6 is is turbo powered.

 

Edited by noah4x4
  • Like 1

Share this post


Link to post
Share on other sites

Thanks for the info, using Win-7-Pro with remote-desktop over cat 5, cat 6 and an infra-red link (no wi-fi), it all works fine on i5 and i7 systems, will check out the compression options and do some tests.  What are you using

all that bandwidth for (other than RDP)?

Edited by nightvision

Share this post


Link to post
Share on other sites
3 hours ago, noah4x4 said:

But why would anybody want to run RDP over the slow Internet?

Believe or not there are lots of people who have true remote obsys - not just in their garden ?

Plus you could of course just build a warm house as part of an obsys and do away with Remote working of any type and get max speed for your type of set up. ?

Share this post


Link to post
Share on other sites
3 hours ago, nightvision said:

Thanks for the info, using Win-7-Pro with remote-desktop over cat 5, cat 6 and an infra-red link (no wi-fi), it all works fine on i5 and i7 systems, will check out the compression options and do some tests.  What are you using

all that bandwidth for (other than RDP)?

This is the really odd thing. I am not convinced actual network speed/bandwidth is the relevant factor, and I can't fully work out why the improvement occurs after turning off RemoteFX Compression. This is my theory......

I have an Atik Horizon camera with a 16 megapixel resolution (4,644 × 3,506) which is connected by USB3 to my scope side Intel NUC with Iris Plus 640 Graphics running in 3840 x 2160. That is handling Atik Infinity software (or SG Pro), PWCI and Focusser.  If that was directly connected to a 4K UHD monitor then I get a super display etc.

However, the scope side NUC is instead running 'headless' and connected to a second NUC indoors (also with Iris Plus 640 ) Graphics. The connection is EITHER by 802.11ac wireless or cat 6 cable over Windows Remote desktop. The NUC indoors then outputs to a 4k UHD monitor.

If using a camera and display at (say) 1080p 'HD' this route works without difficulty. It will also work with lesser computing power. But with large sensor high resolution CMOS cameras it is more challenging. But native speed/bandwidth is probably not the problem.

Cat 6 also works OK with 4K UHD screen data, but isn't 100% perfect. However, over wireless at 4K UHD there is distinct lag and splutter. I initially, quite logically, attributed this to the fact that 4K UHD 'end to end' requires the transmission over Remote Desktop of 4 x as much screen data as 1080p HD. I spent £££'s upgrading my wireless adapters to 5GHz capable of handling 433 Mbps. But still no improvement. Then somebody drew my attention to these far deeper RDP Group Settings.

Windows Resource Monitor was suggesting under 10Mbps was applicable for either 1080p or 4k UHD display.  However, I think that is false. It is simply the rate required for the compressed RemoteFX data. This data once indoors  isn't enough to maintain a sufficient quality display standard for wireless 4K UHD. It wasn't ideal over cat 6a. Yet both routes had speed and bandwidth in abundance. How odd!!!!

After disabling RemoteFX compression, I think this permits the full native uncompressed screen data to flow between the computers, which an 802.11ac 5 Ghz network can comfortable handle. This results in superior quality uncompressed screen data arriving on the NUC indoors and hence to the 4k UHD display. The lag I had previously suffered over wireless has gone, and if I use cat 6 cable that has become positively turbo charged. 

If you don't have performance issues, then don't change anything. But if you have a 16 megapixel resolution camera, this might be the solution you need to enhance performance over wireless or cat 6. In the latter case, RDP is similarly unnecessarily compressing screen data. Let it flow in its native uncompressed format and an improvement is likely. But you do need plenty of computing 'ooomph' and a good quality network. 

I think this makes sense, and the default RDP settings simply assume a worst case scenario (low speed/bandwidth). What this does is remove the shackles of compression and let the full volume of screen data to flow. 

Edited by noah4x4

Share this post


Link to post
Share on other sites

You are correct in what you are saying except RDP is design for multiple users  doing RDP either  corporate to corporate or from home to work .

It would be simply madness for Microsoft to allow unbridled RDP as standard as this would totally render a network (internal or otherwise) useless using the kinds of data you are transmitting - without throttling or some other control.

One could argue that Microsoft documentation is not brilliant but then their "bread and butter" is corporate not Astrophotographers.

So if this works for you and other individuals great - just dont be on any network I use ?

 

Share this post


Link to post
Share on other sites

Have no fear Stash_Old,  there is no more chance of me "throttling" one of your networks with 4K  data than me bringing my highly illuminated giant 'UHD' monitor to a Star Party and screw up everybody's averted vision. After all, where would I park the generator truck? 

More seriously, I dont see the point of manufacturing/buying 16 megapixel cameras unless there are 4K UHD display solutions available that mirror such resolution. Sony and Samsung had already announced retail 8K display devices long before sufficient content (TV and Movies) is available to make 4K mainstream in the TV market. If anything, photography is therefore ahead of the technology curve. Typical DSLRs are now 24 megapixel and since astro cameras depend on the sensor manufacture direction for the wider sector that is probably where CMOS will head next.

Unfortunately, whether Cable, Internet or Wireless, communication technology has always lagged behind device development, largely due to the time/cost of rolling out better network solutions. Back in 2005 I was working as an investor with a Los Angeles company that had developed "emailVideo" . It went bust solely because the prevalent cabled Internet speed was merely 28kbps and streaming even 720p video was not feasible in full screen. Today, streaming full screen 'HD' video at 1080p is routine. I am proud to be amongst EAA participants at the cutting edge of 4K photography leading the way towards finding solutions to the question "how do we wirelessly stream 4K screen data?". What we have discovered is arguably a bit like 'over-clocking'. I doubt if a serious IT professional would attempt that on his network processors, but may do it in the home to push the envelope. So I say let's unleash the beast. Disable RemoteFX compression, and enjoy a glorious wireless 4K UHD EAA experience without lag or stutter. But not beyond our home WAN. 

 

 

 

 

Share this post


Link to post
Share on other sites
22 hours ago, Adreneline said:

This looks very interesting - thank you for posting.

I run RDP between an Win10Pro laptop and Win10Pro NUC (the latter alongside the mount). The NUC is hardwired into the network via a switch whereas the laptop connects via wireless (although on occasion I hardwire that too). I suffer a lot with image quality at the laptop which can be frustrating when trying to do a remote focus operation - stars literally come and go on the laptop display although I am sure they are (would be) present on a NUC attached display if there was one.

The 'static' parts of the display are fine, it is just the dynamic parts that can be very blocky and hard to use/look at.

I'll keep you posted.

Thank you :)

It is the impact on tne "dynamic parts" where this tip delivers most noticable improvements.  Whether using RDP over wireless or cable, my progress bars and similar now run in 'real time'. A ten second frame capture will refresh the screen in 10 seconds not longer. Focus becomes easier as a result.

This has never been a problem at 1080p resolutions, but despite us having 433 Mbps 802.11AC networks it appears RemoteFX is artificially constraining data flow to under 10 Mbps to avoid "throttling" commercial networks. That is below the threshold required for 4K screen data. Unleash the beast, but I agree with Stash-_old, not over the Internet, confine it to your local Network.

  • Like 1

Share this post


Link to post
Share on other sites
On 28/02/2019 at 08:58, noah4x4 said:

<Edit RemoteFX Compression>

It's been very interesting reading this thread. I have still to implement the change because I am not convinced I'm looking at the right thing! This is all down to my lack of detailed knowledge of this aspect of the WIndows operating system.

Can you just clarify whether I edit RDS in the Computer Configuration or User Configuration section. I think my concern is really that I cannot locate the <Edit RemoteFX Compression>. It's probably me being a bit dim! Any help or clarification would be much appreciated.

Thank you.

Adrian

P.S. My NUC is connected to my laptop via a switch and to nothing else. My remote operation is over a straight-line distance of about 5 metres and I can't ever see that changing ;)

Share this post


Link to post
Share on other sites
9 hours ago, noah4x4 said:

It is the impact on tne "dynamic parts" where this tip delivers most noticable improvements. 

I've answered my own question and jumped in and made the change in what looked like the right place (latest update of Win10Pro) and bingo!

The improvement is very apparent. I've only used SharpCap with an ASI120MM so far in daylight but the improvement in image quality is very apparent. Not only is the image clearer it updates much better better and there is no sign of "blockiness".

Thanks again for passing on the tip.

Adrian

  • Thanks 1

Share this post


Link to post
Share on other sites
Posted (edited)

Adrian, I disabled it in the computer configeration (not User configeration).

Please carefully read this Microsoft Paper mentioned in both my and Stash_old's previous posts. The information required is in the section 'RemoteFX Compression'.

It's a simple toggle. Select disable. If you don't see a benefit, change it back. 

EDIT - posts have crossed Adrian. Good to hear you have had an immediate positive result. I am running a 4K camera to display system and the impact on the 'dynamic 'parts critical for control was dramatic. Helped by three clear nights, my joy this week has been monumental!

 

Edited by noah4x4

Share this post


Link to post
Share on other sites
2 minutes ago, noah4x4 said:

I disabled it in the computer configeration

That is more or less what I did - I certainly made the change in Computer Configuration. I actually selected 'Enable' and then selected 'No compression' from the drop-down menu - which I assumed was probably equivalent to 'Disable'. 

As reported above it has definitely worked.

Very pleased.

Thank you :)

 

Share this post


Link to post
Share on other sites

There are three options.

1.  Enable RemoteFX compression; 2.  Disable compression and 3. which is a compromise between reduced compression and increased memory usage (which I think is the route you have selected). Ever the bold, I went straight for the more aggressive 2. disable, but I possibly didn't need to do so as compromise  (3) might have been adequate. I am now working on the principle if it is working, don't change it!  You could experiment with both. There are other potentially useful controls over RDP, but they need careful study.

I did have a conversation with an IT expert today that echoed the advise by Stash_Old. It is probably best not do this over a busy commercial network with multiple users. But on our home WAN for our own limited purpose, it is one of Microsoft's hidden gems. When network capacity increases, Microsoft can progressively remove these shackles that are designed to constrain performance to average network capabilities. But as I have 802.11ac, I am happy to unleash this as uncompressed data. Works a charm.

  • Thanks 1

Share this post


Link to post
Share on other sites
19 minutes ago, noah4x4 said:

There are three options

Hi.

This is the screen I was faced with:

1574764521_Screenshot(1).thumb.png.33e90933edfb946e772592befba1dc8d.png

So I seem to have four options.

Have I done the wrong thing?

 

Share this post


Link to post
Share on other sites

No I think you have done this correctly if it is working for you Adrian..

When I said three (primary) options they are actually, 1.  not configured, 2. Enabled and 3. Disabled.  I went for the sledgehammer solution of 3, Disabled. This works for me.

2. Enabled is the compromise, where you then have four sub-options. I suspect option 4 in that list mimic 3 'disabled'. As I said, I don't actually know which compromise option is best. I see no harm in trying them all if there is any residual RDP performance issues. 

  • Thanks 1

Share this post


Link to post
Share on other sites

 

9 hours ago, noah4x4 said:

I think you have done this correctly if it is working

Well so far I'm impressed and anxious to see if it makes a real difference when I'm actually running an imaging session.

Just need some more clear nights!

Thanks again for highlighting this fix; hopefully others will benefit as well.

:)

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By alexwolf
      Hello!
      Today we published first release candidate to version 0.19.1 - please help us testing Stellarium!
      List of changes between version 0.19.0 and master (0.19.0.16926/0.19.1RC1):
      - Added allow to search an inactive meteor showers in Search Tool/Lists tool
      - Added 'Azimuth vs. Time' graph into AstroCalc/Graphs tool
      - Added feature to show tracks for latest several selected planets (GH: #539)
      - Added calculation and showing the orbital period for artificial satellites
      - Added revolutions per day info for artificial satellites
      - Added tools for jumping to the next or previous time of rising, transit or setting for selected object (GH: #484)
      - Added new behavoir for AstroCalc/Graphs when clicking within graph area now sets current time.
      - Fixed issue in script 'Mercury Triple Sunrise and Sunset'
      - Fixed crash of Stellarium for eyepieces with permanent crosshair
      - Fixed Stellarium crash when Remote Control plugin is working
      - Fixed computation of assume radius for minor planets.
      - Fixed the issue of the scrolling not working properly on Mac (GH: #393)
      - Fixed crash in Scripting Engine (Hide artificial satellites through StelProperties in core.clear() method to avoid crash if plugin was didn't loaded)
      - Fixed planetarium crash in HiPS (network manager delete problem)
      - Fixed position problems on the Poles (GH: #391)
      - Fixed scaling Telrad sign on HighDPI monitors
      - Fixed surface occlusion bug even with landscape turned off in scripting engine (GH: #680)
      - Fixed building with cmake -DBUILD_SHARED_LIBS=ON (GH: #683)
      - Fixed error in constellation file format (Babylonian)
      - Fixed Europe/Volgograd time zone settings (GH: #686)
      - Fixed HiPS handling of allsky download (GH: #671)
      - Fixed progress bar rendering (GH: #671)
      - Fixed positive declinations issue in AstroCalc tool when option 'Use decimal degrees' is enabled (GH: #690)
      - Fixed file names inconsistency
      - Fixed constellation line in "Japanese Moon Stations" skyculture
      - Fixed file name for constellation boundaries in Stellarium User Guide
      - Fixed the user interface problems in Oculars plug-in (GH: #580)
      - Fixed getting the wrong values in objects/info method for selected object for different formats (Remote Control plugin)
      - Fixed refresh plots when AstroCalc dialog becomes visible again (AstroCalc/Graphs tool)
      - Fixed jquery vulnerability (GH: #694)
      - Fixed date and time dialog behaviour: Hour/Minute/Second spinners now correctly trigger signals dateChanged(), dateChangedByYear and dateChangedForMonth() when days, months or years are affected by it.
      - Fixed update graphs in AstroCalc/Graphs tool when days change
      - Updated planetary nomenclature
      - Updated common names of stars and DSO's
      - Updated cmake rules for Windows deployment
      - Updated DSO textures
      - Updated behaviour of HiPS survey if Stellarium started without network (GH: #681)
      - Updated GUI for ArchaeoLines plugin (GH: #689, #682)
      - Updated default pulsars catalog (v1.60)
      - Updated list of asterisms
      - Excluded Armintxe skyculture and landscape from default package
      Download link: https://github.com/Stellarium/stellarium-data/releases/tag/beta
    • By Cosmic Geoff
      On 25th March I tried some live stacking with Sharpcap and a 102mm f5 Startravel achromat & ASI120MC camera.
      Mount was Celestron SLT on custom tripod.  Image size: 1280x960.
      With this setup it is possible to dial in an object to the GoTo and be confident that it will appear on the laptop screen.
      These images may not look too exciting but they do mimic the FOV and general appearance as seen in a 203mm SCT with 25mm EP. Check the image for M87. When I checked the field in Stellarium I found that two faint non-star smudges matched with NGC4478 and NGC4476, which are 11th and 12th mag galaxies.  I am gob-smacked that I managed to image these with such modest equipment from an urban site.   There is no way I would be able to see these visually even with a C8 from here.

    • By Gfamily
      I gave a demonstration/workshop at my local Astro Group* about a simple way of removing light pollution from an Astro Photo. 
      The description I gave was deliberately for beginners, using a wide angle tripod shot photo and using one of the easiest packages to get to grips with (Paint.net). 
      The attached pdf covers the basic technique. 
      I'd appreciate any feedback on it. 
       
       
       
      * The Mid Cheshire Astronomical Group - all welcome, we meet on the last Friday of the Month.
      LP MCAG.pdf
    • By Thalestris24
      After a fistful of stars from the other night here's a few stars more from last night . Transparency was poor, though  and I had to give up in the end. As well as fitting the Lightwave 0.8x to my 80 mm F6, I've also transferred the scope to the Heq5. Although I think Sharpcap is great for live stacking it won't always detect enough stars to auto align which means I have to use guiding. I can see plenty of stars on the screen but Sharpcap refuses to share my view! I've tried noise reduction and boosted digital gain etc. I think I'll try the v3.2 beta. I might try without the uhc in future as it probably cuts out too much light when combined with the IDAS D1. All live stacked with darks and flats. Some were guided.
      M35 - 20 x 30s with IDAS D1 and UHC:

       
      NGC 2420 aka the Twinkling Comet Cluster, 30x30s:

       
      Jellyfish Neb, 40x30s:

      You can just see the edge of it with some stretching!

      More apparent with overstretch but - yuk!
      Louise
    • By JBracegirdle
      I'm new to astronomy, I got my first telescope in November (StarMax 90mm f/13), I was really happy with the view of the moon and double stars, but disappointed I could see but barely make out nebula (initially the ring nebula). I also tried to take a photo of the moon with my phone but trying to get a stable shot was too difficult, even with a basic smartphone adapter.
      I did a bit of research, found about about Video Astronomy/Electronically Assisted Astronomy (EAA) and decided I needed a better mount and took the opportunity to get a faster telescope (StarTravel 102 f5/). I really like the Sky-Watcher -102 AZ GTe with the ZWO ASI 224MC. I've only used it for 4 nights as there is so much cloud about but it's allowed me to take images of things my eyeball wouldn't see. Although my setup is below the minimum specification most would consider for imaging and entry level for visual observations I think I've found a setup that seems to work for me. I like that with SharpCap I can get instant results and the day after when it's back to cloudy I can get a bit more out of the images with Deep Sky Stacker and Gimp. I have tried looking through the eyepiece at the Pleiades, that was a pleasure as well. I can see how observing with a big Dobsonian and amazing eyepieces would be great, but many objects seem better with a camera than eyeballs. The Horsehead nebula wasn't found until astrophotography came into being.
       
      The photo above was taken on my first night with the setup. The January 2019 issue of Sky at Night Magazine has a review of the Sky-Watcher StarTravel-102 AZ GTe and they give it 4.5 / 5. Combining it with an Explore Scientific UHC filter seems to reduce most of the chromatic aberration and increases contrast relative to the stars, and light pollution.

      Video Astronomy/EAA seems to offer a great window into both the visual and imaging worlds of astronomy. As First Light Optics say "Your first telescope is arguably the most important because if the views do not amaze and delight, your interest in astronomy will crash and burn on the runway!" I understand cost could be an issue, but if the beginner had a suitable camera Video Astronomy could be as accessible as a Go-To visual setup, and seems more likely to amaze (especially in the skies of a typical house).
      My question is why is video astronomy not the first suggestion for beginners interested in both visual and imaging?
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.