Bug 191781 - [patch] multimedia/webcamd - much improved rc.d script
Summary: [patch] multimedia/webcamd - much improved rc.d script
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Hans Petter Selasky
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-10 12:58 UTC by dreamcat4
Modified: 2014-09-13 18:34 UTC (History)
3 users (show)

See Also:


Attachments
Latest version. The complete rc.d script. (not patch) (6.08 KB, text/plain)
2014-07-11 11:44 UTC, dreamcat4
dreamcat4: maintainer-approval+
Details
svn diff on head (7.19 KB, patch)
2014-07-14 17:34 UTC, dreamcat4
no flags Details | Diff
webcamd.in - HPS changes (3.54 KB, application/x-shellscript)
2014-07-15 21:45 UTC, Hans Petter Selasky
no flags Details
svn diff on head (17.58 KB, patch)
2014-07-20 08:43 UTC, dreamcat4
no flags Details | Diff
rc.d script, re-written to address previous issues. See Changelog. (16.21 KB, text/plain)
2014-07-20 08:46 UTC, dreamcat4
no flags Details
New webcamd daemon options (8.42 KB, patch)
2014-08-19 15:24 UTC, Hans Petter Selasky
no flags Details | Diff
More webcamd daemon options. (4.26 KB, patch)
2014-09-01 18:12 UTC, Hans Petter Selasky
no flags Details | Diff
webcamd rc.d script (9.67 KB, application/x-shellscript)
2014-09-04 21:09 UTC, dreamcat4
no flags Details
files/webcamd.in with %%PREFIX%% (9.67 KB, application/x-shellscript)
2014-09-04 21:11 UTC, dreamcat4
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description dreamcat4 2014-07-10 12:58:03 UTC
Hello. This PR to supersede the old, previous PR @ https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=159306


Please try this new rc.d script. It fixes and improves a lot of things:

* Reliablility in regards to PIDFILE (no longer uses PIDFILE at all).
* Multiple devices / multiple instances can be set.
* Extra additional instances may also be set without specifying devices, "e.g. -L" invocation, etc.
* Better error checking / warning.
* Both global and instance-specific flags can be overridden for maximum ease of use + flexibility.
* rc.d start / stop / restart / status sub commands all work correctly now, and give the expect correct / official looking messages.


Links to view and download:

New rc.d file:
https://github.com/dreamcat4/ports/blob/master/multimedia/webcamd/files/webcamd.in

Git Commit:
https://github.com/dreamcat4/ports/commit/1cc82d3006031d393598cdff1dd436a9c133eb12

Git Patch:
https://github.com/dreamcat4/ports/commit/1cc82d3006031d393598cdff1dd436a9c133eb12.patch


Looking to Hans for maintainer approval. Many thanks.
Comment 1 Hans Petter Selasky freebsd_committer 2014-07-10 13:34:20 UTC
Patches look good. I will get them through some testing first.

Thank you!

--HPS
Comment 2 Juergen Lock freebsd_committer 2014-07-10 14:14:33 UTC
Interesting, but doesn't yet pass rclint: (devel/rclint)

WARNING:root:[0]: Persistent service?  Needs shutdown KEYWORD
ERROR:root:[31]: rcvar is not set correctly
ERROR:root:[34]: Override blanks in mandatory values (:=/:- vs =/-)
ERROR:root:[35]: Override blanks in mandatory values (:=/:- vs =/-)

See also: http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/rc-scripts.html

Thanx! :)
Juergen
Comment 3 dreamcat4 2014-07-10 14:28:56 UTC
The only reason I didn't add:

# KEYWORD: shutdown

To my new script was because it's not in the previous version of the webcamd rc.d script. Hans, you may add it if you wish. That may be a good idea considering it's possible to have a -L / -D client / server invocation.

Those other 3 remaining error reported by rclint aren't really proper errors. Just the rclint program is not detecting properly / not recognising the syntax. But they look OK when you check manually.
Comment 4 Juergen Lock freebsd_committer 2014-07-10 15:17:05 UTC
I'll leave

# KEYWORD: shutdown

for Hans to decide, but I wouldn't ignore the actual rclint errors, be it only for consistency to other rc scripts.  Also to quote the portersbook entry I linked:

'The _enable variable is not optional, and should use the ":" for the default.'
Comment 5 dreamcat4 2014-07-10 15:39:34 UTC
(In reply to Juergen Lock from comment #4)
> for Hans to decide, but I wouldn't ignore the actual rclint errors, be it
> only for consistency to other rc scripts.  Also to quote the portersbook

OK then Nox. Here is an update that will fix all of the rclint stuff.

https://github.com/dreamcat4/ports/commit/9e30afc3fd4bcbb6399bf8dbe64116e6f9645ecd

The new file is available at here (click RAW):

https://github.com/dreamcat4/ports/blob/master/multimedia/webcamd/files/webcamd.in

I did put in the SHUTDOWN and LOGIN after all because that section of the Porters Handbook you make me read, which says that it is required too.

Many thanks,
Comment 6 dreamcat4 2014-07-10 17:20:12 UTC
Minor: Put back hald_enable to suppress un-necessary warning coming from check_yes_no() function if the variable hald_enable is not set.

https://github.com/dreamcat4/ports/commit/ce34261ed24f8ef9d9a31635942fce73fa4da31e
Comment 7 dreamcat4 2014-07-10 17:55:17 UTC
I have just had yet another idea for improvement. If you guys are interested please say so:

Can be added a feature to auto-resolve any connected devices which match a specific USB vendor id string. This is useful, as I noticed the device number change from 7.3 -> 7.2 on reboot. Not even re-pluggin it then (because was some previous some hot-plugging in the same uptime session, the first 7.2 slot was not re-used).

rc.d script can be programmed to search the USB vendor id string from gripping the output of 'usbconfig' command:

$usbconfig
...
ugen2.2: <Acer Crystal Eye webcam SuYin> at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA)
...
ugen7.2: <SCEH-0036 SONY> at usbus7, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA)

If the user want to set in rc.conf:

webcamd_device_0_name="Acer Crystal Eye webcam SuYin"
webcamd_device_1_name="SCEH-0036 SONY"
etc…
webcamd_device_$n_name=

