CLoud9 TIDL example sees CMEM Error after recent upgrade

[Jon Morss]

After recently upgrading my BBAI via the link below, the Cloud9 TIDL classification example fails for CMEM error.

Link used to upgrade BBAI

https://beagleboard.org/upgrade

Error seen:

File path: /var/lib/cloud9/BeagleBone/AI/tidl

File: /var/lib/cloud9/BeagleBone/AI/tidl/classification.tidl.cpp

Arguments: 

File name: classification.tidl.cpp

File extension: cpp

File base name: classification.tidl

Packages: ~.c9/packages

Project path: /var/lib/cloud9/

Project name: projectname

Hostname: localhost

Hostname path: https://undefined/BeagleBone/AI/tidl/classification.tidl.cpp

URL: http://localhost

Port: 8080

IP: 0.0.0.0

Command: BeagleBone/AI/tidl/classification.tidl.cpp

Python: python3

Python path: /usr/lib/python3.7/dist-packages:/usr/local/lib/python3.7/dist-packages

/var/lib/cloud9/common/Makefile:28: MODEL=BeagleBoard.org_BeagleBone_AI,TARGET=classification.tidl,COMMON=/var/lib/cloud9/common

/var/lib/cloud9/common/Makefile:147: GEN_DIR=/tmp/cloud9-examples,CHIP=am57xx,PROC=tidl,PRUN=,PRU_DIR=,EXE=.so

ti-mct-heap-check -c

sudo mjpg_streamer -i "input_opencv.so -r 640x480 --filter ./classification.tidl.so" -o "output_http.so -p 8080 -w /usr/share/mjpg-streamer/www"

[sudo] password for debian:

MJPG Streamer Version.: 2.0

 i: device........... : default

 i: Desired Resolution: 640 x 480

 i: filter........... : ./classification.tidl.so

 i: filter args ..... :

Initializing filter

loading configuration

allocating execution object pipelines (EOP)

CMEM Error: init: major version mismatch between interface and driver.

CMEM Error:     needs driver version 0x4160000, got 0x4150002

TIOCL FATAL: The cmemk kernel module is not installed. Consult the OpenCL UserGuide at http://software-dl.ti.com/mctools/esd/docs/opencl/index.html

/var/lib/cloud9/common/Makefile:169: recipe for target 'start' failed

make: *** [start] Error 1

Output from version.sh

debian@beaglebone:/var/lib/cloud9$ sudo /opt/scripts/tools/version.sh

[sudo] password for debian:

git:/opt/scripts/:[43e2e0e554b10d779fdbc730bb0d5d197e467d02]

model:[BeagleBoard.org_BeagleBone_AI]

dogtag:[BeagleBoard.org Debian Image 2019-08-03]

UBOOT: Booted Device-Tree:[am5729-beagleboneai.dts]

kernel:[4.14.108-ti-r130]

nodejs:[v6.17.0]

/boot/uEnv.txt Settings:

pkg check: to individually upgrade run: [sudo apt install --only-upgrade <pkg>]

pkg:[bb-cape-overlays]:[4.14.20200312.0-0rcnee0~stretch+20200312]

pkg:[bb-wl18xx-firmware]:[1.20200322.0-0rcnee0~stretch+20200322]

pkg:[kmod]:[23-2rcnee1~stretch+20171005]

pkg:[librobotcontrol]:[1.0.4-git20190227.1-0rcnee0~stretch+20190327]

pkg:[firmware-ti-connectivity]:[20190717-2rcnee1~stretch+20200305]

groups:[debian : debian adm kmem dialout cdrom floppy sudo audio dip video plugdev users systemd-journal input i2c bluetooth netdev gpio pwm eqep remoteproc admin spi tisdk weston-launch xenomai cloud9ide]

cmdline:[console=ttyS0,115200n8 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 rng_core.default_quality=80 quiet video=HDMI-A-1:1920x1080@60e]

dmesg | grep remote

[   39.306068] remoteproc remoteproc0: 58820000.ipu is available

[   39.345676] remoteproc remoteproc1: 55020000.ipu is available

[   39.395618] remoteproc remoteproc2: 40800000.dsp is available

[   39.398003] remoteproc remoteproc3: 41000000.dsp is available

[   39.455514] remoteproc remoteproc1: powering up 55020000.ipu

