#31 Improve the stability of mcomix


Hello, as an old user of comix, I think I can agree that mcomix was a fork well motivated and could improve greatly comix which was really nice but with no further improvements. But comix had the great quality of being quite stable. I cannot say that much for mcomix. It happens often to me that mcomix stays stuck, with UI not responding, prevent message-less crashing or such things that could really reduce the user experience.

My message is to ask you to publish stable version. Improve stability can take several way : improve the internal architecture of mcomix, track bugs or wrong design in the UI, factorization of code, etc.

Being a python programmer on my spare time, I will be glad to help you improving mcomix, but I am not sure what could be done at a first task, and I think you mcomix developper are more able to see what are the weakest points in the mcomix soft. So thank you to read my message, I hope you will help me to enjoy mcomix again much more !


  • Oddegamra

    Oddegamra - 2011-11-12


    unless you can provide a concrete, preferably reproducible situation where MComix hangs, there is very little I can do. I've been using MComix to open literally thousands of archives over the past year, and didn't see a hang once (well, unless I was actually working on the codebase).

    That being said, someone reported an issue with RAR handling on Fedora 16 alpha while back, but according the said person, the issue disappeared over time. Maybe you are experiencing similar problems?

  • dirtyepic @ gentoo

    I have also seen several instances of mcomix freezing when opening an archive, but unfortunately nothing reproducible. It displays a solid black background and the thumbnails on the side are also all black, and the UI does not respond. Killing the program and opening the archive again always works. I imagine there may be a race condition somewhere between the unpacking of the archive and the display of the contained files, but that is just a hunch. In any case it happens very infrequently, maybe once a week for me.

  • Oddegamra

    Oddegamra - 2011-12-12

    This might be a likely cause, but I had no luck trying to find anything as of yet. I believe that the error might lie somewhere between
    a) Execution of an external extraction program (Zip archives always work, and libunrar does as well)
    b) Threading
    c) Waiting on some condition.

    Back on the aforementioned Fedora 16 alpha build, I managed to backtrace the crash into the subprocess.Popen constructor - it simply never returned. Granted, this might have been a side-effect of using an alpha build, but maybe the mutex devices used to synchronize extraction lock up something in the Python core that cannot be released when Python forks a new process.

    That, or I simply suck at writing multithreaded applications.

  • David Kremer

    David Kremer - 2011-12-12

    I must say that I tried to open a .rar archive protected by a password, and mcomix freezed.

    This is reproducible because it happens every time.

    Actually I would think of a good way to improve stability, that is to say to develop a mcomix separate component that would take in charge the archive management (unzipping, browsing, etc). Because here it seems that the UI get frozen by archive management tasks. Actually a separate thread for archive management could be much better and would be a way to show the user what the application is doing without freezing the whole UI. I already have some ideas in implementing such a thing, and would be glad to contribute some code.

  • Nobody/Anonymous

    I see your point concerning password-protected rar archives. Apparently, code locks up here because the rar executable is expecting user input for the password, which will obviously never happen. I commited a fix for this.

    As for separation of UI and extraction code - I have been working on reducing waits from the UI on archive mutexes for a while. Unfortunately, some waits are hard to avoid as things are now. If you have material to contribute here, I'd more than happily receive it.

  • Alan Horkan

    Alan Horkan - 2012-01-31

    It is good that you are finding ways to reduce wait times but I the basic assumption needs to be that wait time (could be potentially ^W^W^W) is very very long and provide users with lots of feedback.

    It may sound ridiculous but I have a comic archive that is almost 1GB with over 1200 pages. Whoever put it together decide they wanted to pack the entire series into one single enourmous comic archive. So even though MComix will work correctly and open this archive it does take. I've a couple of book scans that also approach this absurd size and even though these cases are outliers a great level of feedback during loading could be beneficial to all users.
    (I hesistate to proscribe implementation details and go so far as to make a request for a loading progress bar -- which might be more hassle to implement than it is worth -- but ultimately I know you'll prioritise the features you want to work on and there's no harm in suggesting it.)

    MComix doesn't seem as stable as Comix was but for the most part it works for me. Which isn't to say David wasn't unlucky and I'll keep an eye out for problems. It probably helps that I preconvert most of my archives into ZIP and I open them in another program that fails in different ways so I have a better chance of learning if an archive is corrupt or broken in some other way before it get it to MComix.


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks