Messages

Sometimes the about dialog in the Configurator gives the correct version.  There is a file in the download from Samsung that lists the various versions as well (there are several).  And it usually says on the Samsung website where you find the file, although the download itself is invariably named differently.

All told, it's non-trivial.  Even my repository versioning is a bit arbitrary, because I version everything after the core driver, but there are actually several version numbers in use.  And to make it even more interesting, the 4.00.xx series of drivers restarted the numbering they use on the download file names, so for example the new 4.00.36 is give as 0.86, but it is actually newer than the 1.04 you have.

Open-source drivers would be great, and no doubt would simplify everything around this repository.

I would accept closed-source drivers that weren't a clossal pain to deal with and built using ancient libraries as a short-term solution, though, and Samsung hasn't even expressed any apparent interest in that.

I'm glad the printer is working and the repository is useful.  At this time, I am not accepting donations.  The costs for running this site and the repository are not excessive, and I don't want anyone to feel like they need to spend more money just to get a printer working (using them is expensive enough as it is).

At the present apparent growth rate of users for this repository, in a couple of years I may need to upgrade to a more extensive web hosting system or a dedicated server; at that point, I may reconsider my decision.

The driver supplied for that printer is 3.00.65.  You might have better luck with a newer version; I've been using CUPS 1.5.3 with more recent versions of the driver without any trouble, albiet with a different printer.  If you don't want to pull from the repository, you can download newer versions from the SULDR website or by looking on Samsung's site for a newer printer (e.g., SCX-3405, CLP-365).

Thanks.  The symlink is inherited from the original Samsung package.  I'll remove it in the next release (hopefully in one or two weeks).  I don't think it will impact anything else about the driver.

I think this is probably really a bug in CUPS, because I can't see any reason that detection of a loop (which it isn't actually) should impact reading later directories.  But it's easy for me to fix.

In the meantime, anyone who has trouble finding the driver for a second printer while the Samsung driver is installed should remove that link.

Which packages are you installing?  I'll also have to look at see what was updated with 12.04.1 to see if it some library issue.  I may have time to look at this in detail over the weekend, but it could be the weekend following before I do.

If you get the xsane, etc. errors even without the printer on/connected, then it is not an issue related to the driver.  I suspect that is the case from your error report.  In this case, you might want to try a launchpad bug report to see if Ubuntu support has any ideas.

If programs do start (or at least stop core dumping) when the printer is off, then it might actually be a driver issue, but it could also be an interface problem.  In that case, report back here and maybe someone can help.

