cups-browsed 1.24.0 does not create local queues for remote cups queues (cups-1.4.2)

[zdohnal]

Hi!

I tested the newest release - 1.24.0 - in our company environment, where print server is served by cups-1.4.2, and local queues are not created anymore. Here are the logs
cups-browsed-log.txt .
From logs - it seems some of remote queues did not pass get-printer-attributes request at cups-browsed.c:6793 , thougn the last cups error is 'Success':

Jun 04 03:29:31 host-client-ip cups-browsed[2420]: Tue Jun 4 03:29:31 2019 Request for IPP attributes (get-printer-attributes) for printer with URI ipp://server_hostname:631/printers/brno4-tpbc-0th-north failed: Success
Jun 04 03:29:31 host-client-ip cups-browsed[2420]: Tue Jun 4 03:29:31 2019 get-printer-attributes IPP call failed on printer brno4-tpbc-0th-north (ipp://server_hostname:631/printers/brno4-tpbc-0th-north).

But what is interesting, some remote print queues passed that (or missed that request) and tried to load PPD, but with no luck:

Jun 04 03:29:33 host-client-ip cups-browsed[2420]: Tue Jun 4 03:29:33 2019 Failed reading file /var/cache/cups/cups-browsed-options-brno1-0th-cafe, probably no options recorded yet
Jun 04 03:29:33 host-client-ip cups-browsed[2420]: Tue Jun 4 03:29:33 2019 Print queue brno1-0th-cafe is for remote CUPS queue(s) and we get notifications from CUPS, using implicit class device URI implicitclass://brno1-0th-cafe/
Jun 04 03:29:33 host-client-ip cups-browsed[2420]: Tue Jun 4 03:29:33 2019 Unable to create PPD file: No such file or directory

IMO This two errors are connected - errno is not cleared after load_printer_options(), which ends with error, sets errno and it is again checked after ppdCreateFromIPP2() without clearing errno -> fails.
But the same print queue goes to record_printer_options() and produces following error:

Jun 04 03:29:33 host-client-ip cups-browsed[2420]: Tue Jun 4 03:29:33 2019 Unable to get PPD file for brno1-0th-cafe: The printer or class does not exist.
Jun 04 03:29:33 host-client-ip cups-browsed[2420]: Tue Jun 4 03:29:33 2019 lpstat: No destinations added.
Jun 04 03:29:33 host-client-ip cups-browsed[2420]: Tue Jun 4 03:29:33 2019 Unable to load PPD from local queue brno1-0th-cafe, queue seems to be raw.
Jun 04 03:29:33 host-client-ip cups-browsed[2420]: Tue Jun 4 03:29:33 2019 Queue has still jobs or CUPS error!
Jun 04 03:29:33 host-client-ip cups-browsed[2420]: Tue Jun 4 03:29:33 2019 ERROR: Failed disabling printer 'brno1-0th-cafe': The printer or class does not exist.

[tillkamppeter]

@deepak0405 can you have a look into this? Thanks.

[deepak0405]

I am trying to reproduce the errors.

1. What is the Make Model of remote cups queue brno4-tpbc-0th-north?
2. Can you please also send the output and return status of

ipptool -tv <URI> get-printer-attributes-2.0.test

https://github.com/steveathon/cups/blob/master/test/get-printer-attributes-2.0.test

[zdohnal]

@deepak0405

1. Canon imageRunner C5185i Foomatic/Postscript , but it based on used PPD. In reality it is Canon imageRUNNER ADVANCE C3530i MFP
2. ipptool -tv ipp://server_hostname:631/printers/brno4-tpbc-0th-north get-printer-attributes-2.0.test
   ipptool_output.txt

The uri is uri of print queue on server, uri to device itself is different (socket://printer_ip:9100) - and client machine, server and printer are all in different subnets.

[tillkamppeter]

@zdohnal, the CUPS server server_hostname is not answering the standard get-printer-attributes IPP request, according to your ipptool_output.txt. As CUPS is supposed to fully conform to IPP 2.x this is not expected.
Most probably this is either a bug in CUPS or the server runs a stone-old CUPS version which only does IPP 1.x.
Could you tell which CUPS version your server server_hostname is running? Could you also attach its cupsd.conf and cups-files.conf to this bug report?
If you do not see any hint of a possible mis-configuration (not ver probable as both printing and the get-printer-attributes request go through IPP) please consider reporting a bug on CUPS upstream.

[zdohnal]

@tillkamppeter Ad cups version - please see issue subject, I explicitly defined version there - and yes, because it is old CUPS, it runs only IPP 1.x.
Ad conf files - they are under jurisdiction of our IT team, so I do not have free access to them. But I asked them to send them to me.

[tillkamppeter]

@deepak0405, perhaps we should re-introduce the old clustering method for legacy server support. Not having this especially defeats the support for legacy CUPS browsing (as a client).
First, we need to find out with which version CUPS started to have IPP 2.x support (with supplying full capability info when getting a get-printer-attributes IPP request). If the first DNS-SD-enabled version already supports this (what I assume), we can continue treating all DNS-SD-discovered remote printers as we are treating them now and would treat printers discovered via CUPS (<= 1.5.x) legacy broadcast the old way, either with a raw client queue (no clustering possible) or with the download-server-PPD-and-modify-to-non-filtering-locally method (restricted clustering possible).
For integrating this legacy support in the current cups-browsed we need to take into account:

• Clustering of a legacy printer with downloaded server PPD with a modern network printer/CUPS queue with get-printer-attributes response would require a function which converts a PPD file into a get-printer-attributes response data structure.
• If creating a PPD->get-printer-attributes converter function is too complicated we must somehow manage to not be able to cluster modern with legacy. By default we should simply refuse to cluster modern with legacy, so a cluster started with a legacy printer should only accept further legacy printers and a cluster started with modern printers should only add further modern printers.
• We could add one or more directives to cups-browsed.conf to select the behavior:
  • ClusterModern, ClusterLegacy: as Cluster but using the modern or legacy clustering method, independent of how the printers get discovered, Cluster-modern would reject legacy printers. This overrides the default behavior for clustering.
  • ClusterMethod sets the default clustering method. Default is Auto where the first printer determines which method to use, Modern uses the modern clustering and ignores/rejects legacy printers added to a cluster or a cluster formed from an already set up legacy printer, Legacy creates legacy clusters even if the first printers discovered are modern ones (so that legacy printers can get added later). Manual clusters with ClusterModern or ClusterLegacy override this default setting.

WDYT? How should we implement the legacy printer (IPP 1.x + CUPS browsing) support?

[tillkamppeter]

@zdohnal, as your servers have such an old CUPS (1.4.x), are you using cups-browsed's feature to create local queues based on legacy CUPS browsing (the feature Tim Waugh had added near the beginning of cups-browsed development in 2013)?
Do you only access single printers with each loacl queue or do you want to create clusters?

[zdohnal]

@tillkamppeter ad first question - AFAIK yes, cups-browsed is set to find remote shared printers by dnssd protocol and CUPS legacy protocol.
Ad second question - ideally both. I'm okay with accessing single printers with each local queue for my usual workflow, but IMO there will be requests for clustering feature too .
e.g. our customers wanted clustering features in RHEL 7, so I am doing a rebase of cups-browsed to 1.13.4 without some other features, so there is quite high possibility they will rather want the feature than changing their infrastructure (buying IPP 2.x printers etc...)

[zdohnal]

Footnote:
There was a change in creating local queues from CUPS legacy broadcast since 1.14.0 - created queues started to get implicitclass backend, even when only one server (AFAIK) is broadcasting the queue - I thought it was simple change of behavior, but I'm not sure now - is it not a bug in the end?

[deepak0405]

@tillkamppeter
The DNS-SD support was introduced in cups1.2 and the IPP 2.x support was added in cups 1.4.

I think the method suggested by Till is the best way to solve the issue.

The new Clustering code does IPP requests three times:

1. While getting the attributes of the printer for generating the ppd file.

2. Getting the number of jobs on the server, while we are distributing the new job on the cluster.

3. Sending the job to the printer using IPP backend.

Will we be able to do the last two mentioned IPP request for the legacy printer ?

Implementing a function to get printer attributes from ppd will be a difficult task. We will have to parse the ppd file and after parsing we may have to convert the ppd data into different form

for eg.
The pagesize Letter in ppd file will be written something like
{
media-size = {x-dim = ...., y-dim = ....} ,
media-type = ....,
}

There is a function to convert the second format to the first one, but I am not aware of a function for the reverse work. We can do one of these two things here:

1. Write functions to convert the ppd options to IPP options.

2. If a legacy printer is in the cluster :
   a. Add function to ppdgenerator.c which reads the ppd file of the legacy printer and copies its options to the cluster ppd. In this way we don't have to convert the option.
   b. While selecting the printer, we need to write a different function to see whether the legacy printer supports the requested options. For modern printer we will match the job settings with the p->prattrs, and for legacy we will read the ppd file and see if the option is supported or not.

IMO, the second one will be easier.

[tillkamppeter]

@zdohnal, the implicitclass backend is needed for clustering and it is easier to handle when a single printer also uses implicitclass instead of changing when a second printer gets added or all but one printers of a cluster disappear. See also the NEWS file, changes for version 1.11.3.

[tillkamppeter]

@deepak0405, CUPS started with DNS-SD printer advertising only in 1.3.x but it does not change anything for us here as @zdohnal has CUPS 1.4.x on his servers. But having CUPS 1.4.x already doing IPP 2.x but not answering a get-printer-attributes IPP request properly looks like a bug in this old CUPS for me. @deepak0405 could you have a look into the IPP specs whether the IPP 2.0.x/2.1.x conformance is enough for the get-printer-attributes IPP response we expect?
I think polling number of jobs and sending off jobs via IPP should already work with old CUPS versions, these basic operations should already be available in IPP 1.x.
For the legacy printer integration in a cluster the function which turns a PPD into IPP attributes would be the most elegant and consistent solution, but we would need to use deprecated PPD functions of the CUPS library to not duplicate/re-invent code and as soon as CUPS removes them move them over into libcupsfilters. Can be a lot of code to maintain only to support legacy servers. But this method will also keep working when CUPS stops using PPDs for creating print queues and we then, too. So the local CUPS can be one which does not use PPDs any more and the server can use a stone-old CUPS which still does not answer get-printer-attributes requests properly.
Adding the options of a downloaded PPD from a legacy printer to the joint PPD of all modern printers in the cluster also has its quirks, as we need to find out whether the differently-named options/choices have the same meaning and also keep track of the original PPD to send the correct option settings when the legacy printer gets selected for a job. We also need to take into account when there is more than one legacy printer to add to the joint PPD or if there are only legacy printers and the joint PPD of the modern printers is therefore empty. Also this will stop working if CUPS removes PPD support as then we also do not create a PPD any more. With this method the selection of the destination printer can also get arbitrarily complicated as we have to convert the job's attributes into PPD options to see whether they match the legacy printers.
So for me it seems to be easier and more future proof to convert the downloaded PPDs into IPP attributes and then do all the rest as with a modern printer. Most straightforward.
The decision whether to proceed the standard way of a modern printer or to download the PPD we make based on the answer we get on a get-printer-attributes request. If it is usable we do the modern method, if not we try to download the PPD and only if this does not work we discard the printer as not supported.
WDYT?

[deepak0405]

@tillkamppeter
The GET_PRINTER_ATTRIBUTES request is also supported by IPP/1.1. I checked in IPP/1.1 specification and the IPP request format was the same as we are doing. But the attributes lists in IPP/1.1 or IPP/2.x doesn't have reference to media-col-database. One file related to IPP mentions media-col-database.
Whether the error can be because of requesting media-col-database?

@zdohnal
Can you please send the output of this test file ?

[tillkamppeter]

@deepak0405, perhaps we need to work with a fallback. First, we do, as before, our get-printer-attributes request with "all" and "media-col-database", if we get a failure or broken data, we get into the fallback, which is the same get-printer-attributes request but only with "all" and no "media-col-database". This can even in addition to support for old printers/CUPS queues solve the Canon printer problem of issue #22 (or apple/cups#5512).

[zdohnal]

Hi @deepak0405 !
here are the logs
ipptool_output_without_mediacoldatabase.txt

[tillkamppeter]

Thanks, @zdohnal, this looks like that the fallback as I described in my previous comment would work with this output, as the output lists the available paper sizes ("media-supported") and input PDLs ("document-format-supported") which is the minimum information for generating a valid PPD file, but it has also some point where it is not consistent, as under "job-settable-attributes-supported" the attributes "print-quality" and "printer-resolution" are listed and there are no "print-quality-supported" and "printer-resolution-supported" entries telling about valid choices. This is possibly a bug in the CUPS running on the server.

[zdohnal]

@tillkamppeter I checked clean CUPS 1.4.2 which Mike provided at that time and current upstream master - actually those two missing attrs were only in requested attributes field at that time and they were missing from load_ppd() function, where they are handled now in current upstream. So they are missing in the request because server did not take them from ppd file and was not meant to do it at that time...
Is their absence critical? Because IMO it is 'new feature' (in comparison of RHEL6 and cups-1.4.2) and we are cautious about not-breaking things in older RHEL, so I will need some good justification to get permission to fix it. (there is an initiative to upgrade print servers in the future, but I'm not sure about ETA...)

[tillkamppeter]

@zdohnal, the missing "print-quality-supported" and "printer-resolution-supported" (or generally missing "...-supported" if "..." is listed in "job-settable-attributes-supported") I consider a bug and not a feature addition as it breaks IPP standard compliance, so being legitimate to fix this in an already released distribution, but it is not a security bug or otherwise very severe. You could ask your release team whether they would accept the backport of the fix to this bug as it improves user experience a lot when modern clients (new OS versions, mobile devices) access printers on RHEL servers.
@deepak0405, indepenndent of above-mentioned bug i would recommend you to first implement as the very first approach a two-step poll for get-printer-attributes. First you do the "standard" way with attributes "all" and "media-col-database". If the result is unusable in any form you do the fallback of only using the "all" attribute. This should get you a usable but perhaps poor result. Implement this and let @zdohnal test. After having @zdohnal's answer we can still decide whether we need a PPD importer for legacy CUPS queue support or not.

[deepak0405]

@zdohnal
I have generated a pull request #128. If an IPP request to obtain "media-col-database" and "all" fails, we do a fallback request, asking only "all" group name attributes.
Can you please test it ?

[zdohnal]

@deepak0405 Sure thing, I'll test it right away. Thank you for the patch!

[zdohnal]

@deepak0405 I cherry-picked your two commits, applied on 1.24.0 and tried it in Fedora rawhide. Unfortunately, there are no local queues. I'll send the logs on Monday.

[tillkamppeter]

@zdohnal, thank you very much. I have already found a bug in the patch which renders the fallback completely non-functional. Please see my comment on the pull request. You could try again with this bug corrected.

[zdohnal]

@tillkamppeter now I see - the fallback is very good idea, but it is unfortunate it is not set to 1 in any call of get_printer_attributes() :)

[tillkamppeter]

@zdohnal, in calls outside of get_printer_attributes() outside get_printer_attributes() itself the fallback mode is always set to 0 so that get_printer_attributes() does the standard ("all" + "media-col-database") first. If this fails, get_printer_attributes() calls itself with 1 as fallback mode, so that then the attempt with only "all" is initiated.
Did you test it? Did you apply the small correction of my comment in the pull request?

[zdohnal]

I'm sorry, I have not tested it yet - just arrived into the office. I'll post an update around the noon.

[zdohnal]

@tillkamppeter Actually I do not see any comment on pull request, so I looked into the code and IMO there is the other issue - when you call get_printer_attributes(uri, 1), you do not store the return value, so the output of get_printer_attributes is still NULL from previous call.
I tried to fix it, but messed up something else, so the queues are not created too.

[tillkamppeter]

@zdohnal, take deepak's repo on which he has created this pull request. There edit line 6659 in the file utils/cups-browsed.c by replacing

get_printer_attributes(uri,1);

with

response = get_printer_attributes(uri,1);

Now use the freshly built cups-browsed, either by terminating any other cups-browsed instance and then running ./cups-browsed in the source tree of cups-filters or replacing the system's cups-browsed with .libs/cups-browsed from the source tree.
If you have made sure that you are running the new, fixed cups-browsed and still do not get client queues, switch cups-browsed into debug mode and provide us /var/log/cups/cups-browsed_log.

[deepak0405]

@zdohnal Please also upload the ppd file, if it is generated.

[zdohnal]

I'm sorry, tried pure deepak's version, but still no created queues - here is the log
cups-browsed_log.txt and there are no ppds in /etc/cups/ppd.

[tillkamppeter]

@zdohnal, could you do the get-ipp-attributes requests with only the "all" attribute using ipptool (copy file /usr/share/cups/ipptool/get-printer-attributes-2.0.test, remove "media-col-database" from the attributes and use this with ipptool). Do it preferably on all your remote printers, from the client on which you have the problem with cups-browsed. Attach the results here together with the printer's URIs.

Especially I need the results for
ipp://server_name:631/printers/brno1-4th-cafe
ipp://server_name:631/printers/brno2-1st-hc-mazlik

[tillkamppeter]

It seems that CUPS 1.4.2 on your VM is generally not accessible for a remote machine. Have you checked cupsd.conf on your VM whether all settings are correct?

[tillkamppeter]

@deepak0405, also note that I am assuming that your VM's host name is "ubuntu", following your examples. If it is not the case or needs something extra, like "ubuntu.local", please substitute the "ubuntu" in my examples for whatever is correct as a host name or IP for your VM.

[deepak0405]

On my vm I am running cups in a different directory, i.e. I used ./configure --prefix=/<some-path> to build the cups. Can that be the reason ?

[deepak0405]

With ip-address, one of the command works

deepak@deepak-Lenovo-G50-80:/etc/cups$ lpstat -h 192.168.2xx.1xx:631 -v
device for test2: ///dev/null
device for works: ipp://localhost:631/ipp/resource?version=1.1

but this one doesn't

deepak@deepak-Lenovo-G50-80:/etc/cups$ lpoptions -h 192.168.2xx.1xx:631 -p test2 -l
lpoptions: Unable to get PPD file for test2: Name or service not known

[tillkamppeter]

Installing into an alternative directory on the VM is no problem as long as you do not have the original CUPS running in parallel.
The lpstat command with IP shows that CUPS is principally accessible on the server, but perhaps you did not use the correct host name when accessing with a host-name-based URI.
That the lpoptions command with IP does not work is strange. Perhaps you should have a look into the source code of lpstat and lpoptions (of the CUPS version running on your client) and also have a look into the CUPS error_log on your VM.

[tillkamppeter]

The error message of lpoptions is caused by this code piece in the list_options() function:

  if ((http = cupsConnectDest(dest, CUPS_DEST_FLAGS_NONE, 30000, NULL, resource,
 sizeof(resource), NULL, NULL)) == NULL)
  {
    _cupsLangPrintf(stderr, _("lpoptions: Unable to get PPD file for %s: %s"),
                    dest->name, cupsLastErrorString());
    return;
  }

  if ((filename = cupsGetPPD2(http, dest->name)) == NULL)
  {
    httpClose(http);

    _cupsLangPrintf(stderr, _("lpoptions: Unable to get PPD file for %s: %s"),
                    dest->name, cupsLastErrorString());
    return;
  }

Unfortunately, both steps have the same error message if they fail, so only modifying this piece of code (on the client) can tell you where it exactly fails. But for me it looks like that it is the second one, because the lpstat works and lpstat probably has the same first but a different second step. My guess here is that lpstat speaks IPP after creating the HTTP connection while lpoptions downloads the PPD, using HTTP.

[deepak0405]

I am able to do get-printer-attributes request using the IP address of the vm, so I just changed the name ubuntu with the ip in my cups-browsed.c and finally I was able to reproduce the error.

The backend/ipp.c handles the IPP request nicely, it also does fallback request

       else if ((ipp_status == IPP_STATUS_ERROR_BAD_REQUEST ||
              ipp_status == IPP_STATUS_ERROR_VERSION_NOT_SUPPORTED) && version > 10)
       // IPP2.0 not working trying IPP 1.1

In case of @logTom, we are getting the error IPP_STATUS_ERROR_VERSION_NOT_SUPPORTED and thus we are doing a fallback IPP1.1 request, while in case of @zdohnal, the ipp_status is null( but it should not be) and no data is returned by the printer. But if we do a request without media-col-database, the printer returns the required info. @zdohnal Please try this dummy branch, for my case I was able to create a cups queue with sufficient printer info.

@zdohnal I am not quite sure whether the printing will work after it, as it is not working for @logTom, but I think this PR should be able to generate ppd files and job should also be sent.

@tillkamppeter If this branch works, we can follow this strategy :
If the request return ipp_status one of the two shown above, we will do a IPP1.1 request.
If the get-attributes-call is not having sufficient attributes( like which happens in @zdohnal's case), we do a fallback request without "media-col-database".

@tillkamppeter @zdohnal I don't think there is need to revert back to previous code of downloading a ppd file for legacy printer, as in case of @zdohnal and @logTom, we get sufficient output for get-printer-attributes request.

[tillkamppeter]

@deepak0405, OK, let us go this way.

[zdohnal]

@deepak0405 The print queues are now visible. Thank you, Deepak!

Although it takes about 20-30s to 1st print queue to show up now.

Regarding printing, the job ends with error:

implicitclass://BRQ-TPBC-1D124-North/: Unable to create job - No such file or directory. Retrying.

[deepak0405]

Sorry for the late response, I was not well the last week.

I tried reproducing the error, but the printing is working for my setup. Can you please attach the error logs ?

[zdohnal]

@deepak0405 No problem, Deepak. I hope you feel better.

Here are logs for the job
cupsd_job_log.txt . Actually previous error was caused by old implicitclass backend. Now logs are saying the printing is okay, but only paper which got out of printer is on the photo

[paulmenzel]

This issues has become too long. @zdohnal, can you please create a new one, and reference it here?

[deepak0405]

@tillkamppeter This PR #173 contains the complete implementation of the fallback logic. I hope after this PR, we can close this issue, since queues will be generated for all the cases. But the issue for printing will still remain open, and I am currently working on it.

@zdohnal @logTom Can you please verify this PR ? Also Can you please attach the cups_error log and cups-browsed logs. It will help in debugging the printing issue.

[thomaspeissl]

@deepak0405 Yeah, I tested it. But, in my case the queues seem to be fixed already before the pr. Printing still doesn't work. I guess you only need the logs if it still doesn't work for zdohnal.

[tillkamppeter]

@logTom, as printing does not work for you and this PR is about making printing work, we need also your logs. Can you please attach them? Both the CUPS error_log and the cups-browsed_log?

[zdohnal]

@deepak0405 Ok, I'll test it on clean cups-filters without your dummy branch.

I hope I'll manage it today, but tomorrow is more possible.

[zdohnal]

@deepak0405 Ok, I can see the first print queue now after 1m 20s - cups-browsed 1.22.5 was able to found and create the first queue in 3s.

The printing still does not work, as you expected.

[deepak0405]

@zdohnal 1m is too much time, let me see why its taking this much. For your case we will be doing the request thrice

1. First time a IPP 2.0 request.
2. Next time a IPP1.1 request.
3. If both doesn't give good result we do a request without media-col-database.

I was expecting some delay, but not this much. Can you please attach the cups_browsed-error-log.

[tillkamppeter]

@zdohnal, please also attach the cups-browsed_log.

[zdohnal]

@tillkamppeter @deepak0405 Here you are
cups-browsed_log.txt

[zdohnal]

Note: I stopped the service after the first queue came up, so the log should be more relevant than log of whole process.

[tillkamppeter]

I have fixed several bugs in cups-filters now. Could you try the newest GIT snapshot? Note that there is no workaround for a Poppler segfault on the server (as you mention in issue #163).

[tillkamppeter]

To solve issue #181 I have done several fixes and improvements on the implicitclass backend. Please re-test to see whether this also solves this bug.

[tillkamppeter]

@logTom, @zdohnal, I have now restructured the get_printer_attributes() function of cups-browsed and moved it into libcupsfilters, to share it with the driverless utility (commit 20c4773).
This could perhaps also fix this issue, please test (if the cause of this issue is not a segfaulting Poppler on the server).

[zdohnal]

@tillkamppeter I'm able to print with cups-filters-1.26.0 after fixing poppler. When I set:

BrowsePoll <el6_print_server>
UpdateCUPSQueuesMaxPerCall 20
PauseBetweenCUPSQueueUpdates 5

the first queue of 124 queues appeared after 55s - here is the cups-browsed_log
cups-browsed_log.txt .

It is better than previous interval though, but I'm not sure if it is expected.

[tillkamppeter]

This means that this issue is fixed. The slowness of queue creation needs to get investigated, a near-future feature request.

[tillkamppeter]

@zdohnal, what makes it take 55 seconds before the first queue is created is the fact that all your 124 printers are BrowsePolled from one server, so they are discovered in one single event response (timeout event to trigger a BrowsePoll on a given server) and in this single event response all entries for the local queues are generated in cups-browsed's internal data structure. For queues to be created, the current event response must terminate, so that another one (the queue creation, triggered by the earliest timeout in the printer entries) can start. So what has to be improved is that also BrowsePoll event responses can be split in smaller portions, like we already do with the CUPS queue update event response.

[zdohnal]

@tillkamppeter Ok, I'll open the new issue for it to track it.

Thank you for explanation and fixing the issue!