#1
|
|||
|
|||
multiupload: strange split
Spoiler:
**External links are only visible to Support Staff****External links are only visible to Support Staff**
* after analysis the links were split to two bins, not kept in single one. * and zshare (while sharing the bin with most others) shows different file size. Log does not show no info about decrypting / clustering, so i only can wonder why? |
#2
|
||||
|
||||
It's quite simple, The uploader uploaded with different filenames. JD can remove _ and . and convert to space within the (settings > basic > user interface > linkgrabber) this will then place all the files with similar names into the same package for you then.
on your second point well hosters display filesizes differently, some round (up or down) some use .x decimal some .xx for instance. So filesize will show discrepancy as its out of our control. And also multiupload has nothing to do with megaupload so I'll change your forum heading
__________________
raztoki @ jDownloader reporter/developer http://svn.jdownloader.org/users/170 Don't fight the system, use it to your advantage. :] |
#3
|
|||
|
|||
For what i remember, filenames were not same in bins yesterday. Maybe i'm wrong, today they are split by filenames. I' better do screenshot yesterday :-)
That's obvious. what server sends is what jD displays. But shouldn't JD split the sources to different bins, when sizes do not match ? Yeah, my bad. 'twas brain dead night. :-) |
#4
|
|||
|
|||
This file renaming is independent of the uploader. The uploader just uploads one file to MuU.
It's the hosts that rename the files. In this case it's FSc and WL. The other hosts keep their hands of the file name. |
#5
|
|||
|
|||
of course server does renaming. I't just that i checked that yesterday and - for what i remember - names were not cnsistent in bins and thus were not the reason of split. But probably i'm wrong about that.
But file size difference being kept within same bin still amazes me. |
#6
|
||||
|
||||
packages are determined by plugins like decrypters, or common filenames. It has nothing to do with file sizes as explained for the reasons above.
__________________
raztoki @ jDownloader reporter/developer http://svn.jdownloader.org/users/170 Don't fight the system, use it to your advantage. :] |
#7
|
|||
|
|||
Is it planned for jD to support parallel downloading of file form several sources (aka mirrors) ? If so, then it would be better to do unnecessary split, rather than ignore filesize in comparision.
|
#8
|
|||
|
|||
I think the best way to deal with this is that jD tries to find the file name pattern by removing all the special characters.
Also see |
#9
|
||||
|
||||
We won't be splitting files based on filesize at this stage as it's not useful way of determinating actual filesize. Advertised filesizes can range due to rounding etc (as explained), if we do any checks it will based on filesize reported in HTTP header when downloading the final file and not the advertised filesize (rounded) on the website. Some linkchecking API's can give us the real filesize and checksum hashes prior to downloading we can also use them when possible.
__________________
raztoki @ jDownloader reporter/developer http://svn.jdownloader.org/users/170 Don't fight the system, use it to your advantage. :] |
Thread Tools | |
Display Modes | |
|
|