[X2go-dev] [X2go-user] 10x printing speed increase for x2go printing

[--[ UxBoD ]--]

----- Original Message -----
> ----- Original Message -----
> > Hi Phil,
> > 
> > On Mo 11 Apr 2011 13:25:55 CEST "--[ UxBoD ]--" wrote:
> > 
> > > ----- Original Message -----
> > >> Hi Phil,
> > >>
> > >> On Mo 11 Apr 2011 12:07:57 CEST "--[ UxBoD ]--" wrote:
> > >>
> > >> > Yep that is my interpretation of the process as-well, Mike.
> > >> > One
> > >> > thing I have noticed is that if you print the resultant PDF
> > >> > the
> > >> > file
> > >> > is left in the spool directory without being deleted; yet if
> > >> > you
> > >> > cancel from the x2go-print dialogue box the file is removed.
> > >>
> > >> is that x2goclient or PyHoca-GUI/Python X2go? With PyHoca-GUI
> > >> this
> > >> should not happen, otherwise it is a bug I have missed so far...
> > >>
> > >> Greets,
> > >> Mike
> > >>
> > >>
> > >>
> > >
> > > x2goclient 3.01.18.
> > 
> > we have an unofficial bugtracker that we (the devs and the
> > community)
> > still have to discuss about. However, maybe you place such stuff in
> > there already. In case of dropping the software again (Horde) we
> > will
> > surely migrate the already placed-in tickets.
> > 
> > The chance of forgetting such tiny issues without accounting is
> > otherwise potentially given...
> > 
> > Greets,
> > Mike
> > 
> 
> Mike,
> 
> I think I may have worked out why some print jobs are failing and it
> would appear to be an x2go issue and not SSHFS/WAN.
> 
> What is happening is that the Perl script, x2goprint, moves the PDF
> from /var/spool/x2goprint into the users mounted spool directory and
> then creates the .ready file. The x2goclient looks for any new files
> in that directory and if it sees the .ready file it pops up the x2go
> print dialogue window. Now, looking at the code it appears to remove
> the file as-well; in 3.01-18 the pertinent code is in
> onmainwindow_part4.cpp line 200.
> 
> I am thinking this is a timing issue with respect to the .ready file
> being written and the slot which monitors the local spool directory
> firing off an event.
> 
> Just not sure how to solve it yet :(

Okay, in onmainwindow_part4 here is the bit of code which I believe is causing the issue:


if ( !file.open ( QIODevice::ReadOnly | QIODevice::Text ) )
            continue;
        bool startProc=false;
        QString fname,title;
        if ( !file.atEnd() )

My theory is that a lock still exists on the .ready file for which the file.open() cannot be called and therefore the code continues and ultimately removes the .ready file; taking into account the loop I put into x2goprint the script sees that the file has disappeared and writes it again. This is why I believe we see a different count number each time.

Any thoughts on how to resolve this one ?
-- 
Thanks, Phil