Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
scanner is LIDE 120:003 xsane -v Gtk-Message: 19:26:13.185: Failed to load module "pk-gtk-module" xsane-0.999 © 1998-2013 Oliver Rauch This package is modified from the original version. Please contact your vendor or report problems at http://bugzilla.redhat.com E-mail: Oliver.Rauch balík xsane-0.999 kompilováno s GTK-2.24.33 with color management function bez podpory programu GIMP Výstupní formáty xsane: jpeg, pdf(compr.), png, pnm, ps(compr.), tiff, txt the scanned part is only part of original picture
Hi Tomas, thank you for reporting the issue! It would be great if you provided the steps how to and where to see the problem you reported. Thank you in advance! Zdenek
scanner starts from commandline: xsane since the last upgrade (xsane?), works the scaner (LIDE) wrong. from objects A4 (210mmx297mm) is scanned part about 200mm? x 160mm?. And this part is expanded to the A4 dimension. lower document's parts are lost. the difference on x axis is about cm? it looks like the same problem exists in quick scanner in fedora and after instalation xsane in mageia (in VirtualBox). I hope, that it will be good for you. Tomas
(In reply to tomas from comment #3) > scanner starts from commandline: xsane > > since the last upgrade (xsane?), Do you mean package upgrade (updating a packages to a newer version - package-1.0 -> package-2.0) or OS upgrade (F33->F34)? Are you able to bisect when the issue appeared? > works the scaner (LIDE) wrong. from objects > A4 (210mmx297mm) is scanned part about 200mm? x 160mm?. And this part is > expanded to the A4 dimension. lower document's parts are lost. the > difference on x axis is about cm? > Thanks for the information! IIUC the problem is A4 document isn't scanned as a whole, even if scanning region is set to A4? Did you confirm you have the paper which is going to be scanned on the proper place in scanner? It would be great if you attached the image you got from scanning and the original document (probably take a photo and attach it here as JPEG). To be honest, I didn't have an idea what you meant by the bug name you'd chosen. > > it looks like the same problem exists in quick scanner in fedora and after > instalation xsane in mageia (in VirtualBox). Ok, so the issue doesn't seem to be in xsane only, but probably in the software under it - SANE (sane-backends, sane-airscan). Would you mind getting logs from scanning process according steps here[1]? More information how to choose proper environment variables for debugging is here[2]. [1] https://fedoraproject.org/wiki/How_to_debug_printing_problems#Debugging_scanning_process [2] https://fedoraproject.org/wiki/How_to_debug_printing_problems#How_to_debug_scanning_issues
Created attachment 1795709 [details] debug_log
the first ocurence of this problem was in this jun ????
Thanks for the logs! However, I don't see any genesys related debug logs. Have you used SANE_DEBUG_GENESYS=255 variable? The manual mentions to turn on backend debugging. USB debug logs would be great too. If you haven't, it would be great if you used it and uploaded the updated logs. Can you attach the image you've got from scanning and original document too?
Created attachment 1795799 [details] debug_log /tmp/scan-0002 /tmp/scan-0003 /tmp/debug_log
I'm sorry. commandline is now SANE_DEBUG_DLL=255 SANE_DEBUG_HPAIO=255 SANE_DEBUG_SANEI_TCP=255 SANE_DEBUG_GENESYS=255 xsane &> debug_log I have no original document in electronic form, I send the top and the bottom scan.
(In reply to tomas from comment #9) > SANE_DEBUG_DLL=255 SANE_DEBUG_HPAIO=255 SANE_DEBUG_SANEI_TCP=255 > SANE_DEBUG_GENESYS=255 xsane &> debug_log > Would you mind providing the feedback regarding the documentation I sent? Because I'm curious how you chose those env variables - I thought the docs are clear, but you used 2 bad variables - SANE_DEBUG_HPAIO (your device isn't HP) and SANE_DEBUG_SANEI_TCP (your device is USB, this is env for network connections). Just remove SANE_DEBUG_HPAIO and substitute SANE_DEBUG_SANEI_TCP with SANE_DEBUG_SANEI_USB. On top of that - please attach the debug log with correct envs. You uploaded the scan as debug log. Thank you!
Created attachment 1795840 [details] debug_log usb /tmp/debug_log_usb
command is: SANE_DEBUG_DLL=255 SANE_DEBUG_SANEI_USB=255 SANE_DEBUG_GENESYS=255 xsane &> debug_log
the scanner's light line goes only to ~3/4 right range too. This range is dilationed to 297mm (A4) on result. I thing ??????? that in fedora 34 upgrade in this jun was packet for xsane or similary (drivers)? I have no Fedora 33 for tests..
(In reply to tomas from comment #11) > Created attachment 1795840 [details] > debug_log usb > > /tmp/debug_log_usb Contents of the file: ``` /tmp/debug_log_usb ``` It seems you just echoed the filename into the file. It would be great if you provided the requested logs from command in comment #12. (In reply to tomas from comment #9) > I have no original document in electronic form, I send the top and the > bottom scan. If you have a smartphone or digital camera, you can take a photo, connect the device to the PC and attach the photo here. It would be great if I had a comparison how much of the page is cropped. (In reply to tomas from comment #13) > I thing ??????? that in fedora 34 upgrade in this jun was packet for xsane > or similary (drivers)? The last sane-backends update was 3 months ago, xsane even older.... So something else could change. Or the HW itself can start malfunctioning, I saw such cases too. Once you get the logs, I'll go through them. If I see some obvious issue, I'll try to fix it, but otherwise I'll report it upstream. It seems like HW specific issue and maybe someone there will have the same HW as you.
now I inspecting scans and it looks like the scans from may 26 are OK and from jun 16 are wrong. May be HW problem, but all of rest funkcions seems OK. For me is impossible to check another scanner, special this type. I'll see. Thanks.
You forgot to provide the logs - setting the info back.
Created attachment 1796241 [details] debug_log_210630
There I see problem ( for me) with sending to big files (log file).
Ok, how big is the file? Does it help if you grep the file into three separate ones? You can divide the file based on logging source - one file for dll, second for genesys and third for usb. Otherwise your new file contains only filenames again.
Created attachment 1796276 [details] debugscan /home/tomas/Public/debug_log_usb /home/tomas/Public/scan_usb
Created attachment 1796278 [details] debug-usb
Created attachment 1796305 [details] debug_usb
Tips: 1) if you attach pdf file, name it with .pdf suffix and don't mark it as a patch - the other pdf you attached got recognized as a plain texted patch 2) if you attach a file, don't select 'paste text as an attachment' and then just paste the file name. I guess that's the cause of yours 'just a filename' attachments. If you choose 'paste text as an attachment' you need to copy whole contents of the file, not just path. I prefer using 'Enter the path to the file on your computer' and then clicking on 'Browse' - and select the file from your PC. 3) if you upload different attachments, set the appropriate name for describing the attachment. Uploading 'debug_log' and 'debug-log' doesn't make sense - if the latter obsoletes the former, use the 'Obsoletes' in 'Add attachment' dialog. Or using 'debug_log' name for pdf you get from scanning doesn't make a sense. 4) ad big files and dividing the logs I updated the wiki with recommendation about big log files[1] and how to divide logs if the issue appears only with high settings[2] Anyway, the bz2 contains the data, I'll look into it. [1] https://fedoraproject.org/wiki/How_to_debug_printing_problems#Before_you_start_debugging [2] https://fedoraproject.org/wiki/How_to_debug_printing_problems#How_to_divide_the_logs
Would you mind trying to debug scanning with low settings [1] and seeing if the issue is present? If it is, it would be great if you upload the new log file. The current is really long :( . I'm sorry for inconvenience :( . [1] https://fedoraproject.org/wiki/How_to_debug_printing_problems#Before_you_start_debugging
I try debug. there have I problem. I don't know, what are the lowest scanning step and Lineart mode. But I try to scan object with different resolutions, geometry was 0, 0, 210, 297 mm. All of the scans seems OK (75 bad quiality, 150 better,.....300) (1200,2400). Only resolution 600 is wrong. The scan in this resolution is wrong, is smaller (3/4 from scaned object) and in the gnome simple-scan this problem is too. Can I make a new scan for good small resulution when is this OK?
(In reply to tomas from comment #25) > I try debug. there have I problem. I don't know, what are the lowest > scanning step Step is the settings with the 'shoe' image and can have values -2, -1, +0, +1, +2 > and Lineart mode. It is a scan mode - like Gray or Color, so it is in the same settings as them. > But I try to scan object with different resolutions, geometry was 0, 0, 210, > 297 mm. All of the scans seems OK (75 bad quiality, 150 better,.....300) > (1200,2400). Only resolution 600 is wrong. The scan in this resolution is > wrong, is smaller (3/4 from scaned object) and in the gnome simple-scan > this problem is too. Ok, good to know - so it is connected to the resolution. I checked whether using 'scanimage' (CLI tool) produces smaller logs than xsane, and it does - would you mind trying the following command and checking the out.pnm in gimp, if the issue is present? $ SANE_DEBUG_DLL=255 SANE_DEBUG_GENESYS=255 SANE_DEBUG_SANEI_USB=255 scanimage -d 'genesys:libusb:003:004' --format=pnm --mode Lineart --resolution 600 > out.pnm 2> pnm_debug If the issue manifests in out.pnm, please upload pnm_debug as an attachment. > Can I make a new scan for good small resulution when is > this OK? I'm not sure what you mean.
Created attachment 1797070 [details] product of scan 300/600/900
Thank you for the comparison! Please upload the log file from the command: $ SANE_DEBUG_DLL=255 SANE_DEBUG_GENESYS=255 SANE_DEBUG_SANEI_USB=255 scanimage -d 'genesys:libusb:003:004' --format=pnm --mode Lineart --resolution 600 > out.pnm 2> pnm_debug if it reproduces issue. Thanks!
device `genesys:libusb:003:003' is a Canon LiDE 120 flatbed scanner I had to change to SANE_DEBUG_DLL=255 SANE_DEBUG_GENESYS=255 SANE_DEBUG_SANEI_USB=255 scanimage -d 'genesys:libusb:003:003' --format=pnm --mode Lineart --resolution 600 > out.pnm 2> pnm_debug -rw-rw-r--. 1 tomas tomas 0 2. čec 11.16 out.pnm -rw-rw-r--. 1 tomas tomas 324187 2. čec 11.16 pnm_debug I'll send it as attachment.
Created attachment 1797097 [details] pnm debug
Hmm... I was able to try our office scanner supported by genesys backend (but it has a different device type - gl843, and your Canon Pixma has gl124) and I ran 'scanimage' with '--resolution 600'. Then I saw in logs a default settings first: [12:52:06.647983] [genesys] Genesys_Settings{ xres: 100 yres: 100 lines: 1240 pixels per line (actual): 856 pixels per line (requested): 856 depth: 8 tl_x: 0 tl_y: 0 scan_mode: GRAY } , then xres+yres switch to 600: [12:52:07.007958] [genesys] Genesys_Settings{ xres: 600 yres: 600 lines: 7440 pixels per line (actual): 5144 pixels per line (requested): 5144 depth: 8 tl_x: 0 tl_y: 0 scan_mode: GRAY } So IIUC xres and yres is a resolution set by command line. Then if I open your current log, I see only: [11:16:25.044072] [genesys] calculate_scan_session [11:16:25.044116] [genesys] Genesys_Settings{ xres: 75 yres: 75 lines: 885 pixels per line (actual): 636 pixels per line (requested): 636 depth: 8 tl_x: 0 tl_y: 0 scan_mode: GRAY } It seems like '--resolution 600' wasn't applied in your case and only resolution 75 (which seems to be a default res for your device) is used. Would you mind setting verbose mode for scanimage itself by adding '-vvv' to the original command? The new command will look: $ SANE_DEBUG_DLL=255 SANE_DEBUG_GENESYS=255 SANE_DEBUG_SANEI_USB=255 scanimage -vvv -d 'genesys:libusb:003:003' --format=pnm --mode Lineart --resolution 600 > out.pnm 2> pnm_debug and it would be great if you provided available settings of your device - you can get them by: $ scanimage -h -d 'genesys:libusb:003:003' > settings.txt Please attach 'pnm_debug' and 'settings.txt' file as attachments. Thank you in advance!
Created attachment 1800817 [details] settings
Created attachment 1800818 [details] pnm_debug there are files pnm_debug and settings.txt commands were SANE_DEBUG_DLL=255 SANE_DEBUG_GENESYS=255 SANE_DEBUG_SANEI_USB=255 scanimage -vvv -d 'genesys:libusb:003:003' --format=pnm --mode Lineart --resolution 600 > out.pnm 2> pnm_debug scanimage -h -d 'genesys:libusb:003:003' > settings.txt
I test settings for xsane (I mean, that is in simple scan the same) for 210 x 297 mm the data are from the xsane screen. resoluton dimension of pictures 75 620 * 876 * 8 (530.4 kB) 100 824 * 1169 * 8 (940.7 kB) 150 1240 * 1753 * 8 (2.1 MB) 300 2480 * 3507 * 8 (8.3 MB) 600 4960 * 7015 * 8 (33.2 MB) 1200 9920 * 14031 * 8 (132.7 MB) 2400 19840 * 28062 * 8 (9531 MB) 4800 39680 * 56128 * 8 (2123.4 MB) too big? all of them without 600 wok OK.
Aha, your device doesn't support Lineart at all according settings.txt and scanning itself didn't happened at all... Please run: $ SANE_DEBUG_DLL=255 SANE_DEBUG_GENESYS=255 SANE_DEBUG_SANEI_USB=255 scanimage -vvv -d 'genesys:libusb:003:003' --format=pnm --mode Gray --resolution 600 > out.pnm 2> pnm_debug , verify if out.pnm shows the problem and if it does, do attach pnm_debug. I'm sorry for inconvenience, I expected Lineart is somehow default mode which is available on all devices...
file out.pnm is the first time with length <> 0 (?) The scan picture's failure can be see on them. The files are too long for attach. I don't know, how to send them. -rw-rw-r--. 1 tomas tomas 36138637 13. čec 18.10 out.pnm -rw-rw-r--. 1 tomas tomas 228187324 13. čec 18.10 pnm_debug -rw-rw-r--. 1 tomas tomas 75413334 13. čec 18.19 pnm.tar.gz can you help me?
(In reply to tomas from comment #36) > file out.pnm is the first time with length <> 0 (?) The scan picture's > failure can be see on them. The files are too long for attach. I don't know, > how to send them. > > -rw-rw-r--. 1 tomas tomas 36138637 13. čec 18.10 out.pnm > -rw-rw-r--. 1 tomas tomas 228187324 13. čec 18.10 pnm_debug > -rw-rw-r--. 1 tomas tomas 75413334 13. čec 18.19 pnm.tar.gz > > can you help me? Pre-advice - 'ls' has '-h' parameter which converts file sizes in bytes into higher units (KB, MB etc...), it gives you easier understanding of the file size. Then: 1) you don't need to attach out.pnm - just check if the issue is present (open it in f.e. gimp) and tell me 2) you can do the steps which I mentioned in comment #23 - see the link[1] - you can divide the logs by grepping the names in lower case and redirect grep output to a new files. 3) if the grepped files are still too big, you can use compression to .xz - it seems to compress the data more than .gz or .bz2 The command is: $ tar -cJvf logs.tar.xz <files> [1] https://fedoraproject.org/wiki/How_to_debug_printing_problems#How_to_divide_the_logs
Created attachment 1801575 [details] the first part of the debug files
Created attachment 1801577 [details] the second part of the debug file
it look like the file was too long for all metods. I had to make part1 and part two. file pnm.out is OK, but the picture isn'l all, is still without the bottom part.
(In reply to tomas from comment #40) > it look like the file was too long for all metods. I had to make part1 and > part two. Ok, thanks - actually grepping would not work, because genesys seems to long multiline logs... Hmm... actually the resulted image doesn't look cropped because the scanning area was small, but the image itself looks zoomed in. And if I look into the used scan area: [18:09:25.749681] [genesys] calculate_scan_session [18:09:25.749719] [genesys] Genesys_Settings{ xres: 600 yres: 600 lines: 7086 pixels per line (actual): 5100 pixels per line (requested): 5100 depth: 8 tl_x: 0 tl_y: 0 scan_mode: GRAY } A4 has size 4960 x 7015, so the image should fit just fine. The scanner starts to work in 600dpi, but it switches to 75dpi before end of scanning (however, my HP scanner supported by genesys backend behaves the same, but the image is complete). I passed the logs and findings upstream, maybe someone will have the device or know where to look better than me.
Reported upstream https://gitlab.com/sane-project/backends/-/issues/489
Hi Tomas, upstream told me that it can be a duplicate of issue, which has a proposed fix waiting among merge requests on their gitlab. I took the patch, applied it on our sources and built a testing rpms. Would you mind testing the new rpms if it fixes your issue? Here is the link https://koji.fedoraproject.org/koji/taskinfo?taskID=72235169 .
I try to install sudo dnf install sane-backends-1.0.32-4.fc34.testing.x86_64.rpm for it I had to change (install) sudo dnf install sane-backends-libs-1.0.32-4.fc34.testing.x86_64.rpm but now scan not working. it say "nejsou k dispozici zadna zarizeni". sudo dnf upgrade Poslední kontrola metadat: před 0:35:02, Út 20. července 2021, 13:06:28. Závislosti vyřešeny. Není co dělat. Hotovo! is looks OK and packages are: rpm -qa |grep sane xsane-common-0.999-40.fc34.x86_64 libsane-airscan-0.99.26-1.fc34.x86_64 sane-airscan-0.99.26-1.fc34.x86_64 xsane-0.999-40.fc34.x86_64 sane-backends-libs-1.0.32-4.fc34.testing.x86_64 sane-backends-1.0.32-4.fc34.testing.x86_64 should be chaned another packages?
Aha, sorry - please install sane-backends-drivers-scanners and sane-backends-drivers-cameras from the build too. Those packages contain libraries which defines scanner backends, so the fix lies there.
for all scans (75,150,200,300,600,1200,2400) sizes look OK. thank's.
FEDORA-2021-e24aa26a65 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-e24aa26a65
FEDORA-2021-f15615557e has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-f15615557e
FEDORA-2021-f15615557e has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-f15615557e` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-f15615557e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-e24aa26a65 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-e24aa26a65` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-e24aa26a65 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-e24aa26a65 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-f15615557e has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.