Messages

I have found a reference that suggests this printer is the same as the SCX-4729, so you can start by trying that printer driver.

For scanning, see if running "sane-find-scanner" in a terminal produces any output when the printer is connected via USB.  Post the output of the "ID" label here if so.

The only two suggestions I have are to try a different USB port (sometimes it matters) or to try the suld-driver2-1.00.06 package.  It may be the newest driver works better with that version of CUPS.

I'm assuming from your post that the scanner worked in Mint 14, or at least at some earlier time?  If so and you are using the same drivers, the problem is probably related to some other system change and a bug report with Mint would be more appropriate.

The scanner cleary is recognized, just not responding to programs.  This can often be due to the particular USB port in use.

Otherwise I don't have any immediate suggestions.

Thanks for sharing this.

I can't eliminate the zero-byte files, for the reasons described by one of the posters to that bug forum.  (I get hits on translation files at an average rate of 2-3 per second and peak rate of 50-100/second - if I let all those be 404 errors, the error log and server load get huge, and my host complains about not being able to detect denial of service attacks through the noise I generate.)  Making them non-zero-byte but still not full translations won't help, and I can't generate translations in over 100 languages.  And generating "fake" translations (e.g., making them all identical English ones) is (a) still much harder on the server and (b) misleading to users who actually aren't using English (a majority).

In my view, this bug should have been accepted and pushed out to 10.04 LTS as a patch to apt.  But since that seems unlikely, the two solutions I see are:

1) Disable translation files (how to do this is also given in the same bug report) (part of the problem here is that around the same time, apt defaulted to always looking for translation files, which creates the noise that leads to the need for zero-byte files.....)

2) Disable this repository.

Given the actual frequency of updates here, option 2 with a periodic (once every 3-6 months or when a problem occurs) re-enable to see if a new driver version is available actually seems perfectly reasonable to me.  It's clear to me from download stats that a sizable fraction of users are only checking for (or applying) updates every few weeks anyway.

Based on what I can find with web searches, the only known solutions to problems of this type are resolved at the user end.  See, for example, http://askubuntu.com/questions/158148/why-does-apt-get-keep-waiting-for-headers-on-oracle-repository (and the links therein), but there are other references if you search for something like "apt get translation 99%".  Most commonly it does require a thorough cleaning of the cache or addressing some sort of network configuration problem with many simultaneous connections.

It could well be the multiple connections issue in your case, because the translation files are static.  Therefore, apt only attempts to download them on a fresh install, and makes many more connections to the server at that time than on subsequent updates.

But copying them from a working computer is equivalent, so you should not encounter this problem again regardless of the actual source.

There is nothing to recreate - the translation files are zero bytes.  And all files test fine from where I am, and seem to be working for thousands of other people all over the world.  Getting stuck at 99% of a zero byte file doesn't even make sense, which suggests that the real problem is something else.

If you still observe that this only happens with a new setup of the repository and not with an existing older one, perhaps there is some small error in the way the new one was set up?

I have no real idea what is causing this.  Perhaps a bad network hop between your computer and the repository?  In the absence of something more specific or additional reports of a problem, I can't see a solution.

As before, my first suggestion is to install the drivers via the repository.  Although given that the 1.00.06 driver didn't work and the installer for that one is okay, I'm not optimistic it will matter.  This sounds like an issue with the actual printer, not the driver, especially given that even the Windows driver doesn't work perfectly.  I suggest contacting Samsung support.

This guide doesn't work. I've also tryed to download the file from my browser and it seems that the bzip2 translation files are corrupted. No problem with the files in gz format.

What problem are you actually having?  More than 1200 people have successfully downloaded packages in the last 24 hours, so the repository in general is working.

The "translation" files are all empty placeholders, regardless of format.  (They exist simply to avoid generating millions of "file not found" errors each month, which tend to annoy my provider because of the huge log files and the appearance of a denial-of-service attack.)  So it is not possible for one format to be corrupt and another to work, although error messages may indicate otherwise.

I am putting out official notice that this repository will probably not last forever.  There is no short-term risk it will disappear, or that anything currently available will be removed.  However, there is a serious risk that updates will become even more infrequent and/or eventually stop altogether.

