• AnyStream is having some DRM issues currently, Netflix is not available in HD for the time being.
    Situations like this will always happen with AnyStream: streaming providers are continuously improving their countermeasures while we try to catch up, it's an ongoing cat-and-mouse game. Please be patient and don't flood our support or forum with requests, we are working on it 24/7 to get it resolved. Thank you.

Needs Attention No connection to Internet using version 1.6.8.0

O

ocd

Well-Known Member
Thread Starter
Joined
Jul 17, 2011
Messages
141
Likes
20
Well, the weird thing is I never had this problem until 1.6.8.0, and I've never used VSO Downloader.

Perhaps weirder still is that AS 1.6.8.0 isn't actually sending any packets.

I can ping opd.redfox.bz (100ms) just fine. When I do that, I see the packets. But not when launching AS. No weird firewalls or anything.

When I launch AS, it does nothing for a while and then eventually says "Unable to connect to the Internet" with no error number. If I unplug the network cable, it gives me that message immediately. I'm not sure how to generate a log file when I can't get to the main window...

Edit: Just downgraded back to 1.6.7.0 and it works without any problem...

Edit 2: RESOLVED: Be sure to disable WPAD. It can stall for 15 seconds, which causes the network check in 1.6.8.0 to fail. Thanks to Pete for helping chase this down!
 
Last edited:
ocd said:
Well, the weird thing is I never had this problem until 1.6.8.0, and I've never used VSO Downloader.

Perhaps weirder still is that AS 1.6.8.0 isn't actually sending any packets.

I can ping opd.redfox.bz (100ms) just fine. When I do that, I see the packets. But not when launching AS. No weird firewalls or anything.

When I launch AS, it does nothing for a while and then eventually says "Unable to connect to the Internet" with no error number. If I unplug the network cable, it gives me that message immediately. I'm not sure how to generate a log file when I can't get to the main window...

Edit: Just downgraded back to 1.6.7.0 and it works without any problem...
Click to expand...
Why don't you just try rebooting your computer and see if it connects?
 
Yes. No packets are going out with 1.6.8.0 (I checked on my router). Maybe the workaround doesn't work on Win7?

Any way to generate a log file at this early stage?
 
ocd said:
Yes. No packets are going out with 1.6.8.0 (I checked on my router). Maybe the workaround doesn't work on Win7?

Any way to generate a log file at this early stage?
Click to expand...
Don't ask. Do it.
 
Just a shot in the dark but ... Try to disable automatic proxy settings ...
Open Windows startmenu, start typing "proxy" ... the first search result should be ProxySettings ... go there and disable any sliders.

I just noticed that Win7 is used ... then you would have to change that in the Internet Explorer settings.
 
Last edited:
ocd said:
Yes. No packets are going out with 1.6.8.0 (I checked on my router). Maybe the workaround doesn't work on Win7?
Click to expand...
I just tried it on Win7-64bit under VMWare. Works just fine.

I'd like to track down the cause. So first I'll explain, how AnyStream accesses the Internet - maybe you'll have an epiphany along the way, when something rings a bell.
And then I'd like you to describe your setup (as far as it might be relevant) as detailed as possible. Things like firewalls and anti-virus viruses (not a typo, a statement) are among the obvious.

