Is it something wrong with Rapidshare Premium

[msmolka]

I cannot download anything through Download Station from Rapidshare (hotfile, fileserve works). It shows transfer 0. Files are there - browser downloading them. My firmware is 3.3.6 Build 1109T

[msmolka]

It worked on 22th of Feb. But now it is not. Anybody knows anything? I cannot download file I was able to download on 22th.

[BladesMaster]

I have exactly same problem (TS-109 Pro II, SW 3.2 latest available version. Something changed on Rapidshare side

[ros46]

Same problem. QNAP TS-109, firmware 2.1.2.
Rapidshare gets worse

[msmolka]

I wonder if this problem exists on firmware 3.4

[SiliconRain]

Something did indeed change on the rapidshare side. This post on the support page of a (not qnap-related) mass-downloader confirms that rapidshare changed their authentication method. It looks like this happened within the last couple of weeks. I think it's something to do with rapidshare links no longer pointing directly to the file location. The link needs to be resolved fully before being added to the download station queue. Currently, this is not something that QRapid or QGet do. Downloading rapidshare links through your browser still works because the browser knows to resolve the link.

I'm no expert btw, so my terminology is probably a little off.

Anyway, the bottom line is that this change happened recently, and so it will take a while for the QNAP guys to catch up with it (assuming they know about the problem) and put a fix in a new release of QGet or a new version of the download station. At least I think so. I'm still using the old firmware version 3.2, the old download station and the old QGet. I'm not sure if getting the new versions would solve this problem but I'm hesitant to update given how much complaining everyone else is doing about the new software.

If anyone can confirm if I'm right/wrong about this then that would be great.

[Spag]

I hope QNAP can fix this fast. Suddenly no files can be downloaded from Rapidshare via tha NAS

[nikiw]

OK, thats why my rapidshare downloads stopped working form one second to another. I thought the firmware update caused this but i tried different versions 3.4.0, 3.3.7 and 3.3.9 and everything the same problem.

Is an update for downloadstation in the queue?

[Spag]

Ok, I mailed Rapidshare and the thing is, that all downloads are now automatically via SSL. That meams, that alle links are redirected to a https link, and that Download-managers can't handle this until they are updated. There is no way to disable the SSL in your Rapidshare account.

QNAP, please help us fast!

[synf2n]

From what I see you can disable SSL in rapidshare. If you go to http://www.rapidshare.com/ when logged in, there is a large, red button on the bottom right that lets you enable/disable SSL !

I believe there are one or two problems going on at the moment and nothing is making sense on these forums on these matters.
Excuse me if I am wrong with this but to me it seems the two main issues are:

1, The latest firmware for our qnap stations has (supposedly) added better support for rapidshare. But it actually makes things sort of worse.
Quote from 3.4.0 release notes:

Code: Select all

- Download Station v2 & QGet v2
   * Brand New AJAX-based GUI
   * Support Broadcatching (RSS download)
   * Subscribe to RSS feeds
   * RSS Download Manager(filter)
   * Selectable Download Files
   * Account settings for HTTP/ FTP/ RapidShare Download
   * Better Performance & Bandwidth Control
   * Better Seeding Mechanism
   * Configurable download location (global)
   * Support Multiple URLs in One Task

Given reports on here, though it does sound like qnap have messed up somewhere along the lines - with reports of very slow downloads on those (myself NOT included) who have updated to FW 3.4.0. through rapidshare.


2, Rapidsahre have changed their servers. SiliconRain is correct as far as I can see. Previously (don't ask me for dates on this ) rapidshare links such as:

Code: Select all

http://rapidshare.com/files/442778090/wikinet.facebear.W.part01.rar


gave the exact location to the file you want to download.

However, NOW rapidshare seem to use links or redirects (similar to hotfile) that Download Station cannot follow unless you enter your rapidshare url directly to the Download Station web interface. Most of us, however, do not use the web interface for adding http downloads because who want's to enter every part of their download manually? So we use Qget (which I am told now supports multiple additions to the queue at once) or Qrapid or whatever. I use a download queue client that I wrote myself.
Our rapidshare url - as previously mentioned:

Code: Select all

http://rapidshare.com/files/442778090/wikinet.facebear.W.part01.rar


now resolves to:

Code: Select all

https://rs942tl3.rapidshare.com/files/442778090/wikinet.facebear.W.part01.rar


Where it did not do this before.
Notice the entire new domain at the start of that resultant url. This indicates a restructure at rapidshare.

3, (point 3 is more a result of points 1 & 2 above)
Due to the fact that qnap have added better rapidshare support at the same time rapidshare have changed their server structure ( with redirects rather than pure links ) seems to have caused some problems for everyone.

-Anyone with the latest FW will be able to add their downloads ok though the web interface but might not get great speeds (due to unknown reason- perhaps bug in new qnap code).
-Anyone with older firmware simply does not have functionality either on their download client or on their nas it's self to support the new rapidshare system and follow the links correctly. The symptoms of the latter being downloads that just appear to be "running" at 0.0Kbps as many have reported. This makes sense if you add a url with standard http authentication without calling an API function of some sort; more on this in the solution below.

The reason, just to clarify, is because rapidshare now use redirects rather than actual download links, and the older versions of the qnap FW DO NOT call the rapidshare API function to download something, they simply add the given url to the download queue without checking if it's some sort of link or redirect.
The reason many people will not spot this is because if you go to test a given rapidshare url by downloading it in your browser - it will work. This is because your browser is set to follow all such re-directs automatically so you will only notice that the location actually does not exist when you right click on the download box in your browser and ask it for the download location.

Solution:
For the developers:
Either qnap (in the case of Qget) or developers of Qrapid etc need to change their clients to call call whatever function Download Station calls that in turn, correctly, calls the rapidshare API when adding a download task (that gets the download location before downloading it).
Or
Qnap need to integrate that same code into the CGI code that the client's call. Which I believe is something like this:

Code: Select all

/cgi-bin/Qdownload/DL_Task_Option.cgi?todo=add_qget

Please not that this is just the command which needs to be called as part of a larger HTTP GET request to the qnap.

For users:
Downgrade to a version of FW before 3.4.0 ( to stop the slow rapidshare problems )
Then you could write your own client as it is not yet clear if the download queue clients yet support the new rapidshare structure. Making sure to call the rapidshare API before adding the correct download location (result of API call) to your download queue.
I believe the correct rapidshare API command is:

Code: Select all

sub=download

I have not tried the new Qget with an older version of the FW. The success of this would depend on _where_ the rapidshare API call code is. If it's only in FW 3.4.0 then your screwed because we need that code to get the downloads to work. If it's in Qget then that might be more helpful, because then we can maybe run Qget 2.0 with something < 3.4.0 and everything will just work?
Can someone tell us if Qget 2.0 works with FW thats before 3.4.0?

Hope this makes sense and that I am not talking rubbish. I just see everyone talking about two or three different problems.
Corrections welcome.

-synf

[Spag]

From what I see you can disable SSL in rapidshare. If you go to http://www.rapidshare.com/ when logged in, there is a large, red button on the bottom right that lets you enable/disable SSL !

No. The red button is only for your web-access to the control-panel on http://www.rapidshare.com/. You can chose if you want access with http or https, but that has absolutely no effect on the way your downloads are handled. These are now always automatically via https

[synf2n]

Ok, I see what you are saying. Are you also saying that the cause of the problem is NOT because of the URL redirects but because of the https it directs to?

[synf2n]

This is the best solution to the problem that I can find:
viewtopic.php?f=16&t=33515#p144954

-synf

[Spag]

Ok, I see what you are saying. Are you also saying that the cause of the problem is NOT because of the URL redirects but because of the https it directs to?

I'm saying, that the redirects are the cause of the problem and that the redirects are because of RapidShares globally changed settings, that all downloads are now handled via SSH which redirects the links to a https-location.

Earlier I used to experiment with the SSL-downloads when this could be enabled manually. The price of this was a double charge in Rapids (the currency on Rapidshare), but when i manually enabled it, the Download Station and Qget wouldn't start downloading because of the redirects to the https-location. I therefore disabled the function again.

Now however, Rapidshare has decided that ALL downloads are via SSL, without the Premium User getting charged double rapids. This is a great service, but the problem is, that Download Station and Qget can't "translate" the redirects, so now all the downloads hangs.

I talked to Rapidshare about disabling this, and their response was, that this is no longer possible. When I told them about QNAP-users being unable to download, their response was that 3rd-party download managers are not supported.

So again: Please help us QNAP!

[nikiw]

Something new on this with firmware 3.4.1?
i hope QNAP will help us!