Messages

For Ubuntu 8.04, you may need to use the samsungmfp-driver-legacy package; I don't know if the libc6 with that release is current enough to work with the later driver versions.  As long as you don't try to install the configurator packages, there should be no need for X or QT packages.

samsungmfp-sane-fix-multiarch is part of the main scanner package with 4.00.39, so no longer needs to be installed as a separate package (unless using the older driver files).

There is an unidentified problem with some recent qt4 library that conflicts with the qt4 configurator.  I haven't been able to pin it down, because it only seems to affect a few people and I can't reproduce it.  But many other qt4 programs have had similar issues with recent qt4 libraries, so I'm pretty sure it is a qt4 issue and not the configurator.  For now, just use the qt3 version and you can try the qt4 version later to see if it works.

I'm not sure about the file save location issue.  Maybe you should just use another scanner interface such as simplescan or xsane?

Obviously my "mixed feelings" were not with the hard work you've accomplished already but with the pain of getting this smoothly working for all users (let's be honest, the probability that a non-tech user would be able to get this up and running right after having his AIO printer plugged is infinitesimal).

Believe me, that I understand.  This whole thing started when I spent days trying to get my printer working several years ago, and decided to share the results of that, and then tried to simplify and accomodate requests over the years.  The fact that so many thousands of people are using this is so amazing to me partly because I still view it as having a substantial technical hurdle, and so I can only imagine how many might still be struggling.

The answer to your first question is given on this page:
http://www.bchemnet.com/suldr/repository.html

Ubuntu has a more developed structure than Debian for distributing closed-sourced materials, but because Samsung has refused to clarify the legal aspects of distribution, the distributions are correctly assuming that they do not have the right to distribute.  I would be happy to collaborate with anyone who wanted to set up distribution-specific packages and try to get them incorporated into an official repository, but that is beyond what I can commit to for the near future.

Your second question is also partially addressed there, mainly that I don't have time.  (This whole project has grown far beyond what I expected when I started it.)  However, I have no objection if someone else wanted to set up a Launchpad project and point to this website.  That is essentially what an Arch Linux user did when setting up the Arch package.

Double-check to make sure an appropriate ppd appears to be installed.  It may be necessary to delete the printer and re-install it.

It may also help to try a manual lp print, as in this post: http://www.bchemnet.com/suldr/forum/index.php?topic=59.0 .  For some reason, that seems to clear an initial block in some setups.

I believe you have two choices: update to a more current distribution, or build a custom version of (eg)libc6 at version 2.10 and have the netdiscovery tool use that.  That was a temporary fix I applied via packages in early 2011, but newer Samsung driver versions resolved the issue - except with the particular version of libc6 that you are running.  Given that 10.10 is well out of support anyway, I would suggest updating your whole system unless there is a compelling reason not to.  Grabbing an old copy of libc6 and compiling it is not terribly hard, then netdiscovery just needs to be loaded with a script that loads the old libc6 instead of the current one.

All the configuration is at the begining of the script so it would be easy to move it to an extra file under /etc. Any preferences?

No, anything uniquely identifying works for me.

The script would also need an upstart config file and, potentially, a logrotate one as well.

For compatibility, I use old-style init scripts for packages that need them; that way they can be used with any of the various startup routines, and upstart (or whatever) can deal with it on the fly.  This is simple for me to implement.  I haven't looked at your script closely enough to see if it is generating enough output to justify a logrotate, but feel free to include that if you think it might be necessary.

