Messages

I don't think anyone has ever posted the output for this particular printer, but if you do a search for "netdiscovery" in the Ubuntu forums thread (http://ubuntuforums.org/showthread.php?t=341621) you will find many examples of output that you may be able to adapt to your needs.

Thanks for sharing.  I'll add this scanner information whenever I do the next update.

I've never encounted anything quite like what you are describing.  I agree that the presence of the ppd in /etc/cups/ppd implies the drivers installed, but I have no idea why you are having inconsistent reports from the package managers.  As far the print failure, perhaps the 4.00.35 driver package would work better?  (apt-get samsungmfp-driver-4.00-35 should work, regardless of what else is going on.)  Older ones than that probably won't help, because the ML-2160 is relatively new.

I have always had an issue similar to this with my printer, with all versions (back to the old version 2); it simply will not print files over a certain size.  In short, I don't know what causes this.  But you may be able to make it work with some trial and error.

You can try different versions of the printer, or try to switch to a different printer model for large file prints.  It takes some trial and error, and print quality may suffer somewhat.

It may help to have the file in the native format of the printer.  In my case, that means creating a PS file directly rather than having the printer software do the conversion sometimes helps (because it generates a smaller file).  With current SPL printers, that is more likely to be PDF.  A different PDF rendering, such the samsungmfp-driver-pdf-fix package provides, could also work for you.

Possibly downgrading to the 4.00.35-2 versions would address the problem associated with the upgrade?  If you updated both Slackware and the drivers at about the same time, that's the only way to test where the problem might be.

I'm glad it is working again; the detailed report is useful.

Hi

I'm using Slackware64-14.0 and a CLX-3185 multifunction printer.

The add printer app cannot find the printer driver.

In order to install 4.00.39 I had to modify the install script to enable it to restart cups.

elif test -e /etc/rc.d/rc.cups ; then
      CUPS_SCRIPT=/etc/rc.d/rc.cups

Slackware and Debian are substantially different in how they handle startup scripts.  Differences in startup and a couple of other minor (but time-consuming) issues are why I have not yet built packages for non-Debian distros.  Maybe one day I'll have time to sort it all out.

And the Unified Driver Configurator starts fine, when I try to add a printer it is detected as a local printer on /dev/mfp4, when I click on next and try to select a printer driver there is nothing shown in the selection box.

Where is that screen looking for the ppd files, so that I can check if the files are in the correct place.

samac

As far as I know, it looks the same places CUPS does: in either /usr/share/cups/model, where there should be a samsung directory, or in /usr/share/ppd, again looking for a samsung directory.  The latter used to be a symlink to the former, but I have removed that because it breaks the ability to install some non-Samsung printers in recent versions of CUPS due to a bug in CUPS.  However, in your case it may be necessary.

Thank you quite a lot.

Alas I am on Ubuntu, and there I run into dependency problems; last is that libsane is required with <=1.22.3, but that's not provided anymore (can't enforce that version; Ubuntu provides 1.022.7-ubuntu).

But it's good to hear that I am no alone with this problem, and that for you downgrading worked out. That makes me hope future versions of samsungmfp will work again.

Use samsungmfp-sane-fix-multiarch to get around the libsane problem; otherwise the above solution should work.

I'm still collecting information on who is having difficulty with 4.00.39 and under what conditions; when I have enough information to actually identify the problem, I'll let you know.

Which samsungmfp package versions would you using before/after the upgrade?

I'm not sure what the "install anyway" option is, but it may be a problem with the sane package in Zorin-os rather than these packages.

Clearly Samsung made some sort of major change to their library files; you are the second person to report that the old libsane-smfp works better.  Unfortunately, they didn't increment the version, so dealing with this is more complicated than it should be.  I'll look into it when I have some time.

Regarding the configuration file warning, that is due to the new wrapper scripts Samsung is using on all their custom binaries; as near as I can tell, most of the binaries never generate or try to read a configuration file, so the warning is pointless.

You have to install all old versions to go back.  So try 4.00.35-2 or 3.00.90-4 with the 4.00.35-2 common package.

The other approach would be to extract the /usr/lib/libmfp* and /usr/lib/sane/libsane-smfp* files from the driver-4.00.35 4.00.35-2 or driver-3.00.90 3.00.90-4 packages, and see if just using the old library files makes a difference.  Some other users have reported that it does.

