Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jpylyzer demo crashes/freezes on corrupted JP2s (Linux only) #6

Open
bitsgalore opened this issue Aug 14, 2014 · 2 comments
Open

Jpylyzer demo crashes/freezes on corrupted JP2s (Linux only) #6

bitsgalore opened this issue Aug 14, 2014 · 2 comments

Comments

@bitsgalore
Copy link
Member

Running the jpylyzer demo under Linux Mint (17),if you click on the “Browse” button, a file manager window pops up.

By default this displays a preview of recognized image files (incl JP2). If the folder contains any JP2s that are corrupted, this causes the file manager + browser to either freeze (Firefox) or crash immediately (Chromium).

Not 100% sure, but I suspect this is related to this ancient bug (in which case other Linux distros will be affected as well):

https://bugs.launchpad.net/ubuntu/+source/jasper/+bug/427100

Obviously this is not a bug of the demo, but it makes it pretty much impossible to use it with any faulty JP2s (which is sort of the main point of the demo!).

Already tried this:

  • Disable previews for all files in the file manager’s settings. That works if I manually fire up the file manager, but it doesn’t have any effect if the file manager is started by the browser.
  • Change file manager that is used by browser: neither Firefox nor Chromium allow this!
  • Change default file manager to xfe: no effect whatsoever.

A bit lost on this; I guess the demo will still work under Windows (I can't test this, as I can't get Vagrant running on my Windows machine).

@bitsgalore
Copy link
Member Author

Workaround to get the demo working under affected Linux distros: installl a Windows version of the browser under Wine. That way the libraries that cause the freezes/crashes are completely circumvented. Works for me with FireFox (although as a solution it's a bit silly).

@lecs
Copy link
Contributor

lecs commented Aug 19, 2014

Hi, one work around for the moment could be: the URL input field probably doesn't cause this problem, as it does not call a preview window to open. so you could use the local url of a file (file:// ..) to check local files, also on linux. It's odd but should work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants