Open Video File Crash

[BetterRed]

Basic scenario right click Video folder, select Add existing files.

Sometimes it lands me in Windows\System 32\ pointing at the empty Configuration folder (which is a very odd place to land), other times it lands me the Program Files\Sigil. Neither location is where I ought have my video files. In Windows the designated location for videos is %userprofile%\Videos.

If in the file open dialogue I right click a file Sigil crashes:-


then


Why would I right click it... to play a bit of it to make sure its the right one.

Happens in ePUB 2 and 3. And with Audio files, probably happens with all file types. It's not unusual, for me at least, to open files in open file dialogues, I do it a lot, have done for years.

Aside : Would it be possible to give File New a submenu for ePUB 2 or ePUB 3. Bit of a nuisance having to change the 'standard' preference and then having to remember to change it back.

BR

[DiapDealer]

My right-click->add existing files dialog starts in the last folder I added an existing file from. Whether audio, video or any other type.

As far as crashes when right-clicking on files in Windows fileopen dialogs, it used to crash a lot on me too. It doesn't anymore (hasn't for me for a while), but by then, I'd already learned not to do it.

[BetterRed]

Originally Posted by DiapDealer

My right-click->add existing files dialog starts in the last folder I added an existing file from. Whether audio, video or any other type.

As far as crashes when right-clicking on files in Windows fileopen dialogs, it used to crash a lot on me too. It doesn't anymore (hasn't for me for a while), but by then, I'd already learned not to do it.

Ah-ha, the old blame the user trick. Once more people start building epub 3's, more people will be doing what I did.

What do we blame, Qt, Linux, the price of fish in Denmark. It'll be hard to pin this one on MS because I do it regularly in other several other programs every day. I know lets blame Google like the EU is for their failed mobile phone companies.

I get the last folder within a session, but next session its usually the Sigil folder and sometime System 32 - maybe because it been crashing rather than existing gracefully

BR

[Doitsu]

Originally Posted by DiapDealer

My right-click->add existing files dialog starts in the last folder I added an existing file from. Whether audio, video or any other type.

It's the same on my 64bit Windows 10 machine. Even when I copied a video file to the System 32 folder and added it from there to an ePub Sigil wouldn't crash.

@BetterRed:

• What's your OS and your Sigil version?
• Do you use the portable version or the official release?
• Do you get the System 32 folder also with the open file dialog of other apps, e.g. Word?
• Is there anything special about the multimedia files (large size, unusual codec etc.)?

[BetterRed]

Originally Posted by Doitsu

It's the same on my 64bit Windows 10 machine. Even when I copied a video file to the System 32 folder and added it from there to an ePub Sigil wouldn't crash.

@BetterRed:

1. What's your OS and your Sigil version?
2. Do you use the portable version or the official release?
3. Do you get the System 32 folder also with the open file dialog of other apps, e.g. Word?
4. Is there anything special about the multimedia files (large size, unusual codec etc.)?

1. What's your OS and your Sigil version?
   Win 10 64bit 1511 up-to-date as of Now
2. Do you use the portable version or the official release?
   No I have this installed - 48.7 MB Sigil-0.9.5-Windows-x64-Setup.exe
3. Do you get the System 32 folder also with the open file dialog of other apps, e.g. Word?
   No nothing else takes me to System 32, not even my fingers - Office programs Open File takes me to the relocated %userprofile%\Documents - D:\Documents - but I rarely use Open File in anything, either I start at the data and use Open With or I start the program and use File New, most of them give me a blank file, which I save ASAP with the name I want and where I want it.
4. Is there anything special about the multimedia files (large size, unusual codec etc.)?
   Not as far as I know, They all play in the various viewers/editors I have. No DRM protection, they're either public domain or given privately by the originators. They're things like talking heads and radio podcasts from MSM sources, press conferences from party sources, and think tank tank briefings. Dry as dust.
   What do you call large - I doubt anything I tried was beyond 1GB, the MP3 was < 4MB, the AVI was about 600MB - I didn't set out to stress test it

But don't fixate on that they were media files. Sigil crashes as soon as I right click on any file in any Book Browser folder's Add Existing file Open File dialogue - including an HTML file in the Text folder. Not when I select something from the context menu, but as soon as I right click (or hit the menu key) on a file. Try it on the HTML in the Attached Zip.

I must say I am a bit surprised I am the first to discover this, it seems so fundamental. See a list of files, right click - is the menu what you'd expect to see?

BR

[Doitsu]

Originally Posted by BetterRed

But don't fixate on that they were media files. Sigil crashes as soon as I right click on any file in any Book Browser folder's Add Existing file Open File dialogue - including an HTML file in the Text folder. Not when I select something from the context menu, but as soon as I right click (or hit the menu key) on a file. Try it on the HTML in the Attached Zip.

I wasn't able to add the attached HTML file with Mend on Open disabled, but I had no problems adding it with Mend on Open enabled. Also right-clicking other files didn't cause a crash.

Have you tried to delete sigil.ini? This'll often fix some weird problems.
(Make sure to create a backup copy first, just in case you use custom settings.)

