UI does not detect end of xtm files merge

[Damien Lecan]

I tried to merge 38 xtm files with GS (4Go).

I selected the first file, then clicked on "play" icon to start assembly.

GS did something (high CPU load, progression of progress bar) during 5 minutes. And nothing else happened (CPU to 0%, progress bar to 100%).
"Play" icon was never enabled again, "pause" and "stop" didn't do anything, "quit" was the only action which was successful.

But my file was correctly merged :)

I am not able to provide a copy of execution stacktrace (kill -3), but I looked at it with JConsole tool and no thread was suspiciously hung.

To sum up :
 - assembly of 38 xtm files (4Go) was successful
 - UI did not detect the end of assembly
 - Only "quit" action was successful ("pause" or "stop" didn't do anything)
 - xtm files were not deleted

Maybe fireEngineEnded() event was never fired ...

Configuration :
 - GS 0.3
 - md5 check to true
 - delete files on success to true
 - open file at end to false

[Guillaume Mazoyer (respawneral)]

I tested to split and merge a file of 4 Gio (with your parameters) and it works for me (MD5 sum ok, no more chunk files, and confirmation message). But there is something to notice. Actually, the MD5 sum check at the end of the merge is pretty long to do (about 1 minutes and 13 seconds on my eeepc 1000 HE). Moreover, I did not make a UI change during the MD5 sum check which can make the user think the software is stuck.

Did you really wait for the confirmation dialog or the notification to popup after the merge?
Anyway, there is still an enhancement of the UI that can be done. So I will work on it.

[Damien Lecan (dlecan)]

My CPU is an Intel E7300, much more powerful than Atom one.

> Moreover, I did not make a UI change during the MD5 sum check which can make the user think the software is stuck.

It's possible, GS UI was not frozen. Progress bar was glowing, but was at 100%. I did not see confirmation dialog.

I waited for a long time after merge, at least 5 minutes.

I had the time to launch jconsole, to check each thread application. None was busy.
If MD5 sum was running, I should have seen one thread in MD5Hasher.hashToString(...) for example.

I will try to reproduce the issue. It would be good to have a debug mode, with verbose traces to have something to give to you.

[Guillaume Mazoyer (respawneral)]

If the progress bar keep glowing it means that the progress is not really equal to 100%. So, I guess that there is a problem with a read variable that never take the value of the length of the last file (happened to me while writing the code the first time). Can you give me the exact size (in Kio or even in octets) of the file to be able to try to reproduce the bug on one of my computers?

[Damien Lecan (dlecan)]

Size of merged file or xtm files ?

[Guillaume Mazoyer (respawneral)]

Both :)

[Damien Lecan (dlecan)]

In octets :
...mkv.001.xtm : 103809128
...mkv.002.xtm : 103809024
   ...
...mkv.037.xtm : 103809024
...mkv.038.xtm : 38352420

Total after merge : 3879286276

[Guillaume Mazoyer (respawneral)]

Ok, now it is really awkward. I try to merge xtm files of the same size with GNOME Split 0.3 and the future 0.4. It works with both of the versions. Did you try to start GNOME Split in a terminal to see if there is any exceptions?

[Guillaume Mazoyer (respawneral)]

Eventually, I reproduced the bug. First, split a file using the official Xtremsplit software, then try to merge the created files with GNOME Split. A NullPointerException occurs at the end of the merge. I'll try to figure out why and fix it. The 0.4 version will stay unreleased until this bug will be fixed.

[Guillaume Mazoyer (respawneral)]

The fix has been commited. It is available using the revno 96 and Bazaar;
http://bazaar.launchpad.net/~respawneral/gnome-split/mainline/revision/96

The bug wes coming from a wrong check of the MD5 sums. In fact, I was using the MD5 sum of the original file while Xtremsplit uses the MD5 sums of each created files during the split.

It will be release with the version 0.4 of GNOME Split. Thank you for reporting it.