›

New user - Pi Cam performance problems

micservermicserver
in Repetier-Server
Hello, I just started using Repetier SW for my 3D Printer (Sparkcube xl) a few days ago ... wonderful, all is is working great beside the performance of the Pi Cam stream:
The stream in the server window is very slow and seconds  behind the reality ... but if I open an additional browser tap to view the stream directly it shows real time.
(Repetier shows the historie, the other tab shows the reality).

Any idea to optimize the performance in the repetier software?


Gruß Michael

Comments

  • RepetierRepetier
    What resolution/framerate are you using. I have noticed this for bigger data streams so assumed it is a transfer bottleneck.
  • micservermicserver

    For installation I used your detailed (well working!) instaruction on https://www.repetier-server.com/setting-webcam-repetier-server-linux/. No change of parameters.


     

  • RepetierRepetier
    What is if you connect over ethernet? On my pi 2 with pi cam 2 everything is fluent but I know I have good connection.
  • micservermicserver
    Connected via WLAN (good connection choosed) ... but that can't be the problem because the direct stream in a second browser tab runs fluent ... and that's the same connection (as described above).
  • RepetierRepetier
    You did not say if it worked better over ethernet.

    I agree that it would be strange to have it directly from mjpg_streamer fluent and delayed from server. But all server does is resend the stream which is also taking no cpu power. If you run top how much load does the server generate?
  • micservermicserver
    OK, now I had a chance to test over ethernet - Result: fluent stream.

    Furthermore I tried the following:
    - PC with WLAN connection, means Repetier Server connected via WLAN
    - PI (here runs the Repetier Server and the PI CAM) connected via WLAN and additional ethernet cable connection => fluent stream
    - PI connected via WLAN but without additional ethernet cable connection => delayed stream, but direct acces to stream is fluent

    ... hope that helps bringing some light in the problem.

    Why all this effort: in the area were the 3d printer is located I have no ethernet cable connection, only WLAN



  • kissmankissman
    Any news here? I have PiCam v2 and have same problem...
  • RepetierRepetier
    We will check this for next update, also I still do not understand why ethernet connection makes a difference in delay if wlan is fast enough.
  • RandyLRandyL
    I am having a similar issue running 0.80.3 on a Pi 3. I get one or two frames then it fails to update. I tried going with still frames only every 3 seconds with the same result. Very disappointing performance. I love the interface on the touch screen but might have to go back to Octoprint so I can see the video:(
  • RepetierRepetier
    There was a chrome version that would fail on mjpg streams for some reason. Newer versions seem to have fixed that problem. Firefox never had. Just as a test.
  • pscartozzipscartozzi
    Same problems with me. Happened with the last upgrade. Is there a plan to fix this?
  • RepetierRepetier
    Which problem do you have? Delay or abort of transmission?
  • RandyLRandyL
    Update; I had my Pi3 connected via Wifi to a Linksys router. I also run an Apple Airport in the same location. Moving the Pi to the Airports WLAN made a big difference in video playback performance. I did also note, the video stream on the display directly connected the Pi works excellent. Thus I suspect this is all network related. With the print server idle ping times are all over the place:

    $ ping repetierserver.local

    PING repetierserver.local (192.168.1.85): 56 data bytes

    64 bytes from 192.168.1.85: icmp_seq=0 ttl=64 time=42.444 ms

    64 bytes from 192.168.1.85: icmp_seq=1 ttl=64 time=12.707 ms

    64 bytes from 192.168.1.85: icmp_seq=2 ttl=64 time=36.561 ms

    64 bytes from 192.168.1.85: icmp_seq=3 ttl=64 time=12.779 ms

    64 bytes from 192.168.1.85: icmp_seq=4 ttl=64 time=56.585 ms

    64 bytes from 192.168.1.85: icmp_seq=5 ttl=64 time=5.579 ms

    64 bytes from 192.168.1.85: icmp_seq=6 ttl=64 time=81.436 ms

    64 bytes from 192.168.1.85: icmp_seq=7 ttl=64 time=3.577 ms

    64 bytes from 192.168.1.85: icmp_seq=8 ttl=64 time=154.149 ms

    64 bytes from 192.168.1.85: icmp_seq=9 ttl=64 time=35.681 ms

    64 bytes from 192.168.1.85: icmp_seq=10 ttl=64 time=30.800 ms

    64 bytes from 192.168.1.85: icmp_seq=11 ttl=64 time=34.932 ms

    64 bytes from 192.168.1.85: icmp_seq=12 ttl=64 time=7.139 ms

    64 bytes from 192.168.1.85: icmp_seq=13 ttl=64 time=12.971 ms

    64 bytes from 192.168.1.85: icmp_seq=14 ttl=64 time=9.600 ms

    64 bytes from 192.168.1.85: icmp_seq=15 ttl=64 time=46.083 ms

    64 bytes from 192.168.1.85: icmp_seq=16 ttl=64 time=27.163 ms

    64 bytes from 192.168.1.85: icmp_seq=17 ttl=64 time=4.185 ms

    64 bytes from 192.168.1.85: icmp_seq=18 ttl=64 time=38.124 ms

    64 bytes from 192.168.1.85: icmp_seq=19 ttl=64 time=4.663 ms

    64 bytes from 192.168.1.85: icmp_seq=20 ttl=64 time=19.808 ms

    64 bytes from 192.168.1.85: icmp_seq=21 ttl=64 time=3.914 ms

    64 bytes from 192.168.1.85: icmp_seq=22 ttl=64 time=19.588 ms

    ^C

    --- repetierserver.local ping statistics ---

    23 packets transmitted, 23 packets received, 0.0% packet loss

    round-trip min/avg/max/stddev = 3.577/30.455/154.149/32.750 ms

  • kissmankissman
    Srry, but I must switch back to Astro, until the Rpi Cam bug is not fixed. Terrible video quality and non usable with WiFi (even I have opened stream on PC, my printer have problem to print - status is printing, but printer doing nothing. When I close stream - all run perfectly). There is no apparent progress and as written here - https://forum.repetier.com/discussion/3321/is-there-a-release-date-for-80-4-available#latest - it will not be soon. :(
  • RandyLRandyL
    Any word on a patch for this issue? 
  • cbusillocbusillo
    Have you guys tried a USB wifi adapter or wired ethernet?  The Pi3's built in wifi has caused lots of people grief.
  • kissmankissman
    Buy a car and but still walking? Srry, but both concurent products havent any problems with Pi3 WiFi ;)
  • RepetierRepetier
    How is the picam connected to server? Did you say localhost:port for url or wifi address? Later would be bad as server proxies it and should use the faster localhost so it does not pass wifi twice. It is also clear the lan connection solves the issue so it is something network related that slows down to much so you get a delay. So maybe it is using wrong address for internal connection to mjpg streamer.
  • kissmankissman
    Pi cam is directly connected with flex cable. Selected cam from dropdown menu ;) Using localhost in settings for cam.
  • RepetierRepetier
    I think I know now what is going on with the delay. The problem is the proxy approach with slow wifi connection. While the proxy allows nice things like tunneling to external network and still get valid webcam url it adds a copy of the stream. Would you connect directly to mjpg_streamer you would ask only him and get maybe a small delay (also if you throttle enough it gets also bigger). But now we proxy the stream copying 1:1 to the servers port which adds another buffer so delay gets longer until streamer starts dropping frames. Reason it works with ethernet is just the better performance of ethernet. As A test I used ethernet and enabled throtteling in chrome to test. And in deed below a certain transfer rate it added a lag but otherwise still worked. So for next release we will add the ability to drop frames on slow connections to reduce lag to a minimum.
  • kissmankissman
    Sorry, but this problem is not about slow connections I think... I am streaming on Rpi3 over integrated WiFi Full HD videos with audio from my NAS server without any problems.

    Btw. when next release coming? I am waiting for gcode sharing between printers :)
  • RepetierRepetier
    HD Videos have much better compression. Webcams use MJPG streams meaning each frame is a jpg image. With 640x480 a 3MBit connection is already much too slow. If you use HD with pi cam it gets even worse.

    New version comes when issues known are fixed, whenever that will be.
  • kissmankissman
    Just tested with file transfer and I have around 18Mbit/s with my Pi3 with integrated WiFi module. And again, OctoPrint or AstroPrint can stream same settings without any problems...
  • Marco67Marco67
    edited April 2017
    The streaming is good if you point directly to the MJPG streams cam, but inside the Repetier Server interface there's a lot of lag.
    So the problem is inside the web interface not well developed, not in the streaming.
  • RepetierRepetier
    The problem is octprint/atroprint access mjpg streamer directly and it just drops frames to hold position. We stream through server so buffers if not queried fast enough add a delay. That's why next release will add a new system for webcam proxy that can also drop frames to remove delay. I think this will work.
  • kissmankissman
    Ok ;) waiting for next release. I can not wait... :(
Sign In or Register to comment.