Jump to content

Streaming problems


Scewbedew

Recommended Posts

I'm running DVB Server on a computer, using unicast default settings.

 

Using DVS Viewer (4.0) on another computer on the same LAN works perfectly.

 

Using the same computer over WiFi (180 Mbps), DVBViewer is virtually unusable. Picture and sound 4-5 seconds followed by a 4-5 second pause, over and over.

 

The WiFi Access Point is directly connected to the same LAN as is the DVB Server. Bandwidth is more than adequate for the streaming content.

 

Why on earth do I have such problems getting a contiguous display over WiFi?

:D

Link to comment
Why on earth do I have such problems getting a contiguous display over WiFi?

 

..because most probably this is not true:

Bandwidth is more than adequate for the streaming content.

 

The max physical speed is reduced by a huge overhead. What is left is a statistical value depending on the air_link_qualitity. Average transfer performance is not a guarantee for sufficient peak headroom.

 

I don't know which 802.11x protocol you're using. Draft n is the state of the art. Some manufacturers boost the performance of their gear by quoting compressed transfers. There nothing much to compress with live video :D

Link to comment

I use 11n.

 

The WiFi connection status normally says 180 Mbps, sometimes it goes as high as 300 Mbps...

 

I tried to copy a 600 MB file from the DVB server system to the DVBViewer system; it took 60 seconds, so I have a continuous throughput of 10 MB/s over the wireless connection.

 

What bandwidth is required for DVB streaming?

Link to comment

It isn't only a bandwith matter, transmit a multimedia stream isn't comparable to transmit a simple "static" file...

The problems arise on how the MM stream is sectioned and packetized in the WiFi transmission protocol...

Link to comment

Some additional info:

 

I tried to connect my viewer PC through my 3G phone instead of to the WiFi Access Point... with roughly the same results. It got slightly worse, but not that much.

 

So. A direct connected 180+ Mbps WiFi connection is marginally better than a L2TP tunnel through a 4 Mbps 3G phone, Internet and a firewall. Something isn't right here...

Link to comment

Additional info:

 

I've made some further investigations with Wireshark.

 

The problems start when there is a lost frame in the communication. The server reports that there is a segment lost, and a recovery procedure is executed on the wire to get in sync again. This problem can occur both when doing the file copy and when streaming.

 

During file copying, the "Previous segment lost" is reported immediately, the recovery is instant and the complete procedure have minimal (0.1 second) impact of the data flow.

During streaming, there is a 3-6 second (!) delay before "Previous segment lost" is reported from the server. Once the problem is reported, the recover procedure kicks in and works as with the file copying.

 

If the "Previous segment lost" detection were as fast in streaming as it is in file copying I don't think I would notice the network problems, but since there is a long pause these problems become very noticeable. :D

Link to comment
..maybe it's related to the buffering scheme. You could play with the buffer settings of server and client.

 

I've tried a number of combinations from very small to very large, and the results are...random, at best. Sometimes it works beautifully and I think I have found a perfect configuration. Then I try some other settings and later get back to the one that worked, just to find that it now works as bad as everything else.

 

One thing that actually seems to have made things better was to disable 11n (!?) When I go down to 54 Mbps connections, things seems to be more stable, though it is still not perfect. But for a while I actually managed to have a stable HD connection over WiFi.

 

During the tests I have had Wireshark running in parallel, and I must say things look odd. Once the connection goes out of sync due to missed packages, the client and server seems to have severe difficulties getting back in sync. Often I have to switch channel numerous times in order to get things working again. When I switch channel (after a broken connection), Wireshark often reports the *very first* frame from the client to be a re-transmission (!?) The client and server does not communicate correctly and no streaming is started. Eventually, after numerous channel switches, I manage to get the server start streaming again. These problems to get back in sync seems to be more obvious with lower buffer counts, but that could have been just a coincidence.

 

Often, I also see that streaming is actually started, but the DVBViewer window stays black. It displays frame rate and other information the status line at the bottom, but no picture. A number of channel switches later, I have picture. :)

Link to comment

Well I would say you simply have problems with you WLAN, most likely because of outside influence (collision with other wlan stations or whatever can disturb these frequencies). It would fit your description of sometimes it works without problem other times it won't.

 

