uploaded.to_premium 1.1.0 not working

Hello guys,

thank you for a wonderful app. I'm using FRD 1.0 on Mac OSX 10.8.4 (the mac-specific version from the dmg file) with the uploaded.to_premium 1.1.0 plugin. It worked well until today. What happens today is that it still catches the link in clipboard, then waits for 5 seconds and then stays in the GETTING status without actually getting anything and not even getting the actual filename -- the filename as shown in FRD stays xxxxxxx.

The only thing which shows up in log is:
Thu Aug 22 18:38:28 PDT 2013 WARNING: Text content type expected, but binary stream was found


I've tried a number of links and none work in FRD (but here's an example if you insist: [ul.to]). I can get the files thru browser no problem.

I have tried what the non-premium plugin can do and it does get the right filename but it can't download right away, so it's not useful to me.

Any suggestions?

thanks!



Edited 3 time(s). Last edit at 08/23/2013 01:44AM by stangri.

The plugin was expecting to first load a web page containing a download link then download the file
but the file started to download immediately. (Text content type expected, but binary stream was found)

Plugin 1.1.1 should work again

Oh, I see what happened. Thank you, I confirm 1.1.1 is working now with the "direct downloads" checkbox set in my premium account preferences.

I have a similar problem since yesterday.

Windows 8
FRD 0.9u2
plugin 1.1.1

When I directly copy a reference to an ul.net from a Website-link I often(not always) get an unrecoverable error
" No Content-Disposition (filename) header in file"

As a workaround I first open the link to ul.net in a Webbrowser and then copy it to FRD. This seems to work most of the
time, but it is cumbersome.

Example [avaxhome.ws]

Please let me know if you need more info.

Have you tried setting the checkbox to on for the Direct downloads in your ul.to profile?

I've just tried and I can download from the site you've referred to no problem.

stangri Wrote:
-------------------------------------------------------
> Have you tried setting the checkbox to on for the
> Direct downloads in your ul.to profile?
>
There is no such option for ul.to plugin in V 0.9u2; I changed the global option to enable
direct downloads. Did not work either.

The problem started sometimes yesterday, possibly after the latest fully automatic plugin update (my logfile
says 23rd august, 23:27 )

I meant you need to login to ul.to with your browser and enable direct downloads on the web-site, not within the plugin.

stangri Wrote:
-------------------------------------------------------
> I meant you need to login to ul.to with your
> browser and enable direct downloads on the
> web-site, not within the plugin.

That seems to do the trick. Thanks a lot for your help!

I have found a negative side effect since the plugin behaves differently with v1.1.1. I document my downloads by linking the description web page (including the download link) with the file name. Before it took me just two clicks to do this. Now I can't open the ul.to web page anymore because if I click the link a download dialogue is immediately started.

Is there a chance to get the behaviour of the older plugin version back ; i.e. without having to check "direct downloads" on the ul.to profile?

birchie, it is because "ul.to" links redirect to "uploaded.net" when direct downloads are not enabled. This is unfortunately pretty tricky to handle in the plugin API at the moment. See the XFS plugin for more info.

I downgraded the plugin back to v1.1.0 for now.