If deleting sigil.ini doesn't make a difference, maybe DiapDealer or KevinH can tell you how to locate the Qt/Sigil crash log, which might provide additional information.

[DiapDealer]

Originally Posted by BetterRed

Ah-ha, the old blame the user trick. Once more people start building epub 3's, more people will be doing what I did.

What do we blame, Qt, Linux, the price of fish in Denmark. It'll be hard to pin this one on MS because I do it regularly in other several other programs every day. I know lets blame Google like the EU is for their failed mobile phone companies.

Little dramatic, don't you think? It's quite simple, actually. We blame Qt. Because it's Qt's file dialog call that is causing the crash. There is no magic, "please make Qt bring up a native file open dialog that won't crash on Windows when I right click inside of it" code There is only "bring up a file open dialog and return control to me after the user selects some files" code.

It could also be a combination of a misbehaving third-party shell extension and a Qt quirk.

And you're not the first to discover the right-click inside a Windows file dialog crash. There's been a few reports of it here and there (including from myself) along the way with Sigil. It just seems to be very machine specific.

This Qt bug report has been around since 2013 with people experiencing your right-click crash. Comments show people experiencing it with Qts ranging from 4.8.4 to as recent as Qt5.5.0 (with no resolution).
https://bugreports.qt.io/browse/QTBUG-33119

[KevinH]

Yes and has also been associated with Dell and other mfg shell extensions. What pc mfg are you using?

[HarryT]

Originally Posted by DiapDealer

Little dramatic, don't you think? It's quite simple, actually. We blame Qt. Because it's Qt's file dialog call that is causing the crash. There is no magic, "please make Qt bring up a native file open dialog that won't crash on Windows when I right click inside of it" code There is only "bring up a file open dialog and return control to me after the user selects some files" code.

Would one not, in that case, also expect the same issue to arise in other applications which use Qt, such as Calibre? I don't recall ever having seen this issue reported in Calibre.

[DiapDealer]

Originally Posted by HarryT

Would one not, in that case, also expect the same issue to arise in other applications which use Qt, such as Calibre? I don't recall ever having seen this issue reported in Calibre.

It's pretty rare in the first place (both because it IS device specific and because not a lot of people right-click inside of a file-open dialog) The fact that you've not heard of the issue happening with calibre does not mean that it never does (or ever did). Kovid is also more willing to go a lot of extra miles to work around Qt limitations/issues than I am. It's quite admirable on his part, but unless it's a wide-spread issue that's easily reproduceable (and affects a significant portion of the userbase in a dramatic way), I tend to want to leave Qt bugs for Qt to fix (or not).

If someone were to come up with definitive steps to reproduce this particular Qt/Windows/C++ chupacabra consistently (or Kovid points us to where he's encountered and beaten this bug), then a workaround will certainly be quickly sought to remedy it, if at all possible.

[Toxaris]

I haven't tested with Sigil 0.9.5 yet (I am still on 0.9.4), but if I add a video and right-click on a video in the 'open file' dialog, it works without a crash. It might be that the view of the directory (list, images, details) might also be a factor.

[Doitsu]

Originally Posted by Toxaris

It might be that the view of the directory (list, images, details) might also be a factor.

I have exactly the same Windows version as BetterRed and changing the view settings also didn't cause Sigil to crash. (I tried all of them.)
As DiapDealer has already pointed out, it might be a third party shell extension that causes this issue.

Another possibility is a misbehaving graphics driver.

@BetterRed: Check the event log for relevant information.

[HarryT]

Originally Posted by DiapDealer

It's pretty rare in the first place (both because it IS device specific and because not a lot of people right-click inside of a file-open dialog) The fact that you've not heard of the issue happening with calibre does not mean that it never does (or ever did). Kovid is also more willing to go a lot of extra miles to work around Qt limitations/issues than I am. It's quite admirable on his part, but unless it's a wide-spread issue that's easily reproduceable (and affects a significant portion of the userbase in a dramatic way), I tend to want to leave Qt bugs for Qt to fix (or not).

An entirely reasonable perspective, to be sure. Thanks!

[kovidgoyal]

I dont recall ever seeing a report for this particular issue in calibre, only one where simply opening the File dialog causes a crash.

I'd guess this is almost certainly caused by a shell extension incompatibility. Windows has this crazy design where shell extensions are arbitrary executable code that is injected into any process that uses a windows standard file dialog. Common cause of incompatibility is when the shell extension uses a DLL that the host application also uses, but in an incompatible version.

You can investigate which extension is causing the problem relatively painlessly by using the technique described in the last bullet point here: https://manual.calibre-ebook.com/faq...s-occasionally

[DiapDealer]

Thanks for the insight Kovid. Always appreciated. The Nirsoft Shell Extension Viewer sounds like it would be particularly useful if someone who's experiencing the crash were willing to use it to help track down what extension(s) might be acting up.

Any merit to subclassing QFileDialog to avoid the native filopen dialog? Or would the arbitrary extension code still fire?