I am unlikely to do anything with packaging for at least the next two weeks, although I hope to spend some time on it at some point in January.  (I'm really hoping Samsung releases a new driver right before then, but they seem to have a habit of doing that right after I go through an update round.)  So from my point of view, there is no urgency on this.

At the moment what it is anoying me is that Sane is slow with the Samsung devices conpared to scanning from Windows: it takes 45 second to scan a page in "Grayscale - 256 Levels" and 300 dpis while Windows or scanning to a USB memory plugged into the scanner only takes 15. My theory based on the number and size of the packages in my network capture is that the Windows driver is able to tell the scanner to scan and transfer the image already compressed in JPEG format. In Sane I only found support for PNM and TIFF...

I suspect you are correct.  Personally I find that to be no loss, as I much prefer to take the time/storage penalty at the front end and decide later whether the compression is necessary/worthwhile.  I'm probably in a minority, though, and it also doesn't really matter since I personally have no use for this script (no scanner on my printer).  I doubt there is an easy solution to that, unless there is a physical printer configuration option to default to jpeg output.

Of course, it may also just be that the Windows driver is faster or more efficient in its transfer protocol.  That would hardly be surprising given the massive investment in Windows support Samsung has compared to Linux.

Great.  I'll make a note of this as a Configurator issue; it may be related to a couple of other apparently random problems I haven't yet found a proper solution for, and am hoping another update from Samsung will occur soon to help resolve.

I'm not sure why the GPG key was giving you trouble, but based on what you posted you should now be set to install.  The update list you posted is just the servers and package listing files, not the packages themselves.  If you try to install something like samsungmfp-driver at this point, it should work.

As far as installing vs connecting first, it doesn't really matter.  This doesn't involve any sort of auto-detection, so either way you'll need to manually set the driver after getting everything in place.

The sane-fix packages have been incorporated into the main packages, so aren't necessary unless you install an older driver version.  Have you tried something other than Configurator to run the scanner (e.g., xsane or simplescan)?

You might try installing the printer using the generic PCL5e driver.  There are a couple of reports that works on openprinting.org, and it may address your strange printing issues.  Otherwise I can only recommend my standard troubleshooting: trying different driver versions from the repository.

Thanks for sharing.  If this proves of interest to others, and any configuration is moved out of the script itself into a config file, I could probably package and distribute it.

I'm not sure if it will help, but you should be able to install the samsungmfp-scanner package (and its various dependencies) using apt-get in the terminal.

But I think probably the issue is usbfs or usblp.  You could try

Code Select Expand

modprobe -r usblp as a temporary way to see if the printer works without that module running, to at least try to narrow down the problem.  I suspect this is really a bug/issue that should be raised with the distribution, and forwarded to the appropriate upstream folks.

This is an old issue that relates to libc incompatibilities, but I thought it had been long dealt with.  What packages & versions do you have installed from my repository, and is this 32-bit (i386 or 686) or 64-bit (amd64)?

There is a remote chance that the only practical solution will be for you to update your system to a more recent distribution, because only part of this issue is due to Samsung's driver; the other part is actually in certain versions of the libc packages.  And with (X)Ubuntu, those can only easily be updated by upgrading the whole system.

I would guess it is a bug in the pdf renderer, but whether it is ghostscript, cups, or Samsung I couldn't say for certain.  Acrobat typically outputs as PS, which is probably why it worked fine.  There should be no particular problem printing everything as PS.  You could drive the pdf-driver-fix package to see if that impacts the pdf output.

I believe it is resolved, for now.  Please post back if issues return.

I'm glad it is working.  The network host issues appear to be resolved, at least for now.  But when my renewal is next up (in a few months), I may still move.  Please post back if issues return.

If it is working with foomatic, you should be able to install the Samsung driver in parallel, and then just use the Samsung part for scanning support (i.e., install the samsungmfp-scanner package, but don't change anything about the printer setup).

It appears my hosting company is having system-wide issues that are beyond their ability to handle.  This is not an issue I can address.  All I can suggest is to stop hitting the website for at least a few hours, maybe a day or so, and it should reset.  Apparently multiple failed attempts to access fails (due to a slow network, at the hosting end) is causing temporary blocking of IP addresses.  I suspect this is related to a solution they implemented in response to denial-of-service attacks a few weeks ago.  I did encounter the 302-related error briefly today, but it cleared out on its own after the third attempt I made to connect.

I don't have time to deal with this now, but if the issues continue over the next weeks I will see about switching hosts.

It appears my hosting company is having system-wide issues that are beyond their ability to handle.  This is not an issue I can address.  All I can suggest is to stop hitting the website for at least a few hours, maybe a day or so, and it should reset.  Apparently multiple failed attempts to access fails (due to a slow network, at the hosting end) is causing temporary blocking of IP addresses.  I suspect this is related to a solution they implemented in response to denial-of-service attacks a few weeks ago.

I don't have time to deal with this now, but if the issues continue over the next weeks I will see about switching hosts.

Several people have recently reported that trying to print using lp seems to release whatever the blockade is for some printers, such as the method described in this post: http://www.bchemnet.com/suldr/forum/index.php?topic=59.msg233#msg233

IPP errors are almost worthless, in that there is no good reference for what they mean, and the majority of them seem to have no impact anyway.  (I'm sure some are serious and useful, I just don't know how one is supposed to tell the difference.)  However, you may have better luck using a different protocol (lpd or raw).

Odd.  I can't reproduce this issue, and nothing has changed with the key recently.  (Release.gpg updates every time I change a package, that is not related to the key itself.)  If you try again, does it persist?

I have looked briefly.  I don't think the problem is on my server, though: on average, the server generates a total of 6 302 errors each day.  That's in comparison to 140,000 404 errors per day and about 50,000 successful connections per day.  So if you are seeing 302 errors regularly, you probably account for a substantial fraction of all 302 errors just by yourself.  The file you indicated generates over 200 404 errors per day on its own, which is more than the total 302 errors for every single file on the server per month.  If anything, there is actually a trend of decreasing 302 errors over the last few months.

That said, I'm actually not sure why it is generating 302 errors at all.  When I have some time, I will look into this some more.  But that may be a while unless there is more evidence this is a widespread issue, because I'm buried in other projects that have urgent deadlines.

A few people have had luck sorting out random issues by issuing a print command using "lp" from a terminal (for example, see the first post of this thread: http://www.bchemnet.com/suldr/forum/index.php?topic=59.0).  A test page print may sometimes have a similar effect.

When you reinstalled the drivers, did you first delete the printer and then re-add it (via either interface) after re-installing?  If not, some settings will persist.

     To go somewhat far afield, just about the time this started (2-3 weeks ago) I had removed everything - file & directory - I could find associated with vmware. I don't see a connection but I'll throw anything against the wall to see if it sticks.
     Also, there was Hurricane Sandy with the loss of my broadband connection.

Vmware has several network hooks, so if you were manually cleaning files then it is possible that something was left behind or unintentionally wiped out.  However, if this is the only wierd network behavior you are seeing, perhaps not.  I know there are still some lingering network issues related to Sandy, so it is possible that is related and this will clear up without any effort on your part.

     When you say "disable the repository" do you mean to simply comment (#) it out?

Yes.

Thanks for sharing.  I will make a note of this solution.

   In addition to the ping, I have deleted the repository and reinstalled it and reinstalled the GPG key.
   Each time, but only the first time, I run apt-get update afterwards the error messages are gone. After that first time they come back and remain no matter if I ping or delete, etc. again.

It sounds like for some reason your system is dropping all communications with the server.  Which is odd, because it's the same server as this forum, so if one works for you then so should the other.  I can't reproduce any of your errors.  It's possible that you just happen to be hitting when my host is having problems (they've been subject to several denial of service attacks recently), but if happens regularly then that's probably not it.

   Is this related to the SMF server issues?
   My printer continues to work regardless.
                             kpgoin

Nothing to do with SMF, whatever the source of the problem.  (The SMF issues don't affect this server regardless.)  You really only need the repository if you need to reinstall or update, so perhaps it is simplest to just disable the repository for a few days and then reactivate to see if the problem goes away on its own.  Nothing will happen soon that you would miss by doing that.

Odd.  I'll add trying a manual lp run to the troubleshooting tips.  I'm glad it is now working.

Have you tried printing a very simple (text) file using lp to bypass the Samung driver?  That would at least verify if it really is a hardware issue.  This thread here with the CLP-365 seems to be a similar problem: http://www.bchemnet.com/suldr/forum/index.php?topic=59.0

Also as suggested in that thread, you could uninstall all the repository packages and try the Samsung installer using their download package.

Otherwise I can't think of anything you could do remotely; trying it with a Windows/Mac machine or a different distribution (just in case it is an issue with the version of CUPS he has) probably isn't an easy option.  And realistically if it works with lp but not with any straightforward mechanism of installing the driver, it probably isn't going to make for a long-lasting printer relationship even if it can be forced to work.

I'm not sure what the difference is, because the driver package you downloaded is the same one available on the SULDR website and the basis for the 4.00.39 packages.  But I'll make a note for when I have time to look into it.