While ULOZ is working fine for most files I'm having trouble with small non-archived (non-rar'd) files like


[ulozto.net]

Works fine for me. What error message did you get? Please attach app.log (Help -> Browse to log file).

App.log shows

Mon Apr 04 09:10:06 ICT 2016 WARNING: No Content-Length in header
Mon Apr 04 09:10:06 ICT 2016 WARNING: Loading file failed


FRD shows ERROR - Error starting download.

Still works fine for me. Can you download it via browser? Or maybe just temporary server problem?

tong2shot wrote:
-------------------------------------------------------
> Still works fine for me.

Hi tong2shot

Sadly, I can verify OP's claim, with same results;
verbose log attached, to hopefully aid you in
debugging this...

> Can you download it via browser?

Firefox works fine - downloaded file
attached as proof!

Regards

Agree with what TV junkie said.

I'm not sure if this is related, there is DNS issue with their captcha servers' domain. If I use my ISP's DNS server sometimes I get UnknownHostException error, for example: "java.net.UnknownHostException: xapca7.uloz.to". But if I use different DNS server (for example: dnscrypt), it always works fine.



I still can't figure out what's wrong (on our side) here.

tong2shot wrote:
-------------------------------------------------------
> I'm not sure if this is related, there is DNS
> issue with their captcha servers' domain.
> (snip)
> I still can't figure out what's wrong
> (on our side) here.

I don't think DNS is to blame here
Unless I am mistaken, the DNS cache
is installed/available system-wide in the
Windows OS, for any app connected to
the Internet - if Firefox can download that
.srt file (with the default DNS servers from
my ISP), then so should FRD - unless it
uses a DNS cache different to the one
Firefox does...

But just to humour you, I just changed
my DNS servers from the default ones
(maintained by my ISP) to first GoogleDNS
(8.8.8.8 / 8.8.4.4) and in a second test to
OpenDNS (208.67.222.222 / 208.67.220.220).
After each change, the DNS cache was first flushed;
cmd.exe was run as Admin, then:

Microsoft Windows [Version 6.0.6002]
Copyright (c) 2006 Microsoft Corporation.  All rights reserved.

C:\Windows\system32>ipconfig /flushdns

Windows IP Configuration

Successfully flushed the DNS Resolver Cache.

C:\Windows\system32>

and after that the download tried in FRD;
in both cases the fetch failed, the same
behaviour exhibited with default DNS servers!

I don't pretend to be an expert in this,
but maybe KES's and mine "issue" is Java related?
I happen to use JavaRE 7u99 (x86), if KES
is also on JRE 7 (the last installable on WinXP),
maybe that "common link" is the missing clue...

I'll investigate this later. Does this happen for just particular link (the sample link)? Any other link I can test?

I am also on Win XP (32 bit) with Java 7 Standard Edition build 1.7.0-b147