[   39.455562] remoteproc remoteproc1: Booting fw image dra7-ipu2-fw.xem4, size 3751356

[   39.465881] remoteproc remoteproc0: powering up 58820000.ipu

[   39.465928] remoteproc remoteproc0: Booting fw image dra7-ipu1-fw.xem4, size 7051536

[   39.927096] Modules linked in: omap_remoteproc virtio_rpmsg_bus rpmsg_core uio_pdrv_genirq uio usb_f_ecm usb_f_mass_storage usb_f_rndis u_ether libcomposite cmemk(O)

[   39.928076] Modules linked in: omap_remoteproc virtio_rpmsg_bus rpmsg_core uio_pdrv_genirq uio usb_f_ecm usb_f_mass_storage usb_f_rndis u_ether libcomposite cmemk(O)

[   39.967301] remoteproc remoteproc3: powering up 41000000.dsp

[   39.967350] remoteproc remoteproc3: Booting fw image dra7-dsp2-fw.xe66, size 21014532

[   39.977004] remoteproc remoteproc2: powering up 40800000.dsp

[   39.977039] remoteproc remoteproc2: Booting fw image dra7-dsp1-fw.xe66, size 21014532

[   39.999179] remoteproc remoteproc1: registered virtio1 (type 7)

[   39.999203] remoteproc remoteproc1: remote processor 55020000.ipu is now up

[   40.001317] remoteproc remoteproc0: registered virtio0 (type 7)

[   40.001339] remoteproc remoteproc0: remote processor 58820000.ipu is now up

[   40.106153] remoteproc remoteproc2: registered virtio2 (type 7)

[   40.106177] remoteproc remoteproc2: remote processor 40800000.dsp is now up

[   40.134498] remoteproc remoteproc3: registered virtio3 (type 7)

[   40.134522] remoteproc remoteproc3: remote processor 41000000.dsp is now up

[   61.744815] remoteproc remoteproc4: 4b234000.pru is available

[   61.768955] remoteproc remoteproc5: 4b238000.pru is available

[   61.780959] remoteproc remoteproc6: 4b2b4000.pru is available

[   61.799147] remoteproc remoteproc7: 4b2b8000.pru is available

dmesg | grep pru

[   56.852898] pruss_uio_shmem 4b200000.pruss_shmem: Allocating gdev

[   56.852926] pruss_uio_shmem 4b200000.pruss_shmem: Allocating info

[   56.852946] pruss_uio_shmem 4b200000.pruss_shmem: Requesting resource

[   56.853002] pruss_uio_shmem 4b200000.pruss_shmem: Mapping resource

[   56.853415] pruss_uio_shmem 4b200000.pruss_shmem: Registering with uio driver

[   56.855842] pruss_uio_shmem 4b200000.pruss_shmem: Saving platform data

[   56.889266] pruss_uio_shmem 4b280000.pruss_shmem: Allocating gdev

[   56.889294] pruss_uio_shmem 4b280000.pruss_shmem: Allocating info

[   56.889317] pruss_uio_shmem 4b280000.pruss_shmem: Requesting resource

[   56.889378] pruss_uio_shmem 4b280000.pruss_shmem: Mapping resource

[   56.889418] pruss_uio_shmem 4b280000.pruss_shmem: Registering with uio driver

[   56.910568] pruss_uio_shmem 4b280000.pruss_shmem: Saving platform data

[   60.590938] pruss 4b200000.pruss: creating PRU cores and other child platform devices

[   60.604803] pruss 4b280000.pruss: creating PRU cores and other child platform devices

[   61.744815] remoteproc remoteproc4: 4b234000.pru is available

[   61.745011] pru-rproc 4b234000.pru: PRU rproc node /ocp/pruss_soc_bus@4b226004/pruss@0/pru@34000 probed successfully

[   61.768955] remoteproc remoteproc5: 4b238000.pru is available

[   61.769147] pru-rproc 4b238000.pru: PRU rproc node /ocp/pruss_soc_bus@4b226004/pruss@0/pru@38000 probed successfully

[   61.780959] remoteproc remoteproc6: 4b2b4000.pru is available

[   61.781173] pru-rproc 4b2b4000.pru: PRU rproc node /ocp/pruss_soc_bus@4b2a6004/pruss@0/pru@34000 probed successfully

[   61.799147] remoteproc remoteproc7: 4b2b8000.pru is available