This would be the list of device names to recognise. If found multiple identical device models, all will be loaded on match the same USB vendor id string (since no way to distinguish, unless USB each has some serial number, i don't know).

It can be in addition to the other ways already provided. So the previous ways still remain too.

I can get the rc.d script to grep usbconfig command, extract the "ugen2.2" and "ugen7.2" field which match the grep command. Then that is enough information to launch instances in a new 3rd loop (similar way like is previously already done for a similar mechanism).

This also mean that if someone want to setup devd to automatically restart webcamd on hot-plugging USB events, then the new "ugen" device numbers will be found correctly on next restart, since the number isn't required to be hard-coded.

What to you guys think about that?
Comment 8 Hans Petter Selasky freebsd_committer 2014-07-10 18:04:02 UTC
Hi,

That sounds like a good idea. Maybe you can do the "usbconfig" only once, and then pass it through a regular expression like "grep -iE -- xxx". You should accept multiple matches. This makes a dependency for usbconfig, but I think that is OK. Possibly this functionality could be integrated into webcamd aswell, which might be more clean?

What do you think?

--HPS
Comment 9 dreamcat4 2014-07-10 18:18:14 UTC
(In reply to Hans Petter Selasky from comment #8)
> Hi,
> 
> That sounds like a good idea. Maybe you can do the "usbconfig" only once,
> and then pass it through a regular expression like "grep -iE -- xxx". You

Yes.

> should accept multiple matches. This makes a dependency for usbconfig, but I

Probably OK because usbconfig is included in FreeBSD base.

> think that is OK. Possibly this functionality could be integrated into
> webcamd aswell, which might be more clean?

Yes indeed. In fact all these function would be better inside webcamd (forking / spawning) as C code is faster and give better performance.

I can make very easy in the rc.d script right now, which take just 1-2 days. Which can be done right away. Then later on, when you eventually can work on the C daemon, it can replace any stuff in rc.d script with C mechanism of daemon.

But first it may help to decide beforehand possible interface for C daemon, when starting up multiple instances.

For example if webcamd rc.d script wants to start on 2 identical device then we make some fixed delay of n seconds (normally 0,1, or 2 seconds) to avoid possible conflict of /dev/dvb node names being grabbed.

Yet if the webcamd 'C' daemon had some good lock mechanism communicate with it's sister processes. It could reserve node names ahead of initialization, then 2 instances can be started simultaneously without such delay. And the 2nd instance can see the reserved /dev/ node names, and avoid them. This is important if the time taken to initialise the USB hardware device is not constant. It could be less than 1 second, or several seconds.


> 
> What do you think?
> 
> --HPS
Comment 10 Hans Petter Selasky freebsd_committer 2014-07-10 18:33:05 UTC
Hi,

You can override the "unit" allocation which is used when creating the devices using the "-v" parameter. Maybe not that well documented, and then you don't need any delay between the invokations.

--HPS
Comment 11 dreamcat4 2014-07-10 19:06:14 UTC
(In reply to Hans Petter Selasky from comment #10)
> Hi,
> 
> You can override the "unit" allocation which is used when creating the
> devices using the "-v" parameter. Maybe not that well documented, and then
> you don't need any delay between the invokations.

Hmm. Unfortunately I am not sure yet how rc.d script can be smart enough to automatically know from just a "ugenN.n" device number if it is going to appear as /dev/video{n} or /dev/dvb/adaptor{n} in devfs.

We could say reserve *both*. Which then lead to not-used device numbers. Or some other switching around going on. For example if 2 identical devices are swapped then ugen2.2 become ugen4.4 and visa-versa. Then /dev/dvb numbers will become swapped over too. (since simple counter, and which appear first in the grep list from usbconfig command).

Wheras if we instead use the USB serial number**, then that can correspond to the rc.conf variable's unique index number e.g.:

webcamd_device_0_serial="XXXXX-XXXXXX"
webcamd_device_1_serial="YYYYY-YYYYYY"

Then '-v' flag can be set with index number for consistent device ordering (no matter which is the ugenN.n number).

Unfortunately this situation is not very simple. When a SINGLE dual-Tuner device (like mine) will create:

freenas // root^> webcamd -d 7.2
Attached to ugen7.2[0]
Creating /dev/dvb/adapter0/demux0
Creating /dev/dvb/adapter1/demux0
Creating /dev/dvb/adapter0/dvr0
Creating /dev/dvb/adapter1/dvr0
Creating /dev/dvb/adapter0/frontend0
Creating /dev/dvb/adapter1/frontend0
Creating /dev/input/event0

When all these doubled up devices cannot match up cleanly to a single index number. From rc.conf variable {0,1,2,n} as suggested before.

Maybe we can still guarantee the general ordering. I am guessing a little bit here because I don't have 2x identical 'dual tuner device' to try it with. Sorry if it all sounds pretty complicated. Suggestions welcome!

A possible way to make simpler for user, is to automatically generate and keep some local cache file. Which specify the list of all detected USB serial numbers, just to know their relative positions. Then the /dev/ ordering is kept consistent. But the user never to need to know or find out the USB device serial numbers.

** The USB Serial number can be grepped for, individually 1 device, with the following command:

usbconfig -u 7 -a 2 dump_device_desc


> --HPS
Comment 12 dreamcat4 2014-07-10 19:17:33 UTC
(In reply to dreamcat4 from comment #11)
> A possible way to make simpler for user, is to automatically generate and
> keep some local cache file. Which specify the list of all detected USB
> serial numbers, just to know their relative positions. Then the /dev/
> ordering is kept consistent. But the user never to need to know or find out
> the USB device serial numbers.

For this way quoted ^^, maintaining a cache file not necessary. If we just sort on the list of found USB serial numbers low-high. Then the lowest value USB serial number get loaded first, then the next one, etc. In theory that should keep a consistent ordering for hot-swapping identical devices.

But for that method to work, each USB serial numbers must actually be unique, random, or not often duplicated. Perhaps that fact may depend a lot on the device manufacturer. I don't know if it is universally true for all cases.

> 
> ** The USB Serial number can be grepped for, individually 1 device, with the
> following command:
> 
> usbconfig -u 7 -a 2 dump_device_desc
> 

There is also a small time penalty, to run this command 1x time for each detected device.

> 
> > --HPS
Comment 13 Hans Petter Selasky freebsd_committer 2014-07-10 19:30:05 UTC
Hi,

USB serial numbers are not mandatory.

There is currently no last-device number cache. Might be an idea for cuse4bsd, that it can know the allocation mapping. Then some scripts can pull/restore this info at shutdown/boot.

--HPS
Comment 14 John Marino freebsd_committer 2014-07-11 11:17:35 UTC
Assigning PR so it doesn't show up in assigned/triage list when it's clearly being addressed.
Comment 15 dreamcat4 2014-07-11 11:44:51 UTC
Created attachment 144572 [details]
Latest version. The complete rc.d script. (not patch)

OK. It is all done now. Enjoy :)

Newest version still passes rclint (thanks to Jurgens). I do not think I can improve it any more. So today I attach the full, latest version to this PR page. That is the whole rc.d script (not a patch).

NOTE: As a ".in" file, it contains %%PREFIX%% substitution pattern. And won't work if you try to execute it. Use this sed command to make it work:

sed -i '' -e 's|%%PREFIX%%|/usr/local|g' /usr/local/etc/rc.d/webcamd

You can browse all of the improvements to date in GitHub.

https://github.com/dreamcat4/ports/commits/master


Kind Regards.
Comment 16 dreamcat4 2014-07-14 17:34:54 UTC
Created attachment 144663 [details]
svn diff on head

svn diff format, for commiters (no new changes).

Hans, please try / test those new features we discussed in this script when you can. I have tried myself. Could not find any problem.


What else may be possible is improved documentation distributed inside the upstream src tarball. (unfortunately I don't have srcs / find link).



BTW. (which only affects multiple devices) My script cannot automatically increment the -v option for automatic fast start / concurrent startup

Reason:
Some device is 'dual tuner'. So affects such -v number assignment / allocation. Other reason: devices get created as 'video0' or 'dvb'. And we cannot know which before-time. So that affects the next available '-v' allocation number also.

No further technical improvement will be added. However the rc.d script is now already very flexible.



Supplementary technical notes below. [BORING], please ignore.

Fast start:
It always fast-start when detected only 1 single device. This below note is only in regards to when users have 2+ devices.

So if a user has tried 'service webcamd start'. The default setting is "startup_delay=1". If users want, they can set all their device parameters manually, including the -v number. That will permit concurrent starting. Example:

sysrc "webcamd_instance_0_flags=-d ugen2.2 -v 0"
sysrc "webcamd_instance_1_flags=-d ugen7.2 -v 1"
sysrc "webcamd_startup_delay=0"

All processes will be launched simultaneously (no waiting delays).

Fast start is also possible in other situations too (without '-v' manual flag). But the user has to check they have no possible device conflict. For example if one device will create video0, and the other device will create dvb/adaptor0. Then no conflict will occur. Can just set startup_delay=0. All fine. It doesn't work for 2 identical devices. User should first check their devices to see if OK / not OK.

Hot plugging:
If hot plugging back into the same USB ports, then only minor device numbers will change (not the major). for example '7.2' become '7.3'. This means that the ordering of devices in the usbconfig list remains the same (generally speaking).

If using the recommended setting: "webcamd_device_0_name=<USB Device Name>", then the startup order will determine the /dev/dvb/adaptor{0,1,2} numbers assignment... This should then correspond the same to such physical fixed USB ports. Unless multiple webcamd devices are sharing a same USB hub. However that is not a recommended way to plug in such video devices. Because sharing the bandwidth (of a single USB port) will limit the performance.
Comment 17 Hans Petter Selasky freebsd_committer 2014-07-15 20:08:55 UTC
Hi,

I will modify this script a tiny little bit, because I see devd loading of webcamd now gets broken, due to the expected startup order.

--HPS
Comment 18 Hans Petter Selasky freebsd_committer 2014-07-15 21:45:08 UTC
Created attachment 144706 [details]
webcamd.in - HPS changes

Hi,

I've made some changes. Can you please verify that they are working for you?

--HPS
Comment 19 dreamcat4 2014-07-16 09:45:43 UTC
Ok. I reply back in private email to Hans. Because some things / issues we need to sort out.
Comment 20 dreamcat4 2014-07-20 08:43:35 UTC
Created attachment 144811 [details]
svn diff on head

New version.
Comment 21 dreamcat4 2014-07-20 08:46:48 UTC
Created attachment 144812 [details]
rc.d script, re-written to address previous issues. See Changelog.

Changelog:

* Arguments are now passed to 'webcamd' in the correct priority order custom ones FIRST, global ones LAST. That is correct order for how webcamd parses duplicate argv[] arguments.
* You can specify devices by USB name only. Or by USB name AND serial number.
* Script is now fully 'devd aware' (I hope!).
* Any matching custom flags are now found and applied for devd starting too. If it is for the same "ugenX.X" number.
* Name / serial flags are also applied for devd starting too. IF the USB device name / serial matches. (lower priority than custom flags, but both sets will be applied).
* If you specify a -D vtuner client in custom_flags_N, it will be started regardless of the devd being on or off.
* Any USB devices which are started from 'devd' service will not be started from 'webcamd' service. To prevent them from being started twice.
* However if you are running devd and need to issue "webcamd restart" manually, then the devd instances are not restarted. Unless you remember to do a 'devd restart' after it. To help people who forget about that, they may prefix "force" keyword to their manual rc start command. For example: "service webcamd forcerestart". Using the "force" mode will force the webcamd rc.d script to restart everything, not excluding devd ones.


These variables were removed:
* webcamd_devices
* webcamd_device_X_Y

These variables were renamed:
* webcamd_devices_0_name   ---> webcamd_device_0_name
* webcamd_instance_0_flags ---> webcamd_custom_flags_0

These are new variables added:
* webcamd_device_0_serial
* webcamd_device_0_flags

Examples:

# This is one 'group' of variables that are specific to one device

webcamd_device_0_name="Acer Crystal Eye webcam SuYin"
webcamd_device_0_serial="CN0314-SN30-OV03-VA-R02.03.02"
webcamd_device_0_flags="-L 127.0.0.1:5100:-1"


# These are each seperate custom instances.

webcamd_custom_flags_0="-D 127.0.0.1:5100:-1"
webcamd_custom_flags_1="-d ugen2.2 127.0.0.1:5100:-1"


Testing:

* Type "pgrep -f -l webcamd" to check the running processes have a correct arguments list.

* If find a bug, please type:
  * Type "sh -x /usr/local/etc/rc.d/webcamd <args>" to get a full execution trace. Pastie or email it back to me to investigate it. Many thanks.

Known Bug:

* The webcamd program does not accept "-B -D" switches together. And refuses to start, giving the following error message:
+ /usr/local/sbin/webcamd -D 192.168.1.100:5100:-1 -B -U webcamd -G webcamd
webcamd: -B options requires a valid -d option
* You may prefer fixing in "webcamd" C program itself, rather than my rc.d script.


Script Statistics:
* 0 rclint warnings or errors
* 16 shell functions
* 542 lines including comments
* 365 LOC without any comments
Comment 22 Hans Petter Selasky freebsd_committer 2014-08-19 13:26:23 UTC
Hi,

I'm thinking about moving some parts of the webcamd script into a new utility, webcamd_startup_wrapper, because some parameters like the serial number is not fixed at string index 0003.

What do you think?

--HPS
Comment 23 Hans Petter Selasky freebsd_committer 2014-08-19 13:44:08 UTC
Hi,

Possibly it would be simpler to allow webcamd to accept arguments to recognize device according to serial and device name!

--HPS
Comment 24 Hans Petter Selasky freebsd_committer 2014-08-19 15:24:23 UTC
Created attachment 146036 [details]
New webcamd daemon options

Hi,

I've updated webcamd in my SVN adding some new command line options -S, -N and -l that makes your life easier!

Can you apply the attached webcamd_options.diff patch to your webcamd and adopt your new webcamd.in script to use the new -S and -N options instead of invoking usbconfig!

Thank you!

--HPS
Comment 25 dreamcat4 2014-08-23 22:16:49 UTC
Ah OK. The rc.d script will need to be re-worked to use those new options.
I am happy to do that, hopefully will make it smaller / simpler now. I agree is worth it.

Sorry there is something else for me to finish first before getting back to this. Might be a few days.
Comment 26 dreamcat4 2014-08-24 17:21:39 UTC
Well, I've got so far as to recompile the binary and man page with new options patch. Which is a start i guess. Really likw the new '-l' list option, its pretty awesome.

freenas // root^> webcamd -l
webcamd -d ugen0.1 -N "UHCI root HUB Intel" -S "unknown"
webcamd -d ugen1.1 -N "UHCI root HUB Intel" -S "unknown"
webcamd -d ugen2.1 -N "EHCI root HUB Intel" -S "unknown"
webcamd -d ugen3.1 -N "UHCI root HUB Intel" -S "unknown"
webcamd -d ugen4.1 -N "UHCI root HUB Intel" -S "unknown"
webcamd -d ugen5.1 -N "UHCI root HUB Intel" -S "unknown"
webcamd -d ugen6.1 -N "UHCI root HUB Intel" -S "unknown"
webcamd -d ugen7.1 -N "EHCI root HUB Intel" -S "unknown"
webcamd -d ugen2.2 -N "Acer Crystal Eye webcam SuYin" -S "CN0314-SN30-OV03-VA-R02.03.02"
webcamd -d ugen7.2 -N "SCEH-0036 SONY" -S "ALR001DN4J"
webcamd -d ugen7.3 -N "Cruzer Blade SanDisk" -S "200608778107F6227BC0"
Comment 27 Hans Petter Selasky freebsd_committer 2014-08-24 17:41:19 UTC
Thank you!

It was inspired by your webcamd RC script patches :-)

Maybe the new webcamd RC script can have a separate command to get that listing?

--HPS
Comment 28 dreamcat4 2014-09-01 15:55:17 UTC
Oooh. New color scheme.

Status Update:

I have done some of the re-writing now. At this stage, I have not yet merged together custom_flags_N and device_N_flags so there is only 1 list of _flags to process. That is something not done yet.


Question:

Now if a user is willing to embed quotes or escape spaces. Then this is possible:

webcamd_0_flags="-N \"SCEH-0036 SONY\" -S \"ALR001DN4J\""

or

webcamd_0_flags="-N SCEH-0036\ SONY -S ALR001DN4J"


So do you think we still need separate variables for the name and serial now. Or can we prefer to have the user embed them / escape them inside the same flags= line? (as shown above). Because that can help simplify the rc.d script.


Also Hans, unfortunately one thing I cannot test myself is multiple identical devices. Since my DVB-T dual-tuner appears as a single USB device.

I assume that webcamd (if given -N flag) will attach only to the first detected ugen device from the list. Meaning that the 2nd, 3rd etc would not be attached to. Is that correct to assume?

Previously, the rc.d script parsed all the USB devices list and launched a separate webcamd instance for each matching found devices. However I have removed that code now because of the new ways.
Comment 29 Hans Petter Selasky freebsd_committer 2014-09-01 18:12:05 UTC
Created attachment 146633 [details]
More webcamd daemon options.

Hi,

I've added to my printout a filter which removes all non alphanumeric characters and replace them with dash. Dash is not allowed at the beginning or end of string. Then strings no longer need to be quoted!

I've also added an "-M" option to specify match index for "-S" and "-N" options.

Can you use this? Patch must be applied on top of previous one!

--HPS
Comment 30 dreamcat4 2014-09-04 11:14:59 UTC
Status update:

I have re-written the rc.d script now. It is about half the size. Sorry to make you wait I just need a little bit more time to test it by myself. Then will upload the new version for you guys to test / modify also. Many thanks.
Comment 31 dreamcat4 2014-09-04 21:09:58 UTC
Created attachment 146833 [details]
webcamd rc.d script

Re-writted to work for the new -S -N and -M options.
This attachment is drop-in rc.d script.
Comment 32 dreamcat4 2014-09-04 21:11:10 UTC
Created attachment 146834 [details]
files/webcamd.in with %%PREFIX%%

Same as webcamd.new. Just with %%PREFIX%% --> for files/webcamd.in
Comment 33 Hans Petter Selasky freebsd_committer 2014-09-05 09:55:57 UTC
Hi,

A new webcamd port for testing is available here:

svn --username anonsvn --password anonsvn \
      checkout svn://svn.turbocat.net/i4b/trunk/ports

Please test and verify it!

--HPS
Comment 34 commit-hook freebsd_committer 2014-09-13 18:34:13 UTC
A commit references this bug:

Author: nox
Date: Sat Sep 13 18:33:51 UTC 2014
New revision: 368127
URL: http://svnweb.freebsd.org/changeset/ports/368127

Log:
  - Update to 3.17.0.5 . [1]
  - Import much improved rc.d script - check the script at (usually)
    /usr/local/etc/rc.d/webcamd for configuration info. [2]
  - Some Makefile cleanups, pet portlint.

  Submitted by:	hselasky (maintainer) [1],
  		dreamcat4@gmail.com [2]
  PR:		191781 [2]

Changes:
  head/multimedia/webcamd/Makefile
  head/multimedia/webcamd/distinfo
  head/multimedia/webcamd/files/webcamd.conf.in
  head/multimedia/webcamd/files/webcamd.in
  head/multimedia/webcamd/pkg-message
Comment 35 Juergen Lock freebsd_committer 2014-09-13 18:34:56 UTC
Committed.  Thanks!