When you say downgrading didn't work, do you mean you removed all the 4.00.39-1 packages and went to the 4.00.35-2 packages, or just that you went to an earlier samsungmfp-driver-xxxx package?  But until late May 2012, the packages in use were version 3.00.90, so the problem could be older than the available packages would let you check.

Have you tried scanning using the Configurator, just to see if a different interface works?

The 4.00.35-2 packages are still available in the repository if you force the old versions.  You may need to uninstall all the packages, install the old samsungmfp-common, and then install the other older packages you need.

Odd.  And also an indication that Samsung must be modifying that library without incrementing the version numbers, which complicates things at my end.  I'll see what I can do when I have some time.

If you are inclined to do so, please test whether making the following replacements has any effect:
(1) only netdiscovery with the one from the samsungmfp-network 4.00.35-2 package
(2) only /usr/lib/sane/libsane-smfp.so.1.0.1 with the one from the samsungmfp-driver-4.00.35 4.0035.-2 package
(3) both of the above

Try using samsungmfp-driver-4.00.39.

If you are using the 4.00.39 versions of the packages, samsungmfp-scanner-sane-fix is unnecessary (it is now part of samsungmfp-scanner), so this is exactly correct.  If you are still at 4.00.35, lock the version of samsungmfp-common and it will install correctly.

I'm guess that this is now a permissions issue.  Is your normal user account a member of the lp and scanner groups?  There may also be a permission problem with one of the usb-related groups; I can't immediately think of which one off the top of my head, but you can probably find it with an internet search.

Do any of them work if you execute as root (sudo)?

I'll continue to think about what it could be as I have time.

Scanning still works otherwise with the latest driver?

Have you tried using the 4.00.39 packages, but using the 4.00.35 netdiscovery binary (from the 4.00.35 network package)?  The solution depends on whether the problem is restricted just to the netdiscovery module or something in the scanner library files.

The repository has been updated with the two latest driver versions from Samsung.  Chances are that most people won't notice any changes, but hopefully it will resolve a few issues, and several additional printers are supported for both printing and scanning.

I had to make a bunch of "under the hood" changes to the structure of packages; I believe I resolved all issues so that upgrades should go smoothly, but it is possible you will encounter a hiccup.  If so, I suggest just updating the samsungmfp-common package; that will generally get the package manager straightened out and pull in all the other updates.

Note that there are a few new packages, which are of only administrative interest, and the samsungmfp-scanner-sane-fix(-multiarch) packages are gone - I incorporated them directly into the scanner package.

If anyone is still experiencing this, I am curious as to whether the newly released (to the repository) versions of the Configurator work better (i.e., the Qt4 versions are as stable as the Qt3 ones).  Since I can't reproduce this issue, I can't test it.

Long delay, but a new driver/configurator version is available, and it is possible that it resolves this issue.

I have no experience with it, but also no reason to think it would be problematic based on its specs and information on the Samsung site.

IPP is the most sophisticated protocol; this is a quick summary of sum advantages:
http://www.cups.org/articles.php?L193+TFAQ+Q

That said, most home (or even small office) users have no need for the advantages of IPP, and LPD or JetDirect/Raw work just fine.  I believe some of the Samsung printers do provide a little more information about ink levels & the like over IPP than LPD, but by no means all of them.  And if the printer does not properly support IPP, IPP can be a headache.

SMB is the Windows sharing support, for printers shared over a Windows network.

Personally I use LPD for all the many printers my laptop interacts with at home, work, and when traveling, because it is so reliable and I don't really care about the extras that IPP provides.  But none of those printers are highly managed, either.

The "common" is what I consider the version number.

Your plan is reasonable; if for some reason you wanted to test the repository first, you could do step a last.

I am preparing new packages.  The new versions won't directly address this issue, but may solve it anyway.  Look for them within a week.  If you still have trouble after trying the 4.00.36 or 4.00.39 packages once they are available, I'll see if I can help you narrow this down.

I have fixed this in the next round of packages I am preparing; look for 4.00.36 and 4.00.39 drivers within a week.

Even better would be if it just worked without this.  I am starting to assemble new packages based on the 4.00.36 and 4.00.39 drivers; perhaps one of those will address this problem.  With a bit of luck, I'll have those uploaded within a week.