There are three major reasons for my winding down my effort in this project, in order of least to most important:
1. I no longer own a working Samsung printer.  I am therefore unable to test any drivers, so all packages are untested when posted.

2. The latest Samsung installer is decent, and most of the problems that originally led to the creation of this repository are fixed.  (At least, for those printers supported by the "driver2" drivers, 1.00.06 and higher.)  Therefore, motivation to keep creating packages is considerably reduced, although there is still some benefit to such an approach.

3. At this point in my life, I have very limited free time.  Every significant update to this project consumes most of a weekend, and I rarely have a weekend free any more.  Even minor updates and occasional forum responses take up a significant fraction of my free time.  I do not expect to have time or energy to spend on this project with any consistency.

All that said, the current repository and files will remain indefinitely.  And I would be happy to have someone else contribute or even take over, while retaining the infrastructure I am currently using.

If you have any interest in potentially ensuring that this project continue, just post here and I will be in touch (you do not need to share you email address publicly).  In the meantime, I will continue to respond to forum posts when possible and deal with what maintenance of the packages that I can.  I am uncertain whether any future drivers released by Samsung will be packaged or not; if they are similar to existing drivers and relatively painless to wrap up, I will.  If Samsung releases yet another drastically changed driver, I expect to give it a pass.

Packages for the newest driver (1.00.06) have been released.  These are marked "driver2" because there are major changes compared to the previous versions, including a lack of parallel support and no Configurator.  However, there is support for arm (soft float, armel).

Packages are completely untested.  Please post with problems, and see the web pages for more information if you encounter problems.

Fixed.

I expect to have time this weekend to push these out to the repository.

On most Debian/Ubuntu systems, recommended packages are treated as dependencies and automatically installed.  So this would likely not show up for most people, even though python-pysnmp4 is (apparently) required.

Unless there is some reason not, I will update the dependecies when I re-package this weekend.

I am running into a problem, though-- when trying to use apt-get install, I am getting the following error:

I don't immediately know what exit status 103 actually means.  Is it just this package?  You might just try removing it, clearing the cache, and trying again - that sometimes addresses some random errors.

Sorry the delay, I'm working a crazy schedule at the moment.

For now, you can just make the change to the latest version and post, I'll pull it and update the package.  For now I'm more likely to get around to dealing with it that rather than with a separate source repository, although that may be something worth considering in the future.

Fair enough.  When I next have an afternoon to update things, I will add that information.  I'm glad it worked so well for you.

Have you tried either the 4.00.39 or 4.00.36 drivers?

Just to check the simplest thing: if you run "sudo apt-key list", does a key for the repository exist?  If not, adding suldr.gpg to apt's keys may have failed.

I am not sure why it is crashing for you.  If all you are trying to do is add the printer, I suggest an alternate tool, such as system-config-printer.  Otherwise, the qt3 version of the configurator might work.

Try installing suld-configurator-1-qt4 to get an older version of the printeradd routine that seems more stable.

If you are using the SpliX driver, you may need to follow the steps given here:
http://www.bchemnet.com/suldr/scanning.html#3

In particular, enabling of Xerox MFP may be necessary (I don't know if the Fedora SANE package already includes it or not).

The SCX-3400 is not officially supported by the 3.00.65 driver, so a failure there is not a surprise.  I suggest trying 3.00.90, 4.00.35, and 4.00.39.  Chances are that one (or all) of those will work better than either of the two versions that you have tried.

As of Aug 1, Samsung appears to have released a new driver for all currently supported printers, with the version of 1.00.06.  Theis driver appears to add ARM support, but the structure of the driver is very different from previous versions.  Samsung also appears to have removed the Configurator and many other components.  As time permits, I will work on packaging this version and creating packages for ARM devices.  It will be at least a few weeks, due to my limited free time and the complexity involved.

In the meantime, if anyone tests the installer directly from Samsung, please share any experiences.

I don't know.  The drivers that Samsung released last week are radically different from all previous versions.  It will take me a while just to work through how the new drivers work to be able to correctly package them, and this is a really bad time of year for me to have the time to invest.  I will see what I can do, but it will likely be a few weeks before there is anything ready.

I don't have any indication of errors with the server.  Perhaps try cleaning out your cache, as described here:
http://www.bchemnet.com/suldr/forum/index.php?topic=67.msg273#msg273

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.