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.

Sign up for GitHub

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

Jump to bottom

Bug: Octoprint displays wrong file size and estimates wrong ETL #1765

Closed
wschadow opened this issue Feb 10, 2017 · 18 comments
Closed

Bug: Octoprint displays wrong file size and estimates wrong ETL #1765

wschadow opened this issue Feb 10, 2017 · 18 comments
Labels
bug Issue describes a bug done Done but not yet released
Milestone
1.3.2

Comments

@wschadow
Copy link

Hi,

attached please find a screen shot of the issue. In the file list you can see that the file has 21.6 MB. In the print dialog it only shows 7.9MB and it printed 8.0MB (?!) of that file. The ETL was displayed wrong; it seems to have taken only 7.9MB into account for the calculation. It displayed a time until the 7.9MB were reached, now it's still "stabilizing", but at least it keeps printing :)

Cheers,
Wolfgang

bug
@GitIssueBot
Copy link

Hi @wschadow,

It looks like there is some information missing from your bug report that will be needed in order to solve the problem. Read the Contribution Guidelines which will provide you with a template to fill out here so that your bug report is ready to be investigated (I promise I'll go away then too!).

If you did not intend to report a bug but wanted to request a feature or brain storm about some kind of development, please take special note of the title format to use as described in the Contribution Guidelines.

Please do not abuse the bug tracker as a support forum - if you have a question or otherwise need some kind of help or support refer to the Mailinglist or the G+ Community instead of here.

Also make sure you are at the right place - this is the bug tracker of the official version of OctoPrint, not the Raspberry Pi image OctoPi nor any unbundled third party OctoPrint plugins or unofficial versions. Make sure too that you have read through the Frequently Asked Questions and searched the existing tickets for your problem - try multiple search terms please.

I'm marking this one now as needing some more information. Please understand that if you do not provide that information within the next two weeks (until 2017-02-24 22:30 UTC) I'll close this ticket so it doesn't clutter the bug tracker. This is nothing personal, so please just be considerate and help the maintainers solve this problem quickly by following the guidelines linked above. Remember, the less time the devs have to spend running after information on tickets, the more time they have to actually solve problems and add awesome new features. Thank you!

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being, so don't expect any replies from me :) Your ticket is read by humans too, I'm just not one of them.

@GitIssueBot GitIssueBot added the incomplete Issue template has not been fully filled out, no further processing until fixed label Feb 10, 2017
@wschadow
Copy link
Author

wschadow commented Feb 10, 2017 •
edited

bug

What were you doing?

printing a gcode

What did you expect to happen?

print the gcode, and diplay correct information

What happened instead?

wrong information displayed: n the file list you can see that the file has 21.6 MB. In the print dialog it only shows 7.9MB and it printed 8.0MB (?!) of that file. The ETL was displayed wrong; it seems to have taken only 7.9MB into account for the calculation. It displayed a time until the 7.9MB were reached, now it's still "stabilizing", but at least it keeps printing :)

Branch & Commit or Version of OctoPrint

Version: 1.3.1 (master branch

Printer model & used firmware incl. version

Prusa I3 MK2

Browser and Version of Browser, Operating System running Browser

Firefox, Win10

Link to octoprint.log

[On gist.github.com or pastebin.com. ALWAYS INCLUDE and never truncate.]

Link to contents of terminal tab or serial.log

[On gist.github.com or pastebin.com. If applicable, always include if unsure or
reporting communication issues. Never truncate.

serial.log is usually not written due to performance reasons and must be
enabled explicitly. Provide at the very least the FULL contents of your
terminal tab at the time of the bug occurrence, even if you do not have
a serial.log.]

Link to contents of Javascript console in the browser

[On gist.github.com or pastebin.com or alternatively a screenshot. If applicable -
always include if unsure or reporting UI issues.]

Screenshot(s) showing the problem:

[If applicable. Always include if unsure or reporting UI issues.]

I have read the FAQ.

@foosel
Copy link
Member

foosel commented Feb 10, 2017

Log files please, they are not optional. Provide all requested data. It's impossible to debug anything without that.

Also: did you by any chance do the upload of that file by watched folder?

In general OctoPrint takes the file size it displays there from the file system.

@wschadow
Copy link
Author

the print is not finished, could it that the content is buffered? I'll provide that, once the print is finished
octoprint.zip

@GitIssueBot GitIssueBot added triage This issue needs triage and removed incomplete Issue template has not been fully filled out, no further processing until fixed labels Feb 10, 2017
@foosel
Copy link
Member

foosel commented Feb 10, 2017

No, the content is not buffered but the file size is only read at the start of the print.

Again, how did you upload that file? Web interface, API (eg through Slic3r), watched folder?

@foosel
Copy link
Member

foosel commented Feb 10, 2017

Ah, log says watched folder. This is a duplicate of #1760 then :)

@foosel foosel closed this as completed Feb 10, 2017
@wschadow
Copy link
Author

wschadow commented Feb 10, 2017 via email

@wschadow
Copy link
Author

wschadow commented Feb 10, 2017 via email

@foosel
Copy link
Member

foosel commented Feb 10, 2017

Let me put it this way, something's up there with the watched folder with regards to files uploaded through it and their file size as reflected in the job data (which is read at a different point in time than the data in the file list). The original ticket ran into this issue when uploading a second version, you just proofed that the issue also manifests with a first version. But both problems are caused by the same piece of code (which I'll have to go through with a very fine toothed comb) and in all likelihood also the same core issue, the symptoms are just too similar for this to be two isolated issues.

@wschadow
Copy link
Author

wschadow commented Feb 10, 2017 via email

@foosel
Copy link
Member

foosel commented Feb 10, 2017

I hope so, if not (eg if I'm not able to reproduce it based on the information I now have) you might get a ping though from the other ticket to provide more details on your exact setup and workflow ;)

@wschadow
Copy link
Author

wschadow commented Feb 10, 2017 via email

@nophead
Copy link
Contributor

nophead commented Feb 11, 2017 via email

@foosel
Copy link
Member

foosel commented Feb 11, 2017

Files should only be moved from watched to uploads and only when that completes fully should the event be fired that refreshes the file list and also triggers any auto select or print functionality. But I could imagine that something is happening there that's either firing that too early or there is some form of buffering going on after all even though it shouldn't which allows the file to be selected for printing before it is fully written. The problem here is that since I never expected a file to still be written when it is being selected, I'm only reading the file size during initial selection and not during printing (which also has performance reasons - it costs cycles and it should usually not be necessary). So if the file grows after selection stuff gets out of whack.

I'll have to solve this by first figuring out what is different between the process in the handling of the watched folder and the regular upload (because something is different here or things like the above would happen all the time with regular upload too), but also making the file size tracking in the job handling more resilient against file size changes.

@wschadow
Copy link
Author

wschadow commented Feb 11, 2017 via email

@foosel
Copy link
Member

foosel commented Feb 11, 2017

The problem here isn't that the file was moved too early from the watched folder (or your print wouldn't have continued but stopped in the middle). The problem is rather the move from watched folder to regular file storage/uploads folder, or maybe even just the timing of the "oh, look, new file" signal during that move.

But I won't get around to look into this until next week, and guessing at possible causes without a close look at the code is pretty moot ;)

@wschadow
Copy link
Author

wschadow commented Feb 11, 2017 via email

@nophead
Copy link
Contributor

nophead commented Feb 11, 2017 via email

@foosel foosel mentioned this issue Feb 17, 2017
Closed
@foosel foosel added done Done but not yet released bug Issue describes a bug and removed triage This issue needs triage labels Mar 8, 2017
@foosel foosel added this to the 1.3.2 milestone Mar 8, 2017
@foosel foosel mentioned this issue Mar 8, 2017
Closed
@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 29, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
bug Issue describes a bug done Done but not yet released
Projects
None yet
Milestone
1.3.2
Development

No branches or pull requests
4 participants
@foosel @nophead @GitIssueBot @wschadow