Raspberry cam multiplexer solution no longer working since release 1.4.x

Camera model
2x Raspberry Pi Cam Module v2 (imx219, 3280x2464 max. resolution)
What is the problem?
Some time ago I utilized a camera multiplexer board to connect two pi camera modules to my octopi (for viewing from different angles). The active camera is selected via i2c (short python scripts adressing the correct i2c register) and could be done via the gui (calling the corresponding script).
To make the board useable it needs to be initialized before use (via separate python init script). Until now this has been done by calling the init script from the webcamd init function in /etc/init.d/webcamd:

do_start()
{
   # Return
   #   0 if daemon has been started
   #   1 if daemon was already running
   #   2 if daemon could not be started

   #init ivport
   python3 /home/pi/ivport/init_ivport.py

   is_alive $PIDFILE
   RETVAL="$?"

   if [ $RETVAL != 0 ]; then
       start-stop-daemon --start --background --no-close --quiet --pidfile $PIDFILE --make-pidfile \
       --startas /bin/bash --chuid $USER --user $USER -- -c "exec $DAEMON" >> $LOG 2>&1
       RETVAL="$?"
   fi
}

Worked like a charm. But since 1.4.x it is broken...
Now if I boot up the octopi I get a "webcamstream could not be loaded" in the control tab. If I go to the stream URL it says that the webcam server is currently not running.

If however I reboot the pi (no coldboot, just a reboot without power cycling) I get an image right after it comes back in the control tab. Something seems to have changed in the process of the webcam init. I checked with a output file that the init script is called by webcamd init. So I suspect it is a timing issue? The script is executed after the raspberry pi tries to detect the cam?
If I issue the commands on first boot I get:

pi@octopi:~ $ sudo vcgencmd get_camera
supported=1 detected=0

pi@octopi:~ $ v4l2-ctl --list-devices
bcm2835-codec (platform:bcm2835-codec):
        /dev/video10
        /dev/video11
        /dev/video12

Failed to open /dev/video0: No such file or directory

After a reboot:

pi@octopi:~ $ sudo vcgencmd get_camera
supported=1 detected=1
pi@octopi:~ $ v4l2-ctl --list-devices
bcm2835-codec (platform:bcm2835-codec):
        /dev/video10
        /dev/video11
        /dev/video12

mmal service 16.1 (platform:bcm2835-v4l2):
        /dev/video0

To rule out any funky errors I connected a single raspicam (without the multiplexer) it is recognized on first boot and displays the picture right after bootup.

What did you already try to solve it?
systemctl restart webcamd.service
init script called from webcamd init
init script called by @ reboot cronjob
init script called in rc.local
systemd unit calling init script with:

  1. multiuser.target (unsuccessful -> OSError: [Errno 121] Remote I/O error)
  2. graphical.target (successful -> (code=exited, status=0/SUCCESS) but still no picture on first boot)

Logs (/var/log/webcamd.log, syslog, dmesg, ... no logs, no support)
dmesg.log (20.3 KB) syslog.log (365.2 KB) webcamd.log (989.8 KB)
Additional information about your setup (OctoPrint version, OctoPi version, ...)
OctoPrint Version 1.4.2
OctoPi Version 0.15.1, running on Raspberry Pi 3 Model B Rev 1.2

###cam1.py###
#!/usr/bin/env python3

try:
    import smbus
    import RPi.GPIO as gp
    gp.setwarnings(False)
    gp.setmode(gp.BOARD)
    gp.setup(11, gp.OUT)
except:
    print ("There are no IIC.py or RPi.GPIO module.")
    sys.exit(0)

#init: enable bus
bus = smbus.SMBus(1)
bus.write_byte_data((0x70), (0x00), (0x01))

#redundant?
bus.write_byte_data((0x70), (0x00), (0x01))
gp.output(11, False)
###init_ivport.py###
#!/usr/bin/env python3

import smbus

if __name__ == "__main__":
    bus = smbus.SMBus(1)
    bus.write_byte_data((0x70), (0x00), (0x01))

    with open('/home/pi/ivport/init_log.txt', 'a') as file:
        file.write('initialized ivport board...')

Just for the record, when you update OctoPrint you update only OctoPrint. The webcam server is completely separate from OctoPrint (different project really, third party). The init order is also untouched, that's the responsibility of OctoPi, which you do not update either when updating OctoPrint.

Whatever prompted this change, it is either coincidence that it appeared after updating OctoPrint, or it was shaky to begin with and slight changes in startup behaviour or something similar triggered it.