Help and Support
Ask a question, report a problem, request a feature...
<<  Back To Forum

File Too Large Error
Page 2 of 2     <<<12   >   >>  
by Guest on 2019/09/21 03:43:07 AM    
This bug is still around. I recently been ftp downloading from a seedbox, then I use the .torrent file to force check my download in tixati as I feel it's a good way to verify the ftp transfer was good as I stop and resume a lot of times in the ftp client. But this file too large error happens.
by Guest on 2019/09/25 07:40:10 AM    
that happend when you unarchivate or ad new file in file folder of the same torrent ,and hi become larger than size  that tixati thinks must to be. sorry for my poor english.
by Napsterbater on 2019/09/27 11:10:06 PM    
This error means the file already/currently exist AND is bigger then the file specified by the torrent.

Not that the file is too big for the filesystem.
by Guest on 2019/12/19 05:59:45 AM    
so if tixati thinks a file is too big for the torrent, wouldn't the correct procedure during a check be to DELETE the non-matching block and download it again?

Instead Tixati throws up its hands and goes screw it I'm not doing anything; manual intervention required, you need to manually delete all the changed blocks or files, and then, maybe it will start again. (Until the next FILE TOO LARGE file)

Just, for the love of all of us who hit this problem, delete the bad blocks and move on instead of error to a dead stop.

A very common torrent with this problem are mame rom packs.

they update EVERY month. Common practice is to stop old torrent, download new torrent, point to same files from old. Torrent software checks, finds differences, get rid of non matching blocks REGARDLESS OF SIZE, download missing blocks, (usually only 10-15% change), and you're at 100% again.

That's all clients BUT Tixati! Tixati hits a changed rom you already have an old copy of, and when it doesn't match, it just goes FILE TOO LARGE, and STOPS. Completely frustrating, and WORTHLESS as a failure mode.

We've begged for this to be fixed.... PLEASE fix it!!!!!!
by Guest on 2019/12/26 04:57:33 AM    
have this same issue when i have one file being used to seed multiple torrents. Tixati increases the file size and makes the program think its the incorrect file, very big issue when trying to save space and still seed properly, or when trying to revive a dead torrent.
by Guest on 2020/03/08 03:36:26 PM    
For me, it is simply two files that I opened with an e-book reader. The reader apparently added a bookmark or other information to the original file, annoying but not a disaster.
by Guest on 2020/12/12 11:19:33 AM    
Problem is still here. Had to manually find and delete "too large" files. And then redownload 42GB. Such approach looks very inconvenient for a torrent client.
It there is no way to replace only changed parts of a file then do not make user to search and delete these files manualy at least.
by Guest on 2020/12/12 09:06:02 PM    
Same problem when trying to download a torrent from 1.03 rip filed version to new renewed 1.04 version. Here is link: (Link removed by Mod and sent to Devs) Here is printscreen (Link removed by Mod and sent to Devs) Pls help with that. I dont want use uTrash or smth after 6 years of using Tixati.
by Guest on 2020/12/16 06:19:40 AM    
Best you can do in this situation is to download the whole torrent then spare for your needs, in the past I made the terrible mistake of selcting files within a torrent file, the selected files shared missing parts with the files that were not downloaded, usually one piece or a few more, it could also indicate a memory (RAM) problem.
by Guest on 2021/01/11 09:28:29 PM    
was going to type a lot of words, but basically this :

"so if tixati thinks a file is too big for the torrent, wouldn't the correct procedure during a check be to DELETE the non-matching block and download it again?

Instead Tixati throws up its hands and goes screw it I'm not doing anything; manual intervention required, you need to manually delete all the changed blocks or files, and then, maybe it will start again. (Until the next FILE TOO LARGE file)

Just, for the love of all of us who hit this problem, delete the bad blocks and move on instead of error to a dead stop.

A very common torrent with this problem are mame rom packs.

they update EVERY month. Common practice is to stop old torrent, download new torrent, point to same files from old. Torrent software checks, finds differences, get rid of non matching blocks REGARDLESS OF SIZE, download missing blocks, (usually only 10-15% change), and you're at 100% again.

That's all clients BUT Tixati! Tixati hits a changed rom you already have an old copy of, and when it doesn't match, it just goes FILE TOO LARGE, and STOPS. Completely frustrating, and WORTHLESS as a failure mode.

We've begged for this to be fixed.... PLEASE fix it!!!!!!"
by Guest on 2021/04/18 02:10:07 AM    
i'm getting this error with 2.81 on fully updated Windows 10 20H2.
by Guest on 2021/05/13 07:10:19 PM    
Just randomly got hit by this for 3 albums I torrented, still looking for a solution....
Latest version of TIXATI been using the software since 2010 never had this come up before
now hit on 3 torrents in 2 days, not sure what the hell is going on.
by Guest on 2022/08/08 08:18:29 PM    
This error is really caused by the file existing, but being too large. Some torrent clients can allocate too many bytes (larger than defined in the torrent).

If you're sure the file is correct and you want to strip the extraneous bytes to allow Tixati to check the file without having to re-downloading it, it can be done in the following way:

1) first find out exactly how many bytes the offending file should take up. this can be done by opening the torrent file in BEncode Editor.
2) now that you know how many bytes the file should take, truncate the existing file. `truncate` from GNU coreutils (part of Git for Windows or MSYS2) can be used to do just that - for instance: truncate -s 6519133744 'C:\tixati_files\my_holiday_pix.rar'

this is not exactly simple or intuitive, but I hope it helps someone.
by Guest on 2022/08/26 07:57:10 PM    
This definitely should be change. Some torrent may be updated and you can redownload it. Cleint should check and start downloading new files. Now you need to delete every big file manual. Why this behavior? uTorrent have this many years.
by Guest on 2022/11/29 03:25:40 PM    
Hi,

Here too; I have this same problem, only since recently.
Right now it affects 16 of +/- 1000 torrents.
The strange thing is, that the size is actually what it should be, but still it reports "file too large".

So, f.i., a file of 8.060.377b that should be 8.060.377b reports as "file too large"

Where does this come from?

Kr,
Timo
by Guest on 2022/12/01 01:39:17 PM    
*update*
The number of torrents showing "file too large" or "file mismatch" is slowly adding up.
As a strange side-result, when restarting Tixati, instead of doing the quick-scan it usually does, most torrents are showing "scanning 0%", while none is actually being scanned.
Somehow it ened in an error-loop, where the "file too large" torrents ended up blocking the scanning process.

And now I don't know which torrents to delete, since all of them show their "normal" status, not the "file too large" or "file mismatch".
Because they are not being scanned. Scanning simply doesn't happen?
by Guest on 2023/05/21 09:54:32 AM    
<<<SOLVED>>>

Hey all, I just had this problem myself.  I was also wracking my brains over what could possibly by the problem.
I think I figured it out! (at least in my case...)

I was keeping track of which serial numbers I had been using for this particular torrent, and what workstations I'd used them at.  I made the mistake of typing this information INSIDE the .txt file which came with the torrent (e.g., the "README").  Apparently, just that minor change increased the size (and therefore altered the checksum) enough that Tixati looked at it as being "too large" - because it apparently had 1kb more information now, than before (if that).

So keep an eye out for any alterations you might've made to the files themselves, or anything else that could increase the size or alter the checksum which you did unintentionally.  I'm glad I stumbled across this thread, and I'm also glad I can post this as a guest.  Thank yoU!
by Guest on 2024/02/02 08:01:58 AM    
I have exactly some problem:
>>by Guest on 2017/05/10 06:45:30 AM    
>>The same error happens when rechecking updated torrents.
>>Presumably, problems is that Tixati cannot check correctly check file if it is less than 1 bt block.
>>Let me give an example.
>>Let's say torrent v1 contains files
>>and block size is 4mb.
>>Its updated version v2 contains  with same block size.
>>
>>If you first download v1, then remove v1 while keeping the files, and then try to add v2, Tixati will give "file too large" error.
>>
>>
>>Since subtitle files are often less than 1 mb and it is commonly for some trackers to update its releases, I met this error regularly. And it is quite annoying.

This error very annoying, please fix it. After adding v2 torrent "Force check" not working at all, with "file too large" error.
by Guest on 2024/02/02 10:55:03 PM    
At Guest 2024/02/02 08:01:58 AM:
It's user error.
If the subtitles are updated within the video container (for example inside .mkv), likely all the blocks are misaligned, recheck attempts will likely show 0%.
If the subtitles are updated in separate files (like .sub, .srt) just delete the v1 subtitle files and then do force recheck. Tixati will create and download the new subtitle files only.

Tixati has no idea why the file became smaller or bigger so it leaves it alone when you try to recheck. I think it's a feature, not a bug. Although I agree the message could be more descriptive.
by Guest on 2024/03/25 05:22:55 AM    
I've gotten the "File too large" error often.  My fix is to keep a copy of uTorrent around and use it to force a recheck of the file(s).  Once uTorrent finishes the recheck reload the file(s) in Tixati and they always work fine (for me anyway).  I hope this helps.
Page 2 of 2     <<<12   >   >>  
<<  Back To Forum




This web site is powered by Super Simple Server