Messages

New version up, with the -f (and also re-ordering a couple of statements in postinst that were incorrect).

New packages posted.

Finally, let me suggest to the nice project admins that if you repackage an usb-only,printing-only subset of the deb files, I'm sure it would please a lot of people, not just me.

This is essentially what you get if you download one of the driver .debs.  Yes, it also contains a very basic bit for network function and scanning, but these do not add much in the way of disk space.  On average, a driver .deb, along with the required network and common debs, is about 6 MB when installed.  The PPD packages are about 33 MB, but you can avoid installing the whole package by extracting out only the PPD that you want.  These are substantial improvements over the "single download" method Samsung provides, and which Samsung designed for desktop environments and not for embedded systems.

What you view as "simplifying" the process would actually lead to a massive increase in the number of debs and required maintenance time.  For example, a single .deb install for each printer, with and without scanning and/or networking, and available in the various driver versions (which is an important variable) would generate something like 5,000 packages.  And that still assumes that any GUI is a separate package.

Your other points are addressed in information available on the website, but the main driving factor for what you perceive as complexity is that I do this for free in very limited spare time.

[v0.4.3]

I agree with both of you, if the scantopc package is installed alone.

But when the GUI package is added I think it is better to refrain from automatic startup of the service. The GUI (ubuntu App Indicator) I wrote starts the server upon its application start (or restarts it if the server is already running) and stops it upon its exit. (To save resources on laptops/netbooks etc. ...) The option to chose what one wants (configure while installing) is good, but doesn't really work, because even if you chose to have the server started upon system boot, as soon as the GUI is closed the server is stopped as well and would then not be restarted until next start of the GUI or reboot.

So maybe one should work on the package description of the GUI package? Like:

An Ubuntu Application Indicator (a graphical user interface, GUI) for the server app used for the 'Scan to PC' function of Samsung multi function printers (MFPs) in suld-scantopc. It has some convenient buttons and issues informational notification bubbles about incoming scan files. Note: This is intended for notebook/desktop PC users that do not want the backend server to always run but rather started and stopped together with the GUI.

Good points.  As currently designed, you are probably correct about the server always running issue.  I was thinking about it from the point of view of someone who might not always want to run the GUI to be able to scan, but at times might want the notifications, etc.  But as designed, I think your description of the GUI use case is accurate, particularly with the updated description.  I will make the necessary changes.

Sorry a/b the changelog issue. I do not know very much about debian packaging. As I clicked on 'Get changelog' in Synaptic it told me nothing was present - which obviously isn't true. I incorporated your changelogs into what I already wrote and attached the new ones. You can leave them compressed, btw - the most standard way is probably the best way. ;)

No problem.  I didn't learn about all the standards until I started putting together this repository, even though I had built several packages before then.

v0.4.3 (both scantopc and scantopc-gui, see bundled attachment): I improved a few other things (logging and error handling) and added an option to the conf file to disable the scanner object caching introduced by angelnu, since this does not work with multiple servers registered at the same scanner. Ideally the scanner connection should then be closed after each (multipage) scan, but this causes a seg fault (exiting SANE does as well). Problem is, that the scanner only has one port 9400 to listen to one computer running the server ... But for now the general option is there and at least leads to less problems with multiple servers even though the main problem remains. (My scanner usually freezes if two different servers try to reach it via SANE (port 9400) at the same time, and one of the servers gives me some SANE I/O Error ...)

I will update with these changes.

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