[   61.799337] pru-rproc 4b2b8000.pru: PRU rproc node /ocp/pruss_soc_bus@4b2a6004/pruss@0/pru@38000 probed successfully

dmesg | grep pinctrl-single

[    0.755794] pinctrl-single 4a003400.pinmux: 282 pins at pa fc003400 size 1128

dmesg | grep gpio-of-helper

lsusb

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

Bus 001 Device 002: ID 046d:082d Logitech, Inc. HD Pro Webcam C920

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

END

Looks like the cmemk module is not loading:

TIOCL FATAL: The cmemk kernel module is not installed

Cheers,

Jon

[Robert Nelson]

On Tue, Mar 24, 2020 at 5:31 PM Jon Morss <jonn...@gmail.com> wrote:
>
> After recently upgrading my BBAI via the link below, the Cloud9 TIDL classification example fails for CMEM error.
> Link used to upgrade BBAI
> https://beagleboard.org/upgrade

> CMEM Error: init: major version mismatch between interface and driver.
> CMEM Error: needs driver version 0x4160000, got 0x4150002
> TIOCL FATAL: The cmemk kernel module is not installed. Consult the OpenCL UserGuide at http://software-dl.ti.com/mctools/esd/docs/opencl/index.html

Yeap, I've been busy upgrading both Debian Stretch & Buster to TI's
sdk 06.02.00.81

https://github.com/beagleboard/Latest-Images/issues/11

To fix your problem, two fixes:

Fix 1: update "./update_kernel.sh" so stretch uses cmem 4.16.00.00 on
kernel modules:
https://github.com/RobertCNelson/boot-scripts/commit/43e2e0e554b10d779fdbc730bb0d5d197e467d02

Run:

cd /opt/scripts/tools/
git pull

Fix 2: switch your current version of cmem: (the kernel update script
will fix it going forward, but this will fix your version today)

Run:

sudo apt update
sudo apt remove ti-cmem-4.15.00.02-modules-`uname -r` --purge
sudo apt install ti-cmem-4.16.00.00-modules-`uname -r`
sudo depmod -a
sudo update-initramfs -uk `uname -r`

and reboot..

Regards,

--
Robert Nelson
https://rcn-ee.com/

[Jon Morss]

Hey Robert,

Cool.  Thanks.

However, I now end up with a different error:

NOTE: I did an upgrade after the update. Also, the update_kernel bumped my kernel to r131 from r130.

info: you are running: [4.14.108-ti-r130], latest is: [4.14.108-ti-r131] updating...

The result of removing and installing the cmem modules:

debian@beaglebone:~$ sudo apt remove ti-cmem-4.15.00.02-modules-`uname -r` --purge

Reading package lists... Done

Building dependency tree

Reading state information... Done

Package 'ti-cmem-4.15.00.02-modules-4.14.108-ti-r131' is not installed, so not removed

The following packages were automatically installed and are no longer required:

  bb-beaglebone-io-installer bb-johnny-five-installer

  ti-c6000-cgt-v8.2.x-installer

Use 'sudo apt autoremove' to remove them.

0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.

debian@beaglebone:~$ sudo apt install ti-cmem-4.16.00.00-modules-`uname -r`

Reading package lists... Done

Building dependency tree

Reading state information... Done

ti-cmem-4.16.00.00-modules-4.14.108-ti-r131 is already the newest version (1stretch).

The following packages were automatically installed and are no longer required:

  bb-beaglebone-io-installer bb-johnny-five-installer

  ti-c6000-cgt-v8.2.x-installer

Use 'sudo apt autoremove' to remove them.

0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.

Error from TIDL classification example:

 

Started /var/lib/cloud9/: classification.tidl.cpp

File path: /var/lib/cloud9/BeagleBone/AI/tidl

File: /var/lib/cloud9/BeagleBone/AI/tidl/classification.tidl.cpp

Arguments: 

File name: classification.tidl.cpp

File extension: cpp

File base name: classification.tidl

Packages: ~.c9/packages

Project path: /var/lib/cloud9/

Project name: projectname

Hostname: localhost

Hostname path: https://undefined/BeagleBone/AI/tidl/classification.tidl.cpp

URL: http://localhost

Port: 8080

IP: 0.0.0.0

Command: BeagleBone/AI/tidl/classification.tidl.cpp

Python: python3

Python path: /usr/lib/python3.7/dist-packages:/usr/local/lib/python3.7/dist-packages