So, both AnyDVD and AnyStream up to 1.6.7.0 use a similar module to access our servers. It is based on WinHTTP and that's what the VSO software is breaking.
Any other Internet connection in AnyStream, including actual downloading does not use WinHTTP, but the HTTP API from the Qt framework instead (I'll call it Qt-HTTP).

So the workaround in AnyDVD was to fix the broken settings left behind by VSO. But if someone is using VSO and AnyDVD in parallel, there will be an endless cycle of VSO breaking it, AnyDVD repairing it and so on. But I don't think, the user would ever notice.

In AnyStream, instead, we simply switched from WinHTTP to Qt-HTTP, thereby completely dodging the problem and not caring what VSO does.

Now, what puzzles me, is that your AnyStream 1.6.8.0 now can't access our servers using Qt-HTTP, while the entire rest of AnyStream has always used Qt-HTTP to access the providers without a hitch.

My brain is now - sluggishly - racing through possible differences, but the only difference that I can come up with, is that the failing connection is HTTP, while all others are HTTPS. But since HTTP is considerably (by orders of magnitude) simpler than HTTPS, I have a hard time believing, that it's the cause.
Unless, of course, there is a firewall in place - which could and would make an explicit distinction between HTTP and HTTPS traffic. Further up you stated "no weird firewalls", so I have to clarify: any firewalls? A firewall doesn't have to be weird to cause problems. Windows has one by default, did you switch that off explicitly for testing?

It's a bummer, that AnySream doesn't display an error code (I'll make sure, that gets fixed), so we don't know, at which stage it fails. It could be simply while resolving the IP using DNS (could be verified by adding a fixed entry in c:\windows\system32\drivers\etc\hosts).
 
Last edited:
Pete said:
I just tried it on Win7-64bit under VMWare. Works just fine.

I'd like to track down the cause...

Now, what puzzles me, is that your AnyStream 1.6.8.0 now can't access our servers using Qt-HTTP, while the entire rest of AnyStream has always used Qt-HTTP to access the providers without a hitch.

... Further up you stated "no weird firewalls", so I have to clarify: any firewalls? A firewall doesn't have to be weird to cause problems. Windows has one by default, did you switch that off explicitly for testing?

It's a bummer, that AnySream doesn't display an error code (I'll make sure, that gets fixed), so we don't know, at which stage it fails. It could be simply while resolving the IP using DNS (could be verified by adding a fixed entry in c:\windows\system32\drivers\etc\hosts).
Click to expand...
Thank you for weighing in, and for the explanation. I look forward to a version that does display an error code! :)

Given that you were already using Qt-HTTP for downloads (and those worked!), this behavior is indeed very strange.

More details on my setup:
  • Win7-32bit under VMware
  • I turned Windows Firewall completely off (I hadn't done that previously, but just double-checked the behavior with it off now).
  • Running tcpdump on the VM host, monitoring the VMware network interface.
I can ping opd.redfox.bz from the VM, and tcpdump sees those packets (DNS and ICMP).

But when I launch AnyStream 1.6.8.0, no packets appear on that interface while AS sits there and eventually tells me it can't connect to the internet.

So while I have a (non-filtering) firewall between the host and the internet, packets aren't getting that far: that's what I meant by no "weird firewalls." (Good question, though.)
 
ocd said:
Win7-32bit under VMware
Click to expand...
Now, that is interesting information.
The 32-bit version of AnyStream is hardly used and rarely tested. We're hoping to get rid of it at some point - there's not much sense in dragging that outdated processor architecture along.

My test was with Win7-64bit. So it might be, that the 32-bit version behaves differently. That said, though, a quick test of the 32-bit version under 64-bit Windows 7 also works fine.

Now, since you're mentioning tcpdump, I'm assuming, your host is Linux? Is there a reason why you don't just use the Linux-version of AnyStream?

Regarding tcpdump: you were monitoring the entire interface, or did you filter? (As I said, the DNS resolver may well be involved, which works independently of AnyStream).
 
I'm using a VM because I like to sandbox my programs. It's 32-bit because it's derived from an image that I created a long time ago. The longer term plan is indeed to run AnyStream in a Linux VM on a different host. Maybe it's time to rip the band-aid off now...

I just ran another test and noticed a few packets I missed before:

Code: 
10:35:27.962593 IP 172.16.185.128.54336 > 172.16.185.2.domain: 52025+ A? wpad.localdomain. (34)
10:35:28.975002 IP 172.16.185.128.54336 > 172.16.185.2.domain: 52025+ A? wpad.localdomain. (34)
10:35:30.987597 IP 172.16.185.128.54336 > 172.16.185.2.domain: 52025+ A? wpad.localdomain. (34)

10:35:34.997116 IP6 fe80::1c79:6a12:xxxx:xxxx.63182 > ff02::1:3.llmnr: UDP, length 22
10:35:34.997556 IP 172.16.185.128.65310 > 224.0.0.252.llmnr: UDP, length 22
10:35:35.105984 IP6 fe80::1c79:6a12:xxxx:xxxx.63182 > ff02::1:3.llmnr: UDP, length 22
10:35:35.106150 IP 172.16.185.128.65310 > 224.0.0.252.llmnr: UDP, length 22

10:35:42.179923 IP 172.16.185.128.60053 > 172.16.185.2.domain: 24828+ A? opd.redfox.bz. (31)
10:35:42.182016 IP 172.16.185.2.domain > 172.16.185.128.60053: 24828 1/0/0 A 185.246.128.167 (47)
The error message appears right when the DNS lookup is made, 15 seconds after launching AnyStream.


For reference, here's 1.6.7.0. Note the immediate opd check and traffic:
Code: 
10:46:41.725178 IP 172.16.185.128.63282 > 172.16.185.2.domain: 21855+ A? opd.redfox.bz. (31)
10:46:41.726731 IP 172.16.185.2.domain > 172.16.185.128.63282: 21855 1/0/0 A 185.246.128.167 (47)
10:46:41.727212 IP 172.16.185.128.49176 > se.redfox.bz.http: Flags [S], seq 1717991439, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
...
10:46:41.958861 IP 172.16.185.128.49176 > se.redfox.bz.http: Flags [.], ack 4905, win 64240, length 0

10:46:42.098633 IP 172.16.185.128.65174 > 172.16.185.2.domain: 55908+ A? wpad.localdomain. (34)
10:46:43.103968 IP 172.16.185.128.65174 > 172.16.185.2.domain: 55908+ A? wpad.localdomain. (34)
10:46:45.116049 IP 172.16.185.128.65174 > 172.16.185.2.domain: 55908+ A? wpad.localdomain. (34)

10:46:49.126489 IP6 fe80::1c79:6a12:xxxx:xxxx.57491 > ff02::1:3.llmnr: UDP, length 22
10:46:49.126954 IP 172.16.185.128.49502 > 224.0.0.252.llmnr: UDP, length 22
10:46:49.234594 IP6 fe80::1c79:6a12:xxxx:xxxx.57491 > ff02::1:3.llmnr: UDP, length 22
10:46:49.234911 IP 172.16.185.128.49502 > 224.0.0.252.llmnr: UDP, length 22

10:46:56.314901 IP 172.16.185.128.64937 > 172.16.185.2.domain: 3921+ A? (provider)
10:46:56.347680 IP 172.16.185.2.domain > 172.16.185.128.64937: 3921 3/0/0 CNAME (provider)
...normal traffic...

Interestingly, the provider DNS lookup also happens 15 seconds after launch. I'm guessing that's a result of waiting for Qt-HTTP to start up? But I don't see anything that explains why the provider traffic proceeds in 1.6.7.0 but the opd check doesn't in 1.6.8.0...
 
Ok, thank you. This is pretty mysterious.
Maybe keep that band-aid in place for a little while longer, in case we have a chance to figure this out.

So.... DNS lookup seems to be working just fine, I don't get why nothing at all is happening from then on.
If you have the patience for this - I'd appreciate you installing Wireshark on that VM and monitor the traffic from within the Windows VM.


(Not sure, it seems they are phasing out the 32bit versions, but that version still is available in 32bit)
I can't get why AnyStream - seemingly - gets the IP but then doesn't even seem to try to initiate a TCP connection. So maybe that is just not leaving the VM.
 
BTW: also installed Windows 7 32bit now (VMWare with Windows host) and tried it. AnyStream 1.6.8.0 32bit works just fine.
This is some head-scratcher...
 
ocd said:
Interestingly, the provider DNS lookup also happens 15 seconds after launch.
Click to expand...
Now, that really depends A LOT on which provider that is.
Qt-HTTP is up in an instant. As in the range of split seconds.

How was the appearance of the provider? Did it come up quickly or was AnyStream 1.6.7.0 inertly sitting there for 15 seconds?
It should happen quickly.
 
TL;DR: A possible procedure to reproduce the issue: try launching AS 1.6.8.0 in Windows 7, configuring it, exiting, and launching it again once it's configured.

Well, it turns out I'm running 32-bit AS on 64-bit Win7. I'm trying to remember why I've been doing that. I vaguely recall problems (at least early on) with 64-bit AS on Win7? Anyway, I also tried 64-bit AS and had the same behavior.

Wireshark within the VM shows the same thing that tcpdump did...no other packets.

The 15-second delay before an AS window appears has always happened so far as I can remember. It doesn't matter which provider is first looked up, and it in fact happens at first setup before any providers are enabled.

But here's the new weird scenario:
  • I had both 32-bit and 64-bit AS installed, both failing.
  • I uninstalled 32-bit AS (keeping registration info).
  • I launched 64-bit AS and it walked me through initial setup and loaded a provider's site.
  • I exited 64-bit AS.
  • I launched 64-bit AS again, and it failed again.
I've done a few more experiments, and it seems that so long as I quit AS before completing setup, I can launch it again and get to the setup windows. Once I then proceed and load a provider's site, it fails on subsequent launches until I uninstall it and reinstall.

Here's a tcpdump of a first launch:

Code: 
12:40:20.484893 IP 172.16.185.128.61760 > 172.16.185.2.domain: 9021+ A? wpad.localdomain. (34)
12:40:21.485131 IP 172.16.185.128.61760 > 172.16.185.2.domain: 9021+ A? wpad.localdomain. (34)
12:40:23.497505 IP 172.16.185.128.61760 > 172.16.185.2.domain: 9021+ A? wpad.localdomain. (34)
12:40:27.506857 IP6 fe80::1c79:6a12:xxxx: xxxx.56531 > ff02::1:3.llmnr: UDP, length 22
12:40:27.507028 IP 172.16.185.128.52908 > 224.0.0.252.llmnr: UDP, length 22
12:40:27.615335 IP6 fe80::1c79:6a12: xxxx: xxxx.56531 > ff02::1:3.llmnr: UDP, length 22
12:40:27.615472 IP 172.16.185.128.52908 > 224.0.0.252.llmnr: UDP, length 22
12:40:27.818266 IP 172.16.185.128.netbios-ns > 172.16.185.2.netbios-ns: UDP, length 50
12:40:29.331025 IP 172.16.185.128.netbios-ns > 172.16.185.2.netbios-ns: UDP, length 50
12:40:30.844458 IP 172.16.185.128.netbios-ns > 172.16.185.2.netbios-ns: UDP, length 50
12:40:32.388765 IP 172.16.185.128.netbios-ns > 172.16.185.255.netbios-ns: UDP, length 50
12:40:33.153858 IP 172.16.185.128.netbios-ns > 172.16.185.255.netbios-ns: UDP, length 50
12:40:33.917580 IP 172.16.185.128.netbios-ns > 172.16.185.255.netbios-ns: UDP, length 50
Then the setup window appears.

As soon as I finish the window selecting providers:
Code: 
12:40:49.871742 IP 172.16.185.128.63362 > 172.16.185.2.domain: 8819+ A? opd.redfox.bz. (31)
12:40:49.873791 IP 172.16.185.2.domain > 172.16.185.128.63362: 8819 1/0/0 A 185.246.128.167 (47)
12:40:49.878688 IP 172.16.185.128.49235 > se.redfox.bz.http: Flags [S], seq 4286920423, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
...
12:40:50.236735 IP 172.16.185.128.49235 > se.redfox.bz.http: Flags [.], ack 4909, win 64240, length 0
12:40:50.572563 IP 172.16.185.128.57340 > 172.16.185.2.domain: 40353+ A? wpad.localdomain. (34)
12:40:50.573672 IP 172.16.185.128.50301 > 172.16.185.2.domain: 19482+ A? wpad.localdomain. (34)
12:40:51.574866 IP 172.16.185.128.57340 > 172.16.185.2.domain: 40353+ A? wpad.localdomain. (34)
12:40:51.574942 IP 172.16.185.128.50301 > 172.16.185.2.domain: 19482+ A? wpad.localdomain. (34)
12:40:51.576226 IP 172.16.185.128.53947 > 172.16.185.2.domain: 12754+ A? (provider) (32)
12:40:51.594851 IP 172.16.185.2.domain > 172.16.185.128.53947: 12754 3/0/0 CNAME (provider)
...

So it works so long as it's not configured, but once AS is configured, it refuses to start.
 
ocd said:
I vaguely recall problems (at least early on) with 64-bit AS on Win7?
Click to expand...
You're right, I remember now. There was a requirement for the 32bit version under Windows 7. I believe, that was fixed, when we switched to CEF as browser.

ocd said:
A possible procedure to reproduce the issue: try launching AS 1.6.8.0 in Windows 7, configuring it, exiting, and launching it again once it's configured.
Click to expand...
No, not really, I can do whatever I want, it works and keeps working on both W7_32 and W7_64. No 15 second hold-up, nothing.

But your 15 second delay, that has always been there, seems to be a clue. Meaning: you've always had that problem, only that with v1.6.8.0 it became a show-stopper instead of a nuisance.

The Internet-check on startup has a timeout of 8 seconds (which is still stupidly long for an operation, that normally requires around 300ms).
So, something appears to be blocking networking for the first 15 seconds within the application, but AnyStream's Internet-check gives up after 8.

For testing, I'll bake a version for you, that waits up to 30s. Let's see, if that "fixes" it for you - though you'd still experience those 15 seconds of unnecessary waiting.

I assume, the "Qt-HTTP" on startup does "something", that normally finishes immediately, but in your case waits 15 seconds for - whatever - which doesn't happen and then continues normally. But until it either gets what it's looking for or times out, it doesn't perform any networking tasks.

I'll try to find out what that "something" might be. Which would be so much easier if I could reproduce your problem.
 
You must log in or register to reply here.
Back
Top