AirPrint Support for Label Printers - Print Processing Issue Need to Reboot the Printer for Next Job Printing.

[sahayap]

Dear Michael,

I hope this message finds you well. We are currently in the process of developing AirPrint support for our label printers, and we have entered the testing phase. However, we have encountered a random issue during testing, specifically related to "print processing."

Here is a breakdown of our testing procedure:

1. We connect our printer to Mac OS via USB.
2. Multiple PDF test files (4x6 inch) are queued for printing.
3. We queue 10 jobs at a time and wait for all of them to be printed.
4. After completion, we send another set of 10 PDFs for printing.
5. At random intervals, the "print processing" issue occurs. Once this happens, the printer waits, and no other job is printed until we reboot the printer.

We have also noticed that when the printer is in an error state, the Mac's Print Dialog correctly displays the printer error status. However, despite the error status, the Mac continues to send the next job to the printer. To address this, we implemented a logic check during the printer status cycle. If the printer is in an error state, we inform the caller function of the current error status. In the subsequent printer status check cycle, if the printer is still in an error state, we wait until the printer status changes to "ready" before proceeding. This ensures that the Mac does not send the next job to the printer while it's still in an error state.

Upon examining the output of the 'ps' command from our printer's terminal, we noticed that there are multiple instances of our printer application running, which could be related to the "print processing" issue.

Additionally, we have attached the following information for your reference:

The 'ls' command output from our Printer spool directory.

The log file related to the print processing issue.

log-file-O.txt
log-file.txt

The Mac Print Dialogue and Web UI

We kindly request your expert guidance to help us identify the root cause of this issue and provide solutions to resolve it. We greatly appreciate your assistance.

Thank you for your time and support.

Best regards,
Sahaya Darcius P

[michaelrsweet]

Hard to provide any guidance - the multiple instances of the printer application are definitely a problem, but not one that would be caused by PAPPL...

[sahayap]

Dear Michael,

I hope you are doing well. Thank you.
We believe, we have to implement a Job Flow Control to fix this issue, We are currently in the process of implementing it.

However, a question has arisen that I believe you could help clarify.

When we send a job to our printer, we notice that five threads are initiated. Among these threads, four belong to the "bixolon-printer-app" instance, while the fifth one is associated with the "rastertoBxlLabel" CUPS legacy filter driver. These threads continue to run until the printing process is complete, at which point all five threads exit.

Could you please confirm whether this behavior is normal? If not, could you provide insights into what might be causing this issue?

For your reference, the software versions we are utilizing are as follows:

• libpappl-1.3.2
  

• libpappal-retrofit-1.0b2
  

• libppd-2.04b
  

• libcupsfilters-2.0b4
  

• cups-2.4.5
  

• openssl-1.1.1g
  

• mDNSResponder-1556.80.2
  

Your assistance and guidance on this matter would be greatly appreciated.

Thank you for your time and support.

With Regards,
Sahaya Darcius P

[michaelrsweet]

I don't have any direct involvement with the pappl-retrofit or libcupsfilters projects, so I have no idea whether this is normal. Honestly you are better off porting your filter to the PAPPL architecture directly as the emulation offered by these other projects is only meant as a stop-gap measure.

[sahayap]

Dear Michael,

I hope you are doing well. I wanted to extend my gratitude for your assistance.

Upon further investigation, it appears that the ongoing issue is closely tied to libcupsfilters2. During my analysis, I focused on the 'cfFilterChain' function within the 'filter.c' module. It came to light that this function initiates the creation of four child processes, which represent filter chains. These child processes are subsequently monitored using the 'wait' system call to assess their statuses.

The crux of the matter arises when multiple jobs are dispatched. In certain scenarios, a single filter process might encounter a failure. Consequently, the status of this particular child process isn't properly returned. This anomaly subsequently leads to a deadlock situation, where the remaining child processes also become suspended indefinitely.

In light of this, I have decided to escalate the matter by formally reporting this issue to the libcupsfilters2 team. Your unwavering support throughout this troubleshooting process has been invaluable, and I genuinely appreciate it.

Best Regards,
Sahaya Darcius P