Red Hat Bugzilla – Bug 472908
issues with delayed scheduling
Last modified: 2009-03-06 19:43:46 EST
I was trying to understand some of the delayed scheduling features, and there seems to be some issues with it in the queue viewer (ie what you get when you click on the applet). If I print a job and mark it as "on hold", the applet appears, and the job shows up in the queue viewer, but its state says "processing". The cups web interface on the other hand, correctly says "on hold since ...". One consequence of this is that I can't actually release the job from the queue viewer. If I print a job an mark it as "at 20:00" or somesuch, it does show up with a state of "Pending" in the queue viewer. It would be nice if it would say when the job will be printed, and also if there was a way to reschedule it for a different time (mostly, a "print now" button). For the pending job, I have a sensitive "Hold" menu action, and if I use it, the viewer actually shows the job as "Held", so the problem with the other job seems to be just that the viewer doesn't pick up the right state, not that it can't handle held jobs at all...
What does 'rpm -q system-config-printer' say? I'm having trouble reproducing the 'wrong state' part, and I'm wondering if you're seeing a problem with missed job events. When I submit a job using (for example) 'lp -H 23:00 ...', the job shows as 'Held', and selecting 'Release' from the context menu prints the job now. (Yes, it would be great to show the hold time in the viewer though..)
system-config-printer-1.0.11-1.fc11.i386 Fwiw, I can't consistently reproduce the probblem either, but I am having other problems: the applet doesn't show up when I queue a print job...
Kill the applet and run it by hand like this: system-config-printer-applet --debug If you catch the problem after doing this, please attach the output here.
Ok, I was trying this with my local usb printer not plugged in. It appears in the print dialog with a paused icon, but GTK+ still thinks it will accept jobs. But when I send a job, it silently vanishes. Why does cups say that the printer is accepting jobs, when in fact they go to /dev/null ?
For me on F-9 they are queued in this situation. If that's not happening for you please supply troubleshoot output.
Everything seems to work in rawhide now.