/var/lib/cloud9/common/Makefile:28: MODEL=BeagleBoard.org_BeagleBone_AI,TARGET=classification.tidl,COMMON=/var/lib/cloud9/common

/var/lib/cloud9/common/Makefile:147: GEN_DIR=/tmp/cloud9-examples,CHIP=am57xx,PROC=tidl,PRUN=,PRU_DIR=,EXE=.so

CXX     classification.tidl.cpp

LD      /tmp/cloud9-examples/classification.tidl.o

ti-mct-heap-check -c

sudo mjpg_streamer -i "input_opencv.so -r 640x480 --filter ./classification.tidl.so" -o "output_http.so -p 8080 -w /usr/share/mjpg-streamer/www"

[sudo] password for debian:

MJPG Streamer Version.: 2.0

 i: device........... : default

 i: Desired Resolution: 640 x 480

Unable to stop the stream: Invalid argument

 i: VideoCapture::open() failed

/var/lib/cloud9/common/Makefile:169: recipe for target 'start' failed

make: *** [start] Error 1

rm /tmp/cloud9-examples/classification.tidl.o

Process exited with code: 2

Cheers,

Jon

[Robert Nelson]

The stack switched to ti-c6000-cgt-v8.3

Everything before was based on tidl 1.2.x, we now have the tidl 1.4.x stack..

@Jason Kridner in think needs to update the demos..

[Robert Nelson]

Oh and with r131, there's a new "/dev/video0" device now available,
the guys at TI have a got a way to utilze that internal processor to
do things even faster..

Thus your old usb webcam is no londer /dev/video0...

[maste...@gmail.com]

Hi,

I just came across this post that is relevant to the same problem. I just started working on this Beaglebone AI two days ago. I got the latest os image and updates and upgrades everything. I tried classification.tidl.cpp and I got the same last message that Jon Morss got.  And your latest message was about /dev/video0. On my board I got /dev/video0, /dev/video1 and it does recognize the camera. Do you mean that I can fix it with the change to the default dev for the camera ? And where can I change that? I worked with OpenCV and this VideoCapture::open() failed message seems to indicate a wrong /dev/video index?

Thank you for your support,

Don

[Robert Nelson]

On Thu, Mar 26, 2020 at 10:27 AM <maste...@gmail.com> wrote:
>
> Hi,
> I just came across this post that is relevant to the same problem. I just started working on this Beaglebone AI two days ago. I got the latest os image and updates and upgrades everything. I tried classification.tidl.cpp and I got the same last message that Jon Morss got. And your latest message was about /dev/video0. On my board I got /dev/video0, /dev/video1 and it does recognize the camera. Do you mean that I can fix it with the change to the default dev for the camera ? And where can I change that? I worked with OpenCV and this VideoCapture::open() failed message seems to indicate a wrong /dev/video index?

Please submit a bug to:

https://github.com/beagleboard/cloud9-examples

the classification demo should allow you to specify a video offset..

[jonnymo]

In the GitHub issue that was filed, I noted the following which seems to get the camera active again:

 

Setting '-d /dev/video1' in the common Makefile seemed to do the trick. I now have video from the camera in the TIDL example.

This is what I changed at line 170 in the Makefile at:
/var/lib/cloud9/common$

else ifeq ($(PROC),tidl)
        ti-mct-heap-check -c
        sudo mjpg_streamer -i "input_opencv.so -d /dev/video1 -r 640x480 --filter ./$(TARGET)$(EXE)" -o "output_http.so -p 8080 -w /usr/share/mjpg-streamer/www"
else

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYjyA8yTBWKs-%3DFUoE4kh20XgiQNpheJLfnzHG7_ouqVNA%40mail.gmail.com.

[Jason Kridner]

Any thoughts on making it more generic? Select the highest index?

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAG99bko9Nkz-Jb%2BnBYd-RvhBzGhNHJMkv1%2B7bVcn6hLdaqDcTA%40mail.gmail.com.

--

https://beagleboard.org/about - a 501c3 non-profit educating around open hardware computing

[maste...@gmail.com]

That works! Thank you

I tested out 5 webcams with both dummy.tidl and classificatin.tidl

1. Logitech C920 webcam works

2. VERY Old Creative VF0230 webcam - did not work

3. VERY Old trinket AMD Smarter Choice webcam -images torn up with overread errors-n as n goes randomly from 1 to 8