Important for streaming is that your datarate NEVER goes below a certain limit. So it doesn't matter what avarage datarate you have or what bandwidth, what only matters is the actual lowest occuring datarate at any given time. We're talking just in time streaming here (LiveTV).

Link to comment
Well I would say you simply have problems with you WLAN, most likely because of outside influence (collision with other wlan stations or whatever can disturb these frequencies). It would fit your description of sometimes it works without problem other times it won't.

 

Important for streaming is that your datarate NEVER goes below a certain limit. So it doesn't matter what avarage datarate you have or what bandwidth, what only matters is the actual lowest occuring datarate at any given time. We're talking just in time streaming here (LiveTV).

 

I don't know what you mean with LiveTV, is that what I use when I run DVBServer/DVBViewer ?

 

I have no problem accepting that network problems will cause disturbance in the picture. What I have a hard time understanding is the apparent problem that the DVBServer/DVBClient has to sync after a problem. All other communication I have seen detects a missing frame within 0.1 second and immediately issues a retransmission and after that it continues as if nothing has happened. Regardless of whether it is a file transfer or some other streaming (audio streaming e.g.), the disturbance isn't noticeable unless you have Wireshark running.

 

The DVBServer/DVBViewer detects a missing frame within 5 seconds, and then spend 5-10 seconds frantically resending duplicate acknowledgments and duplicate frames until everything seems to break down completely and start from scratch. During this period I have a black screen that might flash a number of times. In worst case the connection is never synced unless I manually switch channel a number of times. And even with a manual channel switch, I can see on Wireshark that the client/server communication is broken and require a number of fresh starts in order to succeed.

Link to comment

what do you expect? it's TCP, of course the tcp stack ask for a resend if faulty tcp packets arrive. It's not done by the viewer or dvbserver.

 

Your problem is bad reception, so you have to fix this.

Link to comment
what do you expect?

 

If it's all handled by the TCP stack without any involvement of the DVBServer or DVBViewer, I'd expect that the TCP stack handled lost frames in DVB communication with the same speed and resync success as with all other communication on the same line. If it did, the visual disturbance of the lost frames would be virtually unnoticeable.

Link to comment

You could try without DVBViewer's server/client implementation (e.g. vlc or other dvb applications). Maybe they offer a better performance due to different queueing schemes.

Link to comment
I'd expect that the TCP stack

Well, you have to ask MS this, because it's part of the OS. You do seem to confuse UDP and TCP. I suggest you look it up in wikipedia or via google. This isn't the place to give lession in network layers, protocols and architecture.

 

As I said. There is nothing we can or will do about reception problems of the users.

Link to comment

Not sure if it is related, but I was also experiencing problems as the ones mentioned above. For some reason I started suspecting that it was my Router (a D-link DIR655) that couldnt handle the data traffic even though the network speed was sufficient, so I got an D-link DIR 855 instead and now I have much less problems than before. Please note that I havn't really done enough "problem isolation" to actually confirm that this is what solved the problem, so take it for what it is.

Link to comment
  • 2 weeks later...
The DVBServer/DVBViewer detects a missing frame within 5 seconds, and then spend 5-10 seconds frantically resending duplicate acknowledgments and duplicate frames until everything seems to break down completely and start from scratch. During this period I have a black screen that might flash a number of times. In worst case the connection is never synced unless I manually switch channel a number of times. And even with a manual channel switch, I can see on Wireshark that the client/server communication is broken and require a number of fresh starts in order to succeed.
I get a very similiar problem quite frequently over a hard wired gigabit lan as well when changing channels. (Hell I even get it when the server and client are on the same box using unicast). You change channel and nothing happens, you just get a black screen. After issuing a Rebuild graph command it normally works first time with a non-encrypted channel but with an encrypted channel like Five US it seems to be complete pot luck. It can work after 1 Rebuild Graph command or sometime 10, never a pattern to it.

It can get quite frustrating, but once the channel is tuned it runs fine.

Yeah, just took 3 Rebuild Graph command that time. o:)

Link to comment
  • 4 weeks later...
I'm running DVB Server on a computer, using unicast default settings.

 

Using DVS Viewer (4.0) on another computer on the same LAN works perfectly.

 

Using the same computer over WiFi (180 Mbps), DVBViewer is virtually unusable. Picture and sound 4-5 seconds followed by a 4-5 second pause, over and over.

 

The WiFi Access Point is directly connected to the same LAN as is the DVB Server. Bandwidth is more than adequate for the streaming content.

 

Why on earth do I have such problems getting a contiguous display over WiFi?

:)

 

 

I have a similar issue using 54g protocol. The interesting bit is that if I use the netstream plugin, the video quality is perfect. However, if I use dvbserver (unticking "open whole transponder"), then I get continuous discontinuities in the stream. In theory the bandwidth should be similar in both cases...

Link to comment
  • 3 weeks later...

Let's get this thread going again.

 

Your problem is bad reception, so you have to fix this.

 

No. My problem isn't bad reception. I've had time to gather some serious statistics now, and have some interesting finds. Please don't tell me that this isn't possible (which in fact was my first thought), because I have tested this sooo much that there is not doubt.

 

The problems I have are dependent on channel! And that is viewed channel, not WiFi channel.

 

I have some "good" channels and I have some "bad" channels. I have spent a lot of time watching TV with the DVB Source Properties window open in order to get a clue to what is going on. What I found is that "good" channels aren't' affected by any "bad reception" at all, while "bad" channels are hardly usable.

 

This evening I watched a Volleyball game on Eurosport, one of the "good" channels, using a 54 Mbps WiFi link. Every time there where a break in the game (time-outs and such), I momentarily switched to Discovery (one of the "bad" channels). The results?

 

During the complete 2,5 hour Volleyball game, I had no (0, zero, none) errors. The DVB Source window constantly displayed "Last Error: None", and of course I experienced no interruptions in the viewing. When I switched to Discovery (during 30 second time-outs), I never had an error free reception. Some times I actually didn't get any hint on what the Discover program was about since I never got a stable picture during the 30 seconds I had that channel activated. When I switched back to Eurosport, everything goes back to be completely stable again. Some Discovery "sessions" was all about watching a black screen while the "Last Error: Graph too late" counter behaved as if it was counting seconds...

 

It is completely out of the question that this is a coincidence. I have done this experiment so many times with different channels, so there is simply no way that the WiFi happens to be "bad" just during those 30 seconds that I'm on the "bad" channels. I can reproduce this anytime. It's a bit annoying since Discovery is one of the channels that I frequently watch, and it is completely useless over WiFi.

 

There is no correlation between good/bad channels and bandwidth requirements. The good channels often use up more bandwidth than the bad ones so it's not a case of the bad channels overloading the WiFi link. I have a HD channel that is in fact far better than the standard Discovery channel over WiFi.

 

The DVB Source Properties window reports the problems on "bad" channels as "Graph too late" errors. When such an error occur, the display goes black and stays black for 2-5 seconds. After that it might flash an image for a split second and then go black again - all while the "Graph tool late" counter keeps ticking. Sometimes I have the situation that when switching to a bad channel, the image never shows up - I have a constant black screen and a "Graph too late" counter ticking...

 

I wasn't completely honest when I claimed that the good channels isn't affected at all. I have never seen any "Graph too late" error on a good channel, but I have some times (very rare) seen "PCR/PTS Gap" errors and some "Discontinuities" reported, but this didn't cause any viewing disturbances.

 

So, what can I do to help troubleshoot this problem?

Link to comment
It isn't only a bandwith matter, transmit a multimedia stream isn't comparable to transmit a simple "static" file...

The problems arise on how the MM stream is sectioned and packetized in the WiFi transmission protocol...

 

I can't go more deep on this matter (I'm not so skilled in WiFi protocol complexity), but as you can read in many places, even a little MM stream error cause "big" problem on WiFi transmissions; I only can guess that's probably because WiFi CRC go to panic and start to retransmit packets to the start, so causing the "too late" error...

 

Therefore IMO the better way to solve the problem is to go for a better reception: assuming that you receive by sat, you can check the dish orientation, the LNB rotation and forward/backward alignment, cable and connectors connection goodness and so on... consider also a more big dish or a lower noise LNB or better DiSEqC switch or any other component you have on the dish line... last but not least, to connect your card directly to the dish (I mean not through a set-top-box)...

 

:D

Link to comment
...assuming that you receive by sat...

 

To clarify:

 

I use a FireDTV cable decoder connected via Firewire to my DVB Server. No satellite and no dish and hence no reception problems in to the DVB server. All channels view perfectly on the DVB Server itself, so there is nothing wrong in the cable distribution.

 