If you can (temporarily) hook up a computer directly to the same switch as the printer, then you can use this solution (modified from http://ubuntuforums.org/showthread.php?p=10482031&postcount=656):

On some machine that is in the same network segment with the Samsung (usually by attachment to the same switch, even if only temporarily to obtain the file):

Code Select Expand


/opt/Samsung/mfp/bin/netdiscovery --all --scanner >netdiscovery.output


On the computer(s) that need to scan when not on the same network segment (all done as sudo/root):
Copy netdiscovery.output to /opt/Samsung/mfp/bin/:

Code Select Expand


cp netdiscovery.output /opt/Samsung/mfp/bin

Rename the netdiscovery file:

Code Select Expand


mv /opt/Samsung/mfp/bin/netdiscovery /opt/Samsung/mfp/bin/netdiscovery-org

Create a new /opt/Samsung/mfp/bin/netdiscovery with this as the contents (using any text editor):

Code Select Expand


#!/bin/sh
if [ -f /opt/Samsung/mfp/bin/netdiscovery.output ]
then cat /opt/Samsung/mfp/bin/netdiscovery.output
else
/opt/Samsung/mfp/bin/netdiscovery-org $*
fi

Then make the script executable:

Code Select Expand


chmod 755 /opt/Samsung/mfp/bin/netdiscovery


(Disclaimer: I have modified this from the original, which had some bits that no longer apply to these packages, but I have not tested it.)

It would have be to a computer hooked to the switch that the printer is currently on that you do the first step with; moving the printer temporarily would not work.

If you can't obtain the netdiscovery.output file, I don't think there is any way to deal with this.  As you indicated, the broadcast ping is not the best solution (and obviously not what the Windows driver uses).

Glad to hear it.  When I start work on the rpm packages, I will be sure to let you know.

Thanks for sharing.

Thanks.  I had been expecting Samsung to release drivers for that printer for a while now.  I'm currently running behind on monitoring drivers and putting together a new set of packages, but hopefully in the next couple of weeks I can put out an update.

Good addition, thanks for sharing.

When I have some time (maybe in a couple of weeks), I will look into how difficult it might be to build "real" rpm packages instead of relying on alien to convert them.  If it isn't a substantial amount of extra effort, I may be able to create an rpm repository as well.  I will post here again if I get to a point where it would be helpful to have some testing done.

Three of them are not a problem:

libtiff3-samsungmfp: no problem.  That indicates that Fedora still has a libtiff3 package (Debian no longer does), and you should not need this package at all.

samsungmfp-configurator-qt4: this is due to not having the driver package installed (see below).

samsungmfp-scanner-sane-fix-multiarch: this is a valid conflict but not a problem; you only need the non-multiarch or the multiarch version of this package, and the error suggests the non-multimarch was successfully installed.

And the hard one:

samsungmfp-driver-4.00.35: alien apparently sometimes fails to preserve symlinks when converting packages.  Based on the specific file name errors, that's what is happening to you.  The libraries are part of the package and/or the network package, but those specific names are links to the actual library files.  Try running the following commands as root:
in /usr/lib: ln -sf libmfp.so.1.0.1 libmfp.so.1
in /usr/lib: ln -sf libmfp.so.1.0.1 libmfp.so
in /usr/lib: ln -sf libnetsnmp.so.10.0.2 libnetsnmp.so.10
in /usr/lib/sane: ln -sf libsane-smfp.so.1.0.1 libsane-smfp.so.1
in /usr/lib/sane: ln -sf libsane-smfp.so.1.0.1 libsane-smfp.so

I'm not sure if creating those links before installing the package will eliminate the errors, or if you need to force-install the package (not sure what the command would be) and then create the links.

Som additional issues you may encounter due to missing symlinks:

You may also need to add this link for the ppds to actually work when setting up your printer:
in /usr/share/ppd: ln -sfT ../cups/model/samsung/ samsung

And if you planned to use the samsungmfp-lpr package:
in /usr/local/bin: ln -sfT ../../../opt/Samsung/mfp/bin/slpr lpr

There will also be link problems with the samsungmfp-parallel package, but there is no reason you would need that, and I'm not sure it would work in Fedora anyway.

If you manually download the packages that you want (from http://www.bchemnet.com/suldr/pool/debian/extra/), you should be able to use alien to convert the .deb packages to .rpm packages and then manually install them.  Look at the information on the repository homepage about selecting packages to determine which ones you will need; you can also probably determine which ones by the "missing dependency" errors when you try to install a particular driver package.

However, I haven't personally tried it, so please share success or problems.

Also, why when I install the driver package at V3.00.65 does it install the other files at V4.00.35-2? Is this correct?

It is correct.  Only the "driver" packages vary in version; the rest of the packages should be the most current.  I've tried multiple versioning schemes, but the only one that doesn't cause confusion in some circumstances requires a lot of redundant packages and wasted server bandwidth (and even that can cause confusion when "different" packages are really the same).

Does anything in the last bullet under #6 for scanning troubleshooting help or seem relevant?
http://www.bchemnet.com/suldr/scanning.html#6

I'm guessing that what is happening is that the print management tool is incorrectly handling a return message from the printer.  So it's as likely a bug in the print mangament tool.  (system-config-printer?  I'm not sure what Mint is using.)

However, it maybe that an older driver version would work.  So you can try installing samsungmfp-driver-3.00.90 or samsungmfp-driver-3.00.65 to see if those still allow you to print and avoid the error message.

If not, you can try searching the system log to see if there is anything logged about the message (look for "paper jam" or the printer model, or something else distinctive), but I have generally found print error logs to be not very useful.

Hm - the response I thought I posted while traveling seems to have not actually been posted.  Stupid coffee shop wireless.

To start, you don't need the "download that package..." bit now that you have updated your Ubuntu system.

For package selection, the two packages you probably need are samsungmfp-scanner and samsungmfp-scanner-sane-fix-multiarch.  That should get scanning operational.

Although it may now not be relevant for you, I will look into modifying my packages so that they can (possibly) tolerate the crossover packages being co-installed.

Good to know, thanks.  If I find a clever way of monitoring the updates Samsung posts, I'll be sure to share it.

I do it the same way you do.  I try to keep track of 2-4 of the most recent printers, as those are where the newest drivers are likely to appear.  But it's tedious, and I only look about once a month.

I can post here when I find a new version to alert you, which lately has been about every 6 months.

See if question #6 on this page helps: http://www.bchemnet.com/suldr/printing.html#6

If not, I can provide more assistance after I return from some travel if you clarify what you mean by "having trouble".

I am traveling (hence the lack of response to this point), but will look at this when I return to see if I have any ideas.

I'm sorry to hear that.  At the moment, I don't have any other ideas.  I will have monitor what Samsung/Kodak provide as drivers to see if it can be made to work, and support may also be added by someone working on the sane project and made available in a later sane version.

Try installing samsungmfp-configurator-qt3 and see if it works.  It will automatically remove samsungmfp-configurator-qt4 as part of the install.

Thanks for sharing.  This implies the problem is likely to be a conflict with some update to a Qt4 library, which I may be able to track down and deal with when I have some time in a week or two.  In the meantime, a Qt3 install is simple enough. 

I managed to get scanimage to stop crashing by disabling the file I added to /etc/udev/rules.d and restarting udev.  Scanning from the command line now works fine with the caveat that often the first scanimage -L after the printer has been idle won't detect it (I think it times out before the printer finishes waking up; at any rate any further scanimage commands work without issue).

Glad to hear it.

The properties page on the Configurator still closes as soon as it opens, but that's not something I particularly care about any more.  I'm willing to help with further debugging, though, in case tracking it down might help other users.

I'll let you know after I've had some time to look through the traces - it may be a while.

One final comment: I'm not sure if the udev rules.d stanza mentioned on the scanner troubleshooting page is necessary for some models, but it turned out not to be needed for this one (just adding the id to xerox_mfp.conf was sufficient), and actively interfered with the wireless scanning.  It might be helpful to add a note to that page clarifying the situation.

Good to know, but odd.  I'll look into this some more as well.

Maybe it's using the Xerox backend?  Try the similar solution in the third bullet for http://www.bchemnet.com/suldr/scanning.html#3 .

Or less likely, perhaps it uses the smfp backend that is provided with the Unified Driver?  You could try re-installing the samsungmfp-scanner package and then add the printer to the smfp backend in a similar manner.  (You don't need to change the printer configuration.)

If that doesn't work, I suppose you can try other backends at random, but most likely it simply isn't supported.

I don't use chromium, but I would guess that there is a .chromium or .config/chromium folder in your home folder that probably stores that information and could be copied.