[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: remote printing for an USB printer



On Sat 20 Dec 2014 at 22:03:50 +0100, Pierre Frenkiel wrote:

> On Sat, 20 Dec 2014, Brian wrote:
> 
> >. . .
> >This shows you have the android correctly set up for printing.
> 
>   not exactly: I said that I didn't have anything to setup: just launching the
>   application and wait for 10 seconds.
>   I think that a so mature OS as Debian should provide the same
>   facility.

It does.

>   This also shows that the sharing is correctly setup on the server side.

For the Android.

> >This shows you do not have the wheezy client correctly set up for
> >printing.
>   very useful! If the client was correctly setup, I sould not need to
>   post for help...

Stating the obvious (or the apparently obvious) can concentrate the mind. :)
 
> >"Successfully"? In what way?
> >Either the job was successful or it wasn't. Which is it? Printing or no
> >printing?
>    I thought I clearly described what happened:
>       - I get a paper sheet whose content is what I sent to the printer, but:
>       - on the client, the job remains in the queues, and the printer is
>         marked as "stopped"

Where is the printer queue set up? On the client or on the server?

>       - on the server, the printer queue grows indefinitely, and the printer
>         spits page after page, until I cancel the job on the client, and all
>         jobs on the server.
> 
>    I don't see an other way to describe more clearly what is happening.
>
> >Enable debug logging on client and server; cupsctl(8). Print. Examine logs.
> 
>    Ok. I'll see whether this can lead to some explanation

Empty the error_log with '>/var/log/error_log'; print ; send the client
log to the list if you wish.
 
> >Say what cups version is on the server.
>   on the server: 1.7.5-9 (jessie, i386)
>   on the client: 1.5.3-5+deb7u4 (wheezy, amd64)

cups-browsed needs to be correctly set up on the server for the client
to be able to see the advertised queues.

"listen 192.168.1.12" should not be the least bit necessary.


Reply to: