#21
|
|||
|
|||
This happens to me when I try to use link grabber to grab .dlc links.
If you download the .dlc file manually. Goto the folder where the file is downloaded to and then add it to jdownloader by dragging the .dlc file onto the download window of jdownloader it works great. |
#22
|
|||
|
|||
I'm having problems with this no permissions error also. Can't see any consistency.
|
#23
|
|||
|
|||
Please, read this thread from the beginning.
|
#24
|
|||
|
|||
It seems to be a server problem. It happens when your download is somehow disrupted, and you have been disconnected, but on the file server side (MU, RS, etc), they still detect your IP status as downloading. As a result they deny you to reconnect or resume download. Since there is no such error message as:
"Your download has fuxxored. Please resume or begin the next download later, or when the server side has acknowledged that your download has been aborted, and thus freeing up your IP for the next download." Unfortunately JDownloader can only blindly attempt to reconnect, so all your downloads begin to show "no permissions to write to hard disk", such as what you see here... This is getting to be a mega issue with RS, which doesn't allow resuming. So if you see a page full of 200 meg segmented files, and you know your server will take a big dump on you, then I'd advise that you just walk away. |
#25
|
|||
|
|||
@updown: RS does allow resuming.
The problem seems to be a deadlock caused by JD when trying to write to disk. It has nothing to do with RS, MU, FF, etc. It's a problem with JD itself. This error occurs frequently to me when using a faulty internet connection and it doesn't matter if I'm downloading from RS, MU, whatever. Resetting the file works sometimes so half of the time I have to add the link again. Changing the num. of chunks to 2 didn't help either. |
#26
|
||||
|
||||
Quote:
Connection Reset, Connection Timeout, Read Timeout...all those errors come from instable Internet, firewall and so on , but NOT from JD (you can google the error if you want) only because part files has the right size, does NOT mean they are completed, just imagine 2 chunks, chunk 1 is dead, chunk2 is complete so the file is correct filesize, but 0-50% empty, 50-100% correct we need logfiles and information about os/java/firewall to try to help
__________________
JD-Dev & Server-Admin |
#27
|
||||
|
||||
The message is misleading, people will always make a new report about this.
Is it difficult to write a new message about bad connection problem? |
#28
|
|||
|
|||
Does anyone still have this problem?
I do, and I'm on the latest JD.. On a 3mbps connection, I see this problem at least once a day... usually it shows the *.part on disk to be bigger (Sometimes full sized, but still with .part extension) than the %/size shown within JD. Could it be because JD preallocates the space and then fails to readjust it when an unexpected interruption happens? For example when there's connection time out or server disconnection? Thank you. |
#29
|
|||
|
|||
Quote:
Sometimes JD finishes downloading the file but I can still see that the ".part" suffix is still appended to the file. What I've done in this case is to simply rename and remove the ".part" extension and see if it works. It's always worked for me. |
#30
|
|||
|
|||
Yes, exactly. I think the Bad CRC is caused by wrong marker (where JD think the file should be resumed is not accurate with what's already been downloaded).
I've downloaded under the same condition (same file host, same download server, same ISP) and I very very rarely get CRC error on straight download in the past. But after the last big JD update, I get this regularly. Don't get me wrong, I think JD is awesome, but this is a step back in terms of reliability from the previous version from what I've seen. As for the 'full sized file with .part'.. whenever I see that occurence, I almost always get a bad .rar when it's renamed. |
#31
|
|||
|
|||
The error comes undoubtedly from connection problems, from your connection, from the server, etc.
The message "no permissions to write..." is silly. But what I don't understand is why JDownloader can't just overcome these problems and finish the download. I remember using programs like getright and similar ones and they were just set & forget, they used to rollback some kbytes and the download always finished sooner or later. With JDownloader, when I come back to the computer, 4 o 5 files have failed, and I have to reenable or reset the files manually, sometimes, several times. Code:
EXCEPTION 57s.747 - SEVERE [java_downloader] -> SEVERE Exception occurred java.net.SocketException: socket closed at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(Unknown Source) at java.io.BufferedInputStream.fill(Unknown Source) at java.io.BufferedInputStream.read1(Unknown Source) at java.io.BufferedInputStream.read(Unknown Source) at sun.net.www.MeteredStream.read(Unknown Source) at java.io.FilterInputStream.read(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(Unknown Source) at java.nio.channels.Channels$ReadableByteChannelImpl.read(Unknown Source) at jd.plugins.download.DownloadInterface$Chunk.download(Unknown Source) at jd.plugins.download.DownloadInterface$Chunk.run0(Unknown Source) at jd.plugins.download.DownloadInterface$Chunk.run(Unknown Source) 57s.747 - SEVERE [java_downloader] -> error occurred while writing to file. socket closed 57s.748 - SEVERE [java_downloader] -> Error occured: ERROR_LOCAL_IO 57s.748 - SEVERE [java_downloader] -> A critical Downloaderror occured. Terminate... 57s.748 - SEVERE [java_downloader] -> ABBORTED BY USER 57s.748 - WARNING [java_downloader] -> Download not finished. Loaded until now: 103449318/103809023 57s.748 - SEVERE [java_downloader] -> Error occured: ERROR_DOWNLOAD_FAILED 57s.749 - SEVERE [java_downloader] -> ABBORTED BY USER 57s.758 - SEVERE [java_downloader] -> DOWNLOAD INCOMPLETE DUE TO FILESIZECHECK 57s.758 - SEVERE [java_downloader] -> Error occured: ERROR_DOWNLOAD_INCOMPLETE 57s.758 - SEVERE [java_downloader] -> DOWNLOAD INCOMPLETE DUE TO FILESIZECHECK 57s.758 - SEVERE [java_downloader] -> Error occured: ERROR_DOWNLOAD_INCOMPLETE 57s.759 - WARNING [java_downloader] -> Error occured- latest:ERROR_LOCAL_IO 00100000001001000000000000000001 <Statuscode 00000000001000000000000000000000 |ERROR_LOCAL_IO 00000000000001000000000000000000 |PLUGIN_IN_PROGRESS 00100000000000000000000000000000 |PLUGIN_ACTIVE 00000000000000000000000000000001 |TODO 00000000000000000000000000000001 |VALUE_ID_PREMIUM_DISABLE ErrorMessage: No permissions to write to hard disk 02m:27s.107 - WARNING [java_downloader] -> Resumepoint not valid 20m:03s.367 - INFO [java_downloader] -> ByteBufferController: Used: 0 B Free: 12.59 MB 20m:37s.439 - FINER [java_downloader] -> load plugin: jd.plugins.decrypter.TbCm 30m:03s.333 - INFO [java_downloader] -> ByteBufferController: Used: 0 B Free: 12.59 MB 40m:03s.299 - INFO [java_downloader] -> ByteBufferController: Used: 0 B Free: 12.59 MB 50m:03s.265 - INFO [java_downloader] -> ByteBufferController: Used: 0 B Free: 12.59 MB 1h:03s.231 - INFO [java_downloader] -> ByteBufferController: Used: 0 B Free: 12.59 MB 1h:10m:03s.197 - INFO [java_downloader] -> ByteBufferController: Used: 0 B Free: 12.59 MB 1h:20m:03s.163 - INFO [java_downloader] -> ByteBufferController: Used: 0 B Free: 12.59 MB Last edited by briiii; 25.09.2009 at 03:16. |
#32
|
|||
|
|||
Indeed, I just queued up a ton of files in IDM, let that go, it lost connection a couple of times but resumed without issue (we are talking a big queue over 24 hours)
I then queued up the same files in jdownloader, what do you know? some no permission to write errors, and it couldn't resume. I love jdownloader because it has an awesome feature set that no other download manager has but it is failing in a pretty big area - the ability to resume a download. It can sometimes but too often it can't. I have been using download managers for years and never seen this problem before in any of them unless the server doesn't support resuming but in my case that isn't an issue. |
#33
|
||||
|
||||
Quote:
__________________
JD-Dev & Server-Admin |
#34
|
||||
|
||||
Quote:
__________________
JD-Dev & Server-Admin |
#35
|
|||
|
|||
my theory, the "No Permissions To Write To Harddisk" is a byproduct problem of the over active cpu problem. the cpu gets locked on whatever the problem we are trying to figure out. as a result of the excessive cpu usage JD loses track of the tcp or file write stream thus causing the write to hard disk error.
a temp work around is to put JD in low or medium priority (below normal) this will cause the OS to process file and tcp streams more often during cpu spikes thus limiting how the error occurs. also when the problem occurs use JD's reset option. sorry but you'll have to reDL the entire file. |
#36
|
||||
|
||||
Quote:
__________________
JD-Dev & Server-Admin |
#37
|
|||
|
|||
Today, i received this error too.
|
#38
|
|||
|
|||
Your hard disk is very probably working fine.
Typical recommendations, when you get this error message, are :- 1) Reduce the Max.Con. setting (bottom right corner of jD window) to 1. 2) Allow java and javaw in your firewall and virus software. 3) Disable the port 80/html/web scanner in virus software. 4) Un-install your firewall and reboot PC (this is safe when you've a firewall in your router). 5) Un-install virus software and reboot PC. 6) A torrent client is using too many connections; stop the client. 7) JRE version 1.6.0_17 ("**External links are only visible to Support Staff**) is 8) You've an unstable internet connection, contact you ISP. Please, implement these recommendations. If you still get the same error, please provide a detailed log. Look here for logging instructions. Last edited by remi; 28.01.2011 at 12:30. Reason: 1.6.0_17+21 |
#39
|
||||
|
||||
the *socket closed* bug should be fixed with new version
__________________
JD-Dev & Server-Admin |
#40
|
|||
|
|||
Bug was not fixed
Hello,
this bug still exists. have uploaded a log. http://jdownloader.net:8081/pastebin...e255e3a2393a59 most of the times you cant fix this error by resuming, you have to resest the file. i am downloading with 10 paralell downloads and 5 chunks. this error doesnt appear always, there appear to be bad days and good days. the last bad day before today was about 2 weeks ago, everytime else it simply works. cu acidburn |
Thread Tools | |
Display Modes | |
|
|