4. OLD Silicon Motion SM731 webcam works

5. OLD EyeToy webcam  - occasional image tears

check out https://elinux.org/RPi_USB_Webcams for some camera info.

 

I modified the common Makefile and it works. Just for curiosity I modified the local Makefile as well and

I's weird that the LOCAL Makefile is corrupted when I rebooted the board. It came up with a dialog box asking if you want to reload file from disk (that Makefile was modified in previous session and saved  "-r /dev/video1" similar to the common Makefile) . If I clicked "Y" it showed the correct mod -d/dev/video1, and if I clicked "no", it showed -d /dev/

To unsubscribe from this group and stop receiving emails from it, send an email to beagl...@googlegroups.com.

[Jon Morss]

Yeah, I tried the Makefile in the classification example and it did not do anything.  I had to hunt around and found the examples originated the build in the common Makefile so I changed it there and it seems to work.  

I too have a Logitech C920.

Cheers,

Jon

[Jon Morss]

I am not sure and would have to look at it a bit closer.

Perhaps checking whether or not there is something attached to the video device or show a list of possible video devices and prompt the user to select one.  I suppose they would need to know which video device is the active one though.

Cheers,

Jon

To unsubscribe from this group and stop receiving emails from it, send an email to beagl...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYjyA8yTBWKs-%3DFUoE4kh20XgiQNpheJLfnzHG7_ouqVNA%40mail.gmail.com.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email to beagl...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAG99bko9Nkz-Jb%2BnBYd-RvhBzGhNHJMkv1%2B7bVcn6hLdaqDcTA%40mail.gmail.com.

[Kevin de Beer]

Thanks!

This fixed my problems for me.

To unsubscribe from this group and stop receiving emails from it, send an email to beagl...@googlegroups.com.

[Jason Kridner]

On Fri, Mar 27, 2020 at 7:07 AM Jason Kridner <jkri...@beagleboard.org> wrote:

Any thoughts on making it more generic? Select the highest index?

On Thu, Mar 26, 2020 at 10:22 PM jonnymo <jonn...@gmail.com> wrote:

In the GitHub issue that was filed, I noted the following which seems to get the camera active again:

 

Setting '-d /dev/video1' in the common Makefile seemed to do the trick. I now have video from the camera in the TIDL example.

This is what I changed at line 170 in the Makefile at:
/var/lib/cloud9/common$

else ifeq ($(PROC),tidl)
        ti-mct-heap-check -c
        sudo mjpg_streamer -i "input_opencv.so -d /dev/video1 -r 640x480 --filter ./$(TARGET)$(EXE)" -o "output_http.so -p 8080 -w /usr/share/mjpg-streamer/www"
else

Perhaps not the best, but here's my stab at making it continue to work with older kernels:

commit 06c70c2b6a9573a6c72968bce725d30d09cbfe8a Author: Jason Kridner <j...@ti.com> Date: Fri Mar 27 18:13:10 2020 +0000 Remove usage of VPE in running TIDL examples diff --git a/common/Makefile b/common/Makefile index 5a2b886..c1a0982 100644 --- a/common/Makefile +++ b/common/Makefile @@ -167,7 +167,8 @@ ifneq ($(PRU_DIR),) @echo start > $(PRU_DIR)/state else ifeq ($(PROC),tidl) ti-mct-heap-check -c - sudo mjpg_streamer -i "input_opencv.so -r 640x480 --filter ./$(TARGET)$(EXE)" -o "output_http.so -p 8090 -w /usr/share/mjpg-streamer/www" + sudo mjpg_streamer -i "input_opencv.so -r 640x480 -d /dev/$(shell fgrep -v vpe /sys/class/video4linux/video*/name | perl -ne '/\/(video\d+)\/name/ && print $$1') \ + --filter ./$(TARGET)$(EXE)" -o "output_http.so -p 8090 -w /usr/share/mjpg-streamer/www" else ./$(TARGET)$(EXE) endif

As I look at this, I think it would fail if there were just 2 non-vpe interfaces.

There has to be a relatively easy way to pick the first webcam.

[jonnymo]

Jason,

Thanks.

What are you referring to with regards to "making it continue to work with older kernels"?

As far as understand it, the kernel on my BBAI is updated to the latest 4.14 kernel; well at least to 4.14.108-ti-r131 from a few days ago..  

