1.6.5,1.6.4,1.6.3 fail to calculate filesize correctly

[cbxbiker61]

Counting versions with this problem 1.6.3, 1.6.4, 1.6.5.

Happens on x86_64.

This time I tried to save it to an XFS partition as well as EXT4, so it doesn't seem to be partition type dependent.

Will you please fix your over-exuberant disk space check in makemkvcon. At least allow the program to copy the file instead of having it skipped (sometimes the user is smarter than the program).

It won't copy a 21 gig file when there is plenty of space.

The size of output file '/home/kelly/Videos/Wall·E_Disc_1/title00.mkv' may reach as much as 21697 megabytes while target filesystem has a file size limit of 0 megabytes. Do you still want to continue (title will be skipped)?

The size of output file '/home/kelly/Videos/Wall·E_Disc_1/title00.mkv' may reach
as much as 21697 megabytes while target filesystem has a file size limit of 0
megabytes. Do you still want to continue (title will be skipped)?

df -h .
Filesystem Size Used Avail Use% Mounted on
/dev/sda10 230G 85G 133G 39% /home

grep home /etc/fstab
/dev/sda10 /home ext4 defaults 1 2

[cbxbiker61]

Ok I did some checking on my machine just to see where the problem may lie (although it would be nice to have the source code so I could just fix it). I'm assuming that there's a call to rlimit in makemkvcon that's causing the problem. Here's some code that demonstrates where the potential fix is, it should be a one line fix.

Code: Select all

#include <sys/time.h>
#include <sys/resource.h>
#include <stdio.h>

int main(void)
{
        struct rlimit lim;

        getrlimit(RLIMIT_FSIZE, &lim);

        if ( lim.rlim_cur == RLIM_INFINITY )
        {
                printf("soft limit is INFINITY\n");
        }
        if ( lim.rlim_max == RLIM_INFINITY )
        {
                printf("hard limit is INFINITY\n");
        }

        printf("soft=%lu, hard=%lu\n", lim.rlim_cur, lim.rlim_max);
        return 0;
}

The output on my machine is as follows:

Code: Select all

soft limit is INFINITY
hard limit is INFINITY
soft=18446744073709551615, hard=18446744073709551615

After running "ulimit -f 9999000" :

Code: Select all

soft=10238976000, hard=10238976000

[mike admin]

Ok I did some checking on my machine just to see where the problem may lie (although it would be nice to have the source code so I could just fix it).

The 1.6.5 was supposed to fix it. In fact this code was moved to open-source portion in 1.6.5, please see SYS_nstatfs function. Can you please compile a small application that calls SYS_nstatfs taking the path to _directory_ where you save the files, and see if values filled in SYS_statfs in structure make any sense.

[cbxbiker61]

OK, good news. I put a debug fprintf(stderr... in SYS_nstat to see what was happening and it turns out that the directory name for the Wall-E Bluray is using a non-standard character that is throwing SYS_nstat off.

So to fix this problem properly in makemkv, it looks like the solution is to "cleanup" the target directory name by converting it to a utf-8 string.

This is what I got by default when running makemkv, and it causes the disk space error:

SYS_nstat(/home/kelly/Videos/Wall?·E_Disc_1/title00.mkv)

I simply overroad the destination directory name by stripping out the non-standard character and it works:

SYS_nstat(/home/kelly/Videos/WallE_Disc_1/title00.mkv)

Thanks for looking in to this problem. It should be pretty easy to fix in the next version of makemkv.

[sbg12345]

Hi all,

just want to say that the problem still exists in the current version:

Code: Select all

makemkvcon mkv iso:Disk_1.iso 0 Disk_1
MakeMKV v1.6.12 linux(x64-release) started
Using direct disc access mode
Title #0 was added (12 cell(s), 0:40:59)
Title #1 was added (10 cell(s), 0:41:00)
Title #2 was added (11 cell(s), 0:41:00)
Title #3 was added (9 cell(s), 0:41:04)
Title #4 has length of 69 seconds which is less than minimum title length of 120 seconds and was therefore skipped
Title #5 has length of 24 seconds which is less than minimum title length of 120 seconds and was therefore skipped
Title #6 has length of 24 seconds which is less than minimum title length of 120 seconds and was therefore skipped
Title #7 has length of 11 seconds which is less than minimum title length of 120 seconds and was therefore skipped
Title #8 has length of 11 seconds which is less than minimum title length of 120 seconds and was therefore skipped
Operation successfully completed
Saving 1 titles into directory Disk_1
The size of output file 'Disk_1/title00.mkv' may reach as much as 953 megabytes while target filesystem has a file size limit of 0 megabytes. Do you still want to continue (title will be skipped)?
Title 0 skipped
0 titles saved
Copy complete. 0 titles saved.

In fact the filesystem is ext4 and has a size of 640 GB. Gui Version works perfect, but converting many iso-files is easier with makemkvcon.

Thanks in advance!

[cbxbiker61]

OK, I finally took the time to look at the code and figure out what was really going on with the "Wall-E" disc. Wall-E's disc title is "Wall·E_Disc_1". The dot in the title is not a valid filesystem character, so it was erroring (with a bogus error). Here's the patch:

Code: Select all

--- ./makemkvgui/inc/lgpl/appshared.h.orig	2011-09-22 04:59:48.000000000 -0600
+++ ./makemkvgui/inc/lgpl/appshared.h	2011-09-22 11:27:28.395233129 -0600
@@ -42,7 +42,7 @@ inline void AppMakeCorrectFileName(uint1
         {
             c='_';
         }
-        if (c==0x2013)
+        if ((c == 0xB7) || (c==0x2013))
         {
             c='-';
         }

[mike admin]

Thanks.

[shajil]

Well, if I could remember the reason why the version 1.6.5 came out was to solve this very issue. Anyway, it seems a new update is necessary for calculating the file size aptly. By the way, it is good that you have come up with a code regarding this to fix it for now.