Messages

I did a few bugfixes (compatibility to modified sane method was broken), and made some changes to the GUI part, so that it works with angelnu's improvements of the server backend and doesn't print out fuzzy messages. (= (See binary files destined for /usr/bin in attachment.)

The package description of suldr-scantopc-gui still refers to samsungmfp-scantopc, this should be updated to suldr-scantopc.

I'll incorporate these into the package in a few days, I'm away from my main system at the moment.

Also I would appreciate having the changelogs within the deb files as I originally implemented them (see attachment). When I created the deb packages I just renamed them to changelog and put them in the debian folder.

The changelogs are present.  I just moved them into /usr/share/doc/<package-name>/ according to the Debian standard.  I will merge the versions you included with the ones I was updating.  However, placing them in /debian/ is technically incorrect, because then they end up in the system control directory when the package is installed.  I also compressed them (again according to the standard), but I'm okay with leaving them uncompressed if you prefer.

And maybe one could add a postinst routine to suld-scantopc-gui that disables the automatic startup (at bootup) of the server backend, since most people would probably use this package on desktop PCs and don't need the server running in background all the time. Like:

Code Select Expand


sudo update-rc.d -f samsungScannerServer remove

And of course the corresponding postrm code:

Code Select Expand


sudo update-rc.d samsungScannerServer defaults


I'll look at this, but my immediate response is similar to angelnu's - that people installing this package probably expect it to always be running (in the sense of not wanting to think about whether or not it is).  And I think defaulting to leaving it always running is probably correct, as it does not really interfere for those who don't need it while still allowing flexibility for those who do.  If a good argument could be made for either case, I can provide another package of the gui that disables running the server, or create a configuration prompt.  That would allow the user to choose.

I don't know really know how, but couldn't one ensure that suld-scantopc-gui always gets removed before suld-scantop, so no problems regarding these new routines arise?

This is possible, I can implement it if necessary.

FYI, the scantopc package has been downloaded about 300 times in the last 2 months, and nearly all of those users also download the gui package.  However, since the forums are so quiet about these packages, I don't know how many are actively using it.  Or if it "just works" for most, or if it is failing regularly.  There definitely seems to be some interest, though.

In the end I gave up using the Samsung scanner and bought a dedicated Canon CanoScan LiDE 110 which just works (I scanned some 1200 CD covers).

I'm a fan of this scanner as well (actually had good luck with several of the same type).  Sorry the printer won't work as a scanner, but I'm glad you found a workable solution.

I have found that I can use commend line tools to export it successfully however this then makes it more burdensome when a printer is changed.

Then the bug is in the CUPS GUI.  None of the errors/warnings you report should affect your ability to export the printer, and the fact that you can do it on the command line reinforces that.

However, you could simply remove the cms directory (restoring it is easy by re-installing the suld-ppd package if needed).  If that allows the GUI to work, great.  If not, then the issue really isn't anything to do with the Samsung driver itself.  Your printer does not need any of the cms information anyway.

The "E" warnings regarding the Samsung cms files are "normal".  It has to do with the fact that the Samsung driver seems to expect color management files to be stored as a sub-directory of the ppd files, but CUPS expects only ppd files.  These errors do not actually interfere with anything.  The "W" warnings are normal background noise from processes not directly related to the printer, and the "E" warning about cupfilters I don't know about but also is likely not really a problem.

So without more information about what specifically you expect and what is actually happening, it is hard to provide any assistance.

The difference in printing speed probably has more to do with changes in CUPS than the driver; recent CUPS versions are triggering issues for some people, although it's not entirely clear how much is due to poor driver design vs bugs in CUPS (both are factors).

It's probably my poor searching but I haven't found anything yet that explains what is necessary to use a Samsung network printer. I'm expecting that I should just need to tell YaST where it can find a PPD and tell it what protocol to use to what address and I'm done. But I haven't found anywhere yet that those are the necessary and required steps.

Essentially, you are correct.  The only other potential issue is whether the printer also needs a specific driver available.  The reason there is no simple "this is how it's done" is that Samsung makes a lot of printers and the details can differ substantially.

I have just downloaded the UnifiedLinuxDriver and extracted CLP-410.ppd, which I hope is the right PPD. I got the printer to print its network config and have checked I can ping its IP address. I haven't yet found anywhere that specifies what protocols the printer supports, though I've seen things that say there might be a problem with IPP.

That is the correct ppd for the CLP-415, and I don't see anything obvious in it would require that the Samsung driver be installed to use it (at a very cursory glance).  However, if it doesn't work, there probably is some underlying need for a particular binary component as well.

As far as network protocol, there are issues with IPP with many Samsung printers, but newer ones such as the CLP-415 are less likely to be affected.  If IPP does not work, the printers also generally work with LPD or RAW.  Alternatively, IPP issues may be due to an ongoing issue with CUPS, in which case the solution is enabling older IPP support (see the question links or other recent threads about this).

You should not need anything other than the basic driver package to share the printer as you describe.  I suspect that something is being lost in the interface between the network protocol and the printer driver.  But whether that is a bug in the driver, SAMBA, or a configuration problem (or some combination), I don't know.  My only thought regarding configuration is that the driver can be finicky if a firewall has ports blocked to it, but if any data at all is being sent then I doubt that is the issue.

Two questions:

1. Does an "apt-get update" today clear the issue?  It could be an issue with the apt cache if the server was being slow to respond.

2. When did you notice this starting?  The translation files (really just placeholders to eliminate millions of 404 errors in my log) have not changed since last month.

Comment was moved to a new topic here:
http://www.bchemnet.com/suldr/forum/index.php?topic=150.0

The "Samsung Series" driver is the one associated with the Unified Driver.

You may able to try the ipp14 solution as described here:
http://www.bchemnet.com/suldr/forum/index.php?topic=147

You may want to try it first with with the foomatic or splix drivers, as if it works with one of those then you can remove the unified driver.

If you can print correctly from your Ubuntu machine, then it may be a problem with the Windows driver (which I have not looked at it for years).

If neither computer can print, then presumably something in the server is interfering, but I can't say what.

I realize this is probably not very useful, perhaps someone with experience with this type of setup will share.

I'm not sure how you are configuring the printer.  If it is an auto-detection routine, it will always pick up the splix driver.  To ensure that you have an option to select the Samsung driver, you can install the suld-configurator-2-qt4 package and use that to set up the printer.

Based on what you have posted, you do not have the Unified driver installed at all.  It looks like your printer is configured using the splix driver, which is an open-source driver with good success for some people and not so good for others.

You do not need to uninstall the splix driver if you wish to install the unified driver.

When you switch to/from the 4.01.17 driver from earlier versions, you will generally need to remove and re-install the printer.  Samsung renamed a bunch of files, but CUPS caches the relevant parts when you install the printer.  So for example if you set up the printer when 4.01.17 was installed (or CUPS decided to update its cache, which it does on a schedule I've never figured out), then printing with an older version will lead to the error you saw because that particular file only exists in 4.01.17 and has a different name in 4.00.39 and earlier.

Supposedly this printer should work as a scanner without any of the Samsung driver components at all, but that may be only over USB and not over the network.  Based on your test results, it appears that some sort of real change occurred in the driver between 4.00.35 and 4.00.36 to add Samsung scanning support for the CLX-3175.  But since the relevant files don't play well when mixed with some of the 4.00.35 files, I can't think of anything else to try that would give you both good printing and scanning support except to simultaneously install both versions.  I'm unaware of any mechanism that would allow you to do that aside from using a virtual machine (e.g., via Virtual Box), and configuring one of the driver versions there.  So for example, you could print normally by keeping 4.00.35 installed on your main system, then start Virtual Box and scan via your virtual machine.

Not exactly elegant, but probably your only option at this point.

Try installing /etc/sane.d/smfp.conf from the 4.00.36 driver package.  Possibly in conjuction with removing /etc/sane.d/xerox_mfp-smfp.conf (which can be restored by re-installing the driver-common package).  It may be that xerox_mfp support isn't working for some reason, but smfp support will.

You may need to restart saned for the change(s) to take effect (e.g., sudo service saned restart).

Maybe.  You can try manually mixing and matching files from different driver versions.  To do this, install one of the versions as usual.  Then download the driver package for the other version you wish to mix with by accessing it from the website through http://www.bchemnet.com/suldr/pool/debian/extra/su (be sure to select the one named with the appropriate architecture).

There are two approaches that might be worthwhile.  First, install 4.00.35 as usually, then extract /usr/lib/sane/libsane* from the 4.00.36 driver package and use them to overwrite the 4.00.35 files.  Then test to see if scanning works.

Alternatively, install the 4.00.36 driver, then extract /usr/lib/libmfp.so* and/or /usr/lib/cups/backend/mfp from the 4.00.35 package and overwrite the 4.00.36 files.  You may want to test the libmfp and mfp bits separately, as the first could also impact scanning.

You can always restore the original files simply by re-installing the appropriate driver version.

Please share if some combination works.

Unfortunately not.  The Linux driver is largely missing those options; for some printers the control panel is useful (if it works), but not for most.

However, sometimes quality of printing can vary considerably with the different driver versions, so you may want to just try the different versions that are available and see if one of them is substantially better than the others.

=====
W:Failed to fetch http://www.bchemnet.com/suldr/dists/debian/extra/i18n/Index  No sections in Release file /var/lib/apt/lists/partial/www.bchemnet.com_suldr_dists_debian_extra_i18n_Index
, E:Some index files failed to download. They have been ignored, or old ones used instead.
=====

The error is not actually a problem, and has to do with a work-around I implemented to solve an entirely unrelated problem.  However, I think I have made a change that should eliminate it.

Installed packages:
suld-driver-4.01.17
suld-driver-common-1
suld-ppd-2
suld-network-2
suld-printer-pdf-fix

As I have no idea what the problem is and why it occurs, I would appreciate a lot helpful hints or questions.

Presumably something was updated, either the driver itself or something else in the printing system.  Either way, going back to an older driver (e.g., 4.00.39) may solve the problem.  The 4.01.17 driver does not seem to be "stable" for everyone, and there isn't any reason to use it if an older version works.

The error is not actually a problem, and has to do with my solution to an entirely unrelated problem.  However, I think I have made a change that should eliminate the message; please let me know if you continue to get it.

You have to configure the repository and then use a package management program (anything that can install programs, such as apt-get or synaptic) to download.  See the following links for more details:
http://www.bchemnet.com/suldr/forum/index.php?topic=4.0
http://www.bchemnet.com/suldr/index.html

The short answer is "no".  CUPS does have a tool for updating cached PPD files, but it does not work correctly with the PPDs provided by Samsung.  There is a global updater, but that could have unintended consequences by updating unrelated files.  And doing a manual update would be unreliable, because the cached PPD files are named according to the user-chosen printer name, not the underlying file name - so there is no sure way to detect which of those PPD files should be updated.

I have added a note about this to the troubleshooting information.

I have also considered just symlinking the old names to the new ones, but I don't know if that would work, or possibly break something, because the driver has a tendency to have strong preferences for particular paths.  And I'm unable to test it, because my printer is not supported by the newest driver.

I'm not sure I understand the problem.  Is a printer being automatically configured?  If you set up the printer yourself, you should be able to select the appropriate driver.

I'm also not sure what you mean about missing sane - is there a specific error message you get?

Samsung renamed a bunch of the driver files with the 4.01.17 release, and they are referenced in some (not most) ppd files.  The CLX-3185 is one of those affected, so if you want to use the latest driver then you will need to uninstall and reinstall the printer after updating the driver (and similarly if reverting back to an older version).

The issue arises because CUPS caches the ppd file when the driver is first installed, so it does not automatically pick up the new ppd file with references to the new file names.

Try a couple of earlier driver versions, maybe 4.00.39 and 3.00.90.  It's possible something in the driver itself changed that is interfering with the detection.

And I typed "/opt/Samsung/mfp/bin/netdiscovery --all --scanner" in the terminal  and it gave this back:

# DEBUG: Network printers discovery utility

But this is strange and I have no idea about this.

It appears that the latest netdiscovery is stupid.  I can't get it to produce any output other than that message either.

Try downloading either http://www.bchemnet.com/suldr/pool/debian/extra/s/samsungmfp-network_4.00.35-2_amd64.deb (64-bit) or http://www.bchemnet.com/suldr/pool/debian/extra/s/samsungmfp-network_4.00.35-2_i386.deb (32-bit), opening the file as an archive (file-roller or similar, not gdebi or similar to install it), and extract out the netdiscovery that is in /opt/Samsung/mfp/bin.  Try the same command with that netdiscovery (can be done with the file anywhere, it does not need to be in /opt/....).  If it finds your scanner, open a terminal in the /opt/Samsung/mfp/bin directory, "sudo mv netdiscovery netdiscovery-old", and then "sudo cp <path>netdiscovery ." where <path> is wherever the netdiscovery you extracted is.  Then see if scanning works.

If the older netdiscovery does not find your scanner, you don't need to bother with the second part, because it's probably a network/firewall issue.

Have you tried any of the solutions proposed in the link below?
http://www.bchemnet.com/suldr/scanning.html

Looks like something in the route to me, not sure what.  Hopefully it will continue to clear up for everyone, but feel free to post again if problems persist.

Another obvious and potentially useful traceroute comparison would be to the previous server, which is 206.188.192.118.

Try removing the files you installed and installing a version from the repository.

Hopefully this give you some proof that it may come from something else than our ISPs.

Some.  (To be clear - since I have no problems connecting, all my above statements should be treated as hypotheses based on available information, and ones that I am unable to test myself.  I am glad that you have been able to test at least some aspects.)  Assuming for the moment that I can accept the statements I have received that no filtering or blocking is occuring at my end, the implication is still that somewhere along the route there is a problem.  While not necessarily directly the problem of the ISP, it is still something that only an ISP could resolve.  Of course an ISP does not pre-determine the route, but the route is a variable that they do have some control over and nobody else does.

If the information I have received is incorrect and there is filtering at my end, there is still nothing I can do without explicit evidence showing that.  Which no test has yet indicated, but is still theoretically possible.  If something clearly does emerge to indicate a problem with my provider, I will certainly take it to them.

If it really is just a route issue, then the issue may also resolve itself over time.

If I were in your position at this point, I would take the information you have shared to my ISP and point out that something odd is occuring on a server through which some of their traffic is passing, and they should investigate it.  (Not that I would necessarily expect that they would do so, based on past customer service experience.)  Particularly since AboveNet, now owned by Zayo, has a long history of blocking websites, and has been a user of many blacklists.  Again, just a hypothesis, but it does seem like a suspicious difference given the traceroute output.  It would be interesting, if rather non-trivial, to see if you could reach this site by routing around that server.  The data so far is consistent with (although not conclusive) the possibility that the AboveNet server is blocking your IP address, but not your friend's or proxy server's.  Do you know if any sites that you can reach have a route that passes through that server?

It might also be useful if other users who are having trouble (or trouble sometimes) could perform a traceroute (apt-get traceroute, traceroute -T 173.236.28.2) to see if there is a common point at which the packet stalls.