Is this supported on 4.19 or later now?

Cheers,

Jon

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CA%2BT6QPkAeEiaNK-ULejZqiUR6pZuTt2J5egr20BM%2BC7%2BDLfdug%40mail.gmail.com.

[Robert Nelson]

On Fri, Mar 27, 2020 at 1:27 PM jonnymo <jonn...@gmail.com> wrote:

Jason,

Thanks.

What are you referring to with regards to "making it continue to work with older kernels"?

As far as understand it, the kernel on my BBAI is updated to the latest 4.14 kernel; well at least to 4.14.108-ti-r131 from a few days ago..  

Is this supported on 4.19 or later now?

By older kernels Jason means r130 (and lower) of the 4.14.x-ti branch

4.19.x-ti has an OpenCL bug in TI's own SDK on teh x15, so yeah our version has the same exact error.. Something broke..

Regards,

-- 

Robert Nelson
https://rcn-ee.com/

[jonnymo]

Cool, thanks.

Oh, with Jason's change, I get the following error due to the port being set to 8090.

Unable to connect

Firefox can’t establish a connection to the server at 192.168.2.210:8080.

If I change it back to 8080, it seems to work.

Cheers,

Jon

--

For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYhKRpsQF0KpEDqaOuVtOg0qQKztg%2BkeDef8qskx1CqG2g%40mail.gmail.com.

[Dennis Lee Bieber]

On Fri, 27 Mar 2020 11:48:35 -0700, in gmane.comp.hardware.beagleboard.user
jonnymo <jonnymovo-Re5JQE...@public.gmane.org> wrote:

>Cool, thanks.
>
>Oh, with Jason's change, I get the following error due to the port being
>set to 8090.
>Unable to connect
>
>

>*Firefox can’t establish a connection to the server at 192.168.2.210:8080
><http://192.168.2.210:8080>.*
>
>*If I change it back to 8080, it seems to work.*

What happens if you tell /Firefox/ to use port 8090?


--
Dennis L Bieber

[jonnymo]

Where does one define this?  The error occurs when launching MJPG-Streamer from the Cloud9 interface.

Why  change the port to 8090?

Jon

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/c6ms7fhii84iocr8ieoiqett1l1ctc28kd%404ax.com.

[jonnymo]

Okay, you need to change the port in the extras/mjpg-stream.html to get it to work with the way Jason has it set:

debian@beaglebone:/var/lib/cloud9/common$ cat ../extras/mjpg-stream.html
<iframe height="100%" width="100%" id="mjpg-iframe"></iframe>
<script>
/*global location*/
var element = document.getElementById("mjpg-iframe");
element.src = "http://" + location.host + ":8090/?action=stream";
</script>

Jon

[maste...@gmail.com]

You're right Jon - It has to be explicitly specified to override the default to request a web browser connect.

https://www.grc.com/port_8090.htm

On Friday, March 27, 2020 at 4:35:43 PM UTC-4, jonnymo wrote:

Okay, you need to change the port in the extras/mjpg-stream.html to get it to work with the way Jason has it set:

debian@beaglebone:/var/lib/cloud9/common$ cat ../extras/mjpg-stream.html
<iframe height="100%" width="100%" id="mjpg-iframe"></iframe>
<script>
/*global location*/
var element = document.getElementById("mjpg-iframe");
element.src = "http://" + location.host + ":8090/?action=stream";
</script>

Jon

On Fri, Mar 27, 2020 at 1:23 PM jonnymo <jonn...@gmail.com> wrote:

Where does one define this?  The error occurs when launching MJPG-Streamer from the Cloud9 interface.

Why  change the port to 8090?

Jon

On Fri, Mar 27, 2020 at 12:51 PM Dennis Lee Bieber <dennis...@gmail.com> wrote:

On Fri, 27 Mar 2020 11:48:35 -0700, in gmane.comp.hardware.beagleboard.user
jonnymo <jonnymovo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

>Cool, thanks.
>
>Oh, with Jason's change, I get the following error due to the port being
>set to 8090.
>Unable to connect
>
>
>*Firefox can’t establish a connection to the server at 192.168.2.210:8080
><http://192.168.2.210:8080>.*
>
>*If I change it back to 8080, it seems to work.*

        What happens if you tell /Firefox/ to use port 8090?


--
Dennis L Bieber

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email to beagl...@googlegroups.com.