So, I have a DVB Server with perfect signal, streaming that signal on my local network. Part of that network is a wireless WiFi based network and it is when the signal from the DVB Server is sent over the WiFi connection that some of my viewed channels experience severe problems while others do not.

 

Since some viewed channels are completely free from disturbances (both viewed and detected by the DVB Source Properties) the problem simply cannot be the WiFi connection.

Link to comment
Since some viewed channels are completely free from disturbances..

 

?????

 

I wasn't completely honest when I claimed that the good channels isn't affected at all. I have never seen any "Graph too late" error on a good channel, but I have some times (very rare) seen "PCR/PTS Gap" errors and some "Discontinuities" reported, but this didn't cause any viewing disturbances.
Link to comment
?????

 

English is not my native language, I apologize if I use words in the wrong way. :D

 

The situation I try to describe is that some viewed channels work without any problems over a WiFi link while other channels are virtually useless. During the test I described, I didn't have one single error reported during a 2,5 hour watch on one channel, while I never managed to view 30 seconds uninterrupted on another. I think that is a significant difference, and I'm interested in finding the cause of that difference so I can view all channels uninterrupted.

 

Is there any tests, traces, debugs or anything else I can do to gather data that gives us a better view on what is going on?

Link to comment

..the ???? were relating to the contradictions in your reports :D

 

Different programmes use different bandwidths. Check, whether the problem is correlated to the bitrate.

Link to comment
Different programmes use different bandwidths. Check, whether the problem is correlated to the bitrate.

No, there is no correlation between bit rate and problem - at least not in the expected direction. The "good" channels often use a higher bit rate than the bad ones. Some data from the DVB Source Properties window:

 

Good, rock solid channels without any disturbances:

Eurosport, 544x576, 25 fps, 5.0 Mbps

HD channel, 1280x720, 50 fps, 9-15 Mbps

 

Totally useless channel that hardly survives 30 seconds without severe disturbances:

Discovery, 720x576, 25 fps, 2.4-3.9 Mbps

Link to comment

Dunno the relative bandwith, but Scewbedew already stated that

I have a HD channel that is in fact far better than the standard Discovery channel over WiFi
...

 

The question that (at least for me) is yet unclear is if on the Server the "bad" Discovery channel work flawlessy...

And - probably the info most important - if Discovery channel was crypted or FTA...

 

:D

Link to comment
The question that (at least for me) is yet unclear is if on the Server the "bad" Discovery channel work flawlessy...

And - probably the info most important - if Discovery channel was crypted or FTA...

All channels work flawlessly on the DVB Server, and all channels are encrypted. I don't know what "FTA" is.

Link to comment
Ok, on the Server you can see it flawlessy, but there are also zero reception errors (on the Server)?

That is correct. I had the "bad" Discovery channel active over night on the server. 10 hours. Last Error: None.

Link to comment
You did of course the most obvious thing first and tested the whole setup with a 100mbit network cable between server and client?

I was about to write that it works perfectly over LAN, but I ran a test with the DVB Source Properties window open and it shows the same kind of problems. Over LAN though, the problem is much less noticeable while viewing the channel since it only results in a split-second freeze of the picture and then it continues. Not the 2-5 seconds black screen over-and-over as is the result over WiFi.

 

Over LAN it is the same characteristics; the "good" channels show no errors in the DVB Source Properties while the "bad" channels continuously count "Graph too late" errors.

Link to comment
the 2-5 seconds black screen over-and-over as is the result over WiFi.
(the WiFi "panic"...)

 

IMO other direction of investigation can be in:

• check the QOS: if you want to benefit of it you have to set it on on ALL lan device, card, switch and so on (but AFAIK is better to disable it everywere...)

• updating the firmware of the WiFi router and/or lan switches

• hunt for other stream that can (also briefly) overload your lan or cause sparkly disturbance

• the width of the DVBServer and DVBSource buffers (that can help to, say, "immunize" from trasmission errors...)

• some other "bad channels" property, like the type/number of encryption/s

 

Good hunting...

 

:(

Link to comment
(the WiFi "panic"...)

 

IMO other direction of investigation can be in:

• check the QOS: if you want to benefit of it you have to set it on on ALL lan device, card, switch and so on (but AFAIK is better to disable it everywere...)

• updating the firmware of the WiFi router and/or lan switches

• hunt for other stream that can (also briefly) overload your lan or cause sparkly disturbance

• the width of the DVBServer and DVBSource buffers (that can help to, say, "immunize" from trasmission errors...)

• some other "bad channels" property, like the type/number of encryption/s

 

Good hunting...

I tested a lot of channels and noted how many "Graph too late" errors that where reported during 3 minutes. Most channels had none while some channels had a lot. Some statistics (the last number on each line is the number of "Graph too late" errors during 3 minutes of that channel):

  • Eurosport 2 4:3 704x576 25fps 3,8 Mbps 0
  • TV6 16:9 720x476 25fps 4,5 Mbps 0
  • TV8 4:3 720x576 25fps 3,4 Mbps 0
  • Nat. Geograhic 4:3 544x576 25fps 4,4 Mbps 0
  • TV4 sport 16:9 704x576 25fps 4,4 Mbps 0
  • Kanal 9 16:9 720x576 25fps 5,4 Mbps 4
  • Motors TV 16:9 704x576 25fps 4,1 Mbps 0
  • ZTV 4:3 720x576 25fps 3,4 Mbps 0
  • Toon Disney 4:3 544x576 25fps 3,4 Mbps 0
  • Extreme Sports 4:3 528x576 25fps 3,0 Mbps 0
  • BBC World 16:9 720x576 25fps 4,1 Mbps 0
  • Showtime 4:3 704x576 25fps 3,9 Mbps 0
  • MTV 4:3 704x576 25fps 3,5 Mbps 0
  • Eusrosport 4:3 544x576 25fps 5,0 Mbps 0
  • Disc. World 4:3 544x576 25fps 3,3 Mbps 0
  • Disc. Travel 4:3 544x576 25fps 3,7 Mbps 0
  • Disc Science 4:3 544x576 25fps 3,3 Mbps 0
  • Silver 4:3 720x476 25fps 4,1 Mbps 0
  • Star 4:3 704x576 25fps 4,0 Mbps 0
  • SVT HD 16:9 1280x720 50fps 7-13 Mbps 0
  • Mezzo 4:3 544x576 25fps 4,8 Mbps 0
  • Viasat Expl. 4:3 720x576 25fps 3,4 Mbps 0
  • Kanal 5 16:9 720x576 25fps 4,1 Mbps 0
  • TV4 16:9 720x576 25fps 4,0 Mbps 0
  • SVT1 16:9 720x576 25fps 4,0 Mbps 0
  • SVT2 16:9 720x576 25fps 3,6 Mbps 0
  • SVT24 16:9 720x576 25fps 6,0 Mbps 0
  • Disey Channel 4:3 544x576 25fps 4,3 Mbps 0
  • Viasat Crime 4:3 544x576 25fps 4,0 Mbps 0
  • Animal Planet 4:3 544X576 25fps 3,4 Mbps 0
  • SVT B&K 16:9 720x576 25fps 3,5 Mbps (var) 7
  • Travel Channel 4:3 720x576 25fps 3,0 Mbps 10
  • TV400 4:3 720x576 25fps 2,7 Mbps (var) 23
  • TV3 16:9 720x576 25fps 2,8 Mbps (var) 25
  • TV4 Fakta 4:3 544x576 25fps 2,4 Mbps (var) 39
  • Discovery 4:3 720x576 25fps 2,8 Mbps (var) 40
  • TV4 Plus 16:9 720x576 25fps 2,5 Mbps (var) 43
  • TV4 Film 16:9 720x576 25fps ? 181

The last channel was so severely disturbed that I never managed to get any bit rate figure; I more or less had 3 minutes of black screen and an ever counting "Graph too late" counter. I switched to another channel and immediately had a steady connection, switched back and viewed the black screen and counter...

 

Some interesting notes:

  • the bad channels where in fact those with the lowest bit rates.
  • the bit rates of the bad channels varied wildly even when there where no visible disturbances. Good channels had constant, steady bit rates.
  • The HD channel had up to 4 times higher bit rate than the bad channels without showing any problems, so this can't possibly be a network congestion problem.

To eliminate all external interferences, I isolated the server and the client on a new, separate network with a dedicated switch for these two systems only. The problems where still there...

 

I don't think this is a network layer problem at all, I think it is an application layer problem.

Link to comment
application layer problem
mmmh, and which application you mean?

DVBViever have to "collaborate" in some way with some other apps, like card driver, video driver, cam driver, decoders and network driver, and speaking of DVBViewer himself I never noticed such an error, as I'm quite sure the other thousands of user, otherwise the forum was full of similar complain...

So there was something in your HW/settings that's make the difference...

And - as I had to remark you that and as early discovered - most probably it isn't a simple bandwith problem, but a WiFi error correction problem, so all network components (sw/hw) have to be deeply analized...

 

But you've replyed to only two of the points I recommend you (the 3rd and the 5th), and I have some more:

• check the protocol stack of your PCs from every pont of view (protocols, order an so on)

• check if WinPcap is still installed on your PCs

• check the CPU level on both PCs

• check the type of encryption of the "bad" vs the "good" channels

 

BTW: sometime a TCP/IP protocol reset greatly help me...

 

:(

Link to comment

IMHO this is going in the wrong direction :(

 

Let's remind that the wireless transfer was according to this thread never error free. Apparently there is no strong correlation between bandwidth and errors. On the contrary, some channels with lower bandwidth seem to be more affected then others. But channels with low bandwidth use a high compression ratio. With high compression a missing packet can have a larger influence and can lead to larger disruptions in the decoded stream.

Link to comment
With high compression a missing packet can have a larger influence and can lead to larger disruptions in the decoded stream.

I fully agree (and IMO that's the real point....)

 

However I'm convinced that a clean and "essentialized" protocol stack with a better tuning of DVBViewer buffers sizes on both the ends can quite help and it's worth a deep try...

 

:(

Link to comment

When I started this thread, I described the problem as being WiFi specific, because it was over WiFi that I first noticed the problems. Please note that I since then have discovered that the LAN connected workstations have the same problem. And even when I put the server and the viewer on a separate, totally isolated network with their own switch, the problems where still there. Some channels are close to unusable when using a dedicated, point-to-point 1 Gbit LAN connection. This can't possibly be due to network problems.

 

I've used viewers on Windows XP SP2, Windows Vista SP2 (64 bit) and Windows 7 beta (64 bit). The server is on Windows XP SP3.

 

I've used both WiFi and LAN connections the clients (different network cards, different drivers). I've installed additional LAN NIC's on the server - NIC's from other vendors with other drivers. I've tested with a completely separate network infrastructure.

 

But you've replyed to only two of the points I recommend you (the 3rd and the 5th), and I have some more:

• check the protocol stack of your PCs from every pont of view (protocols, order an so on)

• check if WinPcap is still installed on your PCs

• check the CPU level on both PCs

I don't have WinPcap installed on any system. I've reset the TCP stack. The provider order and other definitions for the TCP stack is as default, i.e. no additional providers and no changed order of the default providers. Only the default protocols are used, with the default settings.

 

The server is a pretty clean system with no additional software other than what is required for the DVB software and the drivers for NIC's, cable decoder, graphic card and such.

 

CPU load on the client (only checked Windows 7) average on 20% whereof 10% is the DVBViewer.

CPU load on the server average on 5% whereof 2-3% is the DVB Server.

 

• check the type of encryption of the "bad" vs the "good" channels

I don't know how to check that, please guide me.

 

So there was something in your HW/settings that's make the difference...

I don't think the HW is causing the problem since I have tested with various NIC's. The only thing I have not done yet is to re-install the complete server from the ground up. I am planning to do that based on Windows 7 RC1 as soon as this is released.

Link to comment
use transedt -> analyze

I can't find any details about the encryption method used. All channels have MPEG2 and most of them are in red (i.e. encrypted). Two interesting things noted in the analyze window:

  1. The Discovery channel (one of the "bad" ones) is not encrypted.
  2. Most, but not all, of the bad channels are on the same frequency. (Don't know what "frequency" means in a cable network, I thought everything were digital...)

Apart from that...I have now got Windows 7 and re-installed the server (and one of the clients).

The server disk is formatted and a fresh copy of Windows 7 is installed. Only the absolute minimum of software and drivers are installed; only what's needed to get the DVB Server to work.

 

Still the same problem with "Graph too late" errors for some channels both on WiFi and LAN.

Link to comment

Join the conversation

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

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
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.

×
×
  • Create New...