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

Surface more useful error messages on export failure #1450

Closed
ferdnyc opened this issue Mar 30, 2018 · 3 comments
Closed

Surface more useful error messages on export failure #1450

ferdnyc opened this issue Mar 30, 2018 · 3 comments
Labels
💡 enhancement This issue describes an improvement, enhancement, or feature request for OpenShot stale This issue has not had any activity in 60 days :(

Comments

@ferdnyc
Copy link
Contributor

ferdnyc commented Mar 30, 2018

Currently when the export process aborts, the user is shown the "Export Error" dialog. It contains a generic message about the type of error encountered:

Sorry, there was an error exporting your video:
Error while writing raw video frame

That "error type" is also logged in openshot-qt.log

export:INFO Error type string: Error while writing raw video frame

(Only!) if OpenShot is in debug mode, libopenshot.log will include a write_video_packet message containing the reason why the write failed, e.g.:

FFmpegWriter::write_video_packet ERROR [No space left on device] (error_code=-28.0000)

There are two issues with that.

  1. The application shouldn't have to be in debug mode for libopenshot to log an error message.
  2. The exact reason for the error (in this case, "No space left on device") should be displayed to the user in the "Export Error" dialog, in addition to (always) being logged.
@DylanC
Copy link
Collaborator

DylanC commented Apr 4, 2018

@ferdnyc - This is very true, I agree.

@DylanC DylanC added the 💡 enhancement This issue describes an improvement, enhancement, or feature request for OpenShot label Apr 4, 2018
@DylanC
Copy link
Collaborator

DylanC commented Apr 4, 2018

@jonoomph - Would this be a useful change to make soon? (ish)

ferdnyc added a commit to ferdnyc/openshot-qt that referenced this issue Jul 23, 2018
This commit enables something I've been working towards for some
time now: The ability to configure OpenShot's console output and
logfile output to different logging levels, with potentially _more_
messages being logged to the logfile than are shown on the console.

As a result, it brings all of the following:
* Log messages of level INFO or higher are written to the console
  log
* By default, initially the same messages are written to the
  logfile as well
* The `debug-mode` preference now affects openshot-qt's own logging,
  as well as the libopenshot proxy logging. When `debug-mode` is
  switched on, the `openshot-qt.log` file will receive all messages
  of level DEBUG or higher.
* Log messages proxied from libopenshot are now logged at level
  DEBUG, instead of INFO, so that they will be written to the
  log file (only if `debug-mode` is on), but will not be printed
  to the console output.

This opens up the possibility of adding a second ZeroMQ logging
channel for messages at a _higher_ severity than debug, which
would always be active rather than being gated by the `debug-mode`
switch. That priority logging channel could be used for messages
which openshot should always log, such as error messages. This
would be a possible means of addressing OpenShot#1450.
ferdnyc added a commit to ferdnyc/openshot-qt that referenced this issue Jul 23, 2018
This commit enables something I've been working towards for some
time now: The ability to configure OpenShot's console output and
logfile output to different logging levels, with potentially _more_
messages being logged to the logfile than are shown on the console.

As a result, it brings all of the following:
* Log messages of level INFO or higher are written to the console
  log
* By default, initially the same messages are written to the
  logfile as well
* The `debug-mode` preference now affects openshot-qt's own logging,
  as well as the libopenshot proxy logging. When `debug-mode` is
  switched on, the `openshot-qt.log` file will receive all messages
  of level DEBUG or higher.
* Log messages proxied from libopenshot are now logged at level
  DEBUG, instead of INFO, so that they will be written to the
  log file (only if `debug-mode` is on), but will not be printed
  to the console output.

This opens up the possibility of adding a second ZeroMQ logging
channel for messages at a _higher_ severity than debug, which
would always be active rather than being gated by the `debug-mode`
switch. That priority logging channel could be used for messages
which openshot should always log, such as error messages. This
would be a possible means of addressing OpenShot#1450.
@stale
Copy link

stale bot commented Oct 27, 2020

Thank you so much for submitting an issue to help improve OpenShot Video Editor. We are sorry about this, but this particular issue has gone unnoticed for quite some time. To help keep the OpenShot GitHub Issue Tracker organized and focused, we must ensure that every issue is correctly labelled and triaged, to get the proper attention.
This issue will be closed, as it meets the following criteria: - No activity in the past 180 days - No one is assigned to this issue
We'd like to ask you to help us out and determine whether this issue should be reopened. - If this issue is reporting a bug, please can you attempt to reproduce on the latest daily build to help us to understand whether the bug still needs our attention. - If this issue is proposing a new feature, please can you verify whether the feature proposal is still relevant.
Thanks again for your help!

@stale stale bot added the stale This issue has not had any activity in 60 days :( label Oct 27, 2020
@stale stale bot closed this as completed Nov 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
💡 enhancement This issue describes an improvement, enhancement, or feature request for OpenShot stale This issue has not had any activity in 60 days :(
Projects
None yet
Development

No branches or pull requests

2 participants