Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Morse]

and one more time i can't preview the file i'm downloading with the error "avi: can't find index" till the very end. i have "download first and last" checked, and according to the graph amule did download something in the end of file.
So the question is: can it be that the problem is in the last chunk being too small for the index?
If yes then the request is to increase priority not only of the last chunk, but also of the pre-last if the last is small (what is small - i don't know, but the index surely have to have some average size)

[Stu Redman]

Did you try VLC? It can preview AVIs without the index, so I think the feature is pretty obsolete.

[GonoszTopi]

Code: (src/PartFile.cpp) [Select]

// Criterion 2. Parts used for preview
// Remark: - We need to download the first part and the last part(s).
//        - When the last part is very small, it's necessary to
//          download the two last parts.
bool critPreview = false;
if(isPreviewEnable == true) {
if(cur_chunk.part == 0) {
critPreview = true; // First chunk
} else if(cur_chunk.part == partCount-1) {
critPreview = true; // Last chunk
} else if(cur_chunk.part == partCount-2) {
// Last chunk - 1 (only if last chunk is too small)
const uint32 sizeOfLastChunk = GetFileSize() - uEnd;
if(sizeOfLastChunk < PARTSIZE/3) {
critPreview = true; // Last chunk - 1
}
}
}
I.e. if the last part is smaller than 3242666 bytes (~3MB) we assign high priority to the penultimate part, too.

[Morse]

hmm...

then it must be badly muxed avi or something...

[zagar]

No, it isn't . Without an AVI index, you can just play the beginning, but no seek  and maybe no FF / REW . Unfortunately, you cannot guess the index size unless analyzing the muxed stream, which is obviously outside amule's scope. The current approach, shown by GonoszTopi, is a good compromise indeed.

It was good compromise when most files were not bigger than 700MB.
With larger files, more chunks are needed.

For example, 2 or even 3 last chunks are needed for 1.5 GB files.

[Morse]

It was good compromise when most files were not bigger than 700MB.
With larger files, more chunks are needed.

For example, 2 or even 3 last chunks are needed for 1.5 GB files.

very probable this is the case. sometimes i download video files of the size 3+ GB, and very often only beginning is available for preview till the very end. And i don't think that bad muxing is the only problem, because most of that files are "mkv", and i really doubt that there is such a thing as "badly muxed mkv".

[Stu Redman]

Does MKV even have an index at the end like AVI?
Oh, and I think you can mux anything badly. 

[Vollstrecker]

Maybe we can change that to something like "one chunk at the at (without conting anything below 50% of the chunk) per 500MB filesize".

[Stu Redman]

Maybe we can change that to something like "one chunk at the at (without conting anything below 50% of the chunk) per 500MB filesize".

Hmm, that would mean 2% of the file are not evenly distributed, which is bad for sharing. Even worse, while trying to get the indexes first the actual preview data (beginning of the video) is neglected.

Is preview really so important? Looking at the filenames usually is enough for me to weed out fakes.
And I think the main question is if the codec is able to skip blank (all-zero) parts and resync afterwards in finite time.

[zagar]

Hmm, that would mean 2% of the file are not evenly distributed, which is bad for sharing.

Probably less, because the option is disabled by default.

Even worse, while trying to get the indexes first the actual preview data (beginning of the video) is neglected.

What about adding a separate option for indexing?

[Vollstrecker]

Is preview really so important? Looking at the filenames usually is enough for me to weed out fakes.
And I think the main question is if the codec is able to skip blank (all-zero) parts and resync afterwards in finite time.

MPEG is able to jump over zeros or garbage, but resync isn't really needed. If I see naked people or hear spanish dialogs, I can be sure it's not what I wanted, regardles if it's syncronized or not.

[Stu Redman]

If you point a codec at a random point in a file it won't be able to show neither naked people nor Spanish dialogs until it finds a point to resync and recognize the start of a key frame or an audio sample within the gibberish. And depending on the encoding this may be easy, hard or even impossible.

What about adding a separate option for indexing?

Which should do what?

[Kry]

I'm Spanish AND naked.

[Vollstrecker]

And I AM damned sure that I DON'T want to see that.

[Stu Redman]

I'm Spanish AND naked.