Performance issue with JS demos on Android/Linux chromium

Please make sure that this is a bug and also refer to the troubleshooting, FAQ documentation before raising any issues.
System information (Please provide as much relevant information as possible)

Have I written custom code (as opposed to using a stock example script provided in MediaPipe): No
OS Platform and Distribution (e.g., Linux Ubuntu 16.04, Android 11, iOS 14.4): Fedora 34, Android 10
Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device: Sony Xperia
Browser and version (e.g. Google Chrome, Safari) if the issue happens on browser: Chromium 91.0.4472.114
Programming Language and version ( e.g. C++, Python, Java): JavaScript
MediaPipe version:
Bazel version (if compiling from source):
Solution ( e.g. FaceMesh, Pose, Holistic ): Any solution
Android Studio, NDK, SDK versions (if issue is related to building in Android environment):
Xcode & Tulsi version (if issue is related to building for iOS):

Describe the current behavior:
The demo on CodePen is a lot slower on Chromium than on Firefox. On Firefox I can get 30-50 fps, but on chromium it is constantly 7-8 fps no matter the setting. Wasm and WebGL are enabled and I can see WebGL context is allocated from console.
All demo from https://google.github.io/mediapipe/getting_started/javascript.html#ready-to-use-javascript-solutions have the same result. The behavior can also be observed on Android.
Describe the expected behavior:
The js solutions shall have the same performance in chrome/chromium as in firefox.
Standalone code to reproduce the issue:
Provide a reproducible test case that is the bare minimum necessary to replicate the problem. If possible, please share a link to Colab/repo link /any notebook:
Other info / Complete Logs :
Include any logs or source code that would be helpful to
diagnose the problem. If including tracebacks, please include the full
traceback. Large logs and files should be attached
KKgVaPJ:1 Refused to apply style from 'https://cdpn.io/mediapipe/fullpage/demo.css' because its MIME type ('text/html') is not a supported stylesheet MIME type, and strict MIME checking is enabled.
logo_white.png:1 Failed to load resource: the server responded with a status of 404 ()
face_mesh_solution_simd_wasm_bin.js:9
I0710 19:57:28.020000       1 gl_context_webgl.cc:151] Successfully created a WebGL context with major version 3 and handle 3
put_char @ face_mesh_solution_simd_wasm_bin.js:9
I0710 19:57:28.066000       1 gl_context.cc:348] GL version: 3.0 (OpenGL ES 3.0 (WebGL 2.0 (OpenGL ES 3.0 Chromium)))
put_char @ face_mesh_solution_simd_wasm_bin.js:9
W0710 19:57:28.067000       1 gl_context.cc:807] OpenGL error checking is disabled
put_char @ face_mesh_solution_simd_wasm_bin.js:9
KKgVaPJ:1 Refused to apply style from 'https://cdpn.io/mediapipe/fullpage/demo.css' because its MIME type ('text/html') is not a supported stylesheet MIME type, and strict MIME checking is enabled.

This is not typical behavior.  Especially on desktop Chrome, the demos should be running quite quickly, which makes me suspect you might have a Chrome setting/experiment/flag which is interfering.  One thing to double-check would be to navigate to chrome://gpu and ensure that the settings there look good.  And in particular, check that your WebGL2 is hardware accelerated, since software WebGL is extremely slow.

I checked and indeed WebGL2 is hardware accelerated. Actually just now I tried it on a newly installed Chrome on Windows, and I can reproduce the 8 fps behavior. It runs exactly 8 fps no matter the setting, like it is being capped somewhere.
The browser version I tested was:
Google Chrome	92.0.4515.159 (Official Build) (64-bit) (cohort: Stable Installs & Full Version Pins)
Revision	0185b8a19c88c5dfd3e6c0da6686d799e9bc3b52-refs/branch-heads/4515@{#2052}
OS	Windows 10 OS Version 2009 (Build 19043.1165)
JavaScript	V8 <IP_ADDRESS>
User Agent	Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36
Command Line	"C:\Program Files\Google\Chrome\Application\chrome.exe" --flag-switches-begin --flag-switches-end

And here is the chrome://gpu report:
Graphics Feature Status
Canvas: Hardware accelerated
Compositing: Hardware accelerated
Multiple Raster Threads: Enabled
Out-of-process Rasterization: Hardware accelerated
OpenGL: Enabled
Rasterization: Hardware accelerated
Skia Renderer: Enabled
Video Decode: Hardware accelerated
Vulkan: Disabled
WebGL: Hardware accelerated
WebGL2: Hardware accelerated

Driver Bug Workarounds
check_ycbcr_studio_g22_left_p709_for_nv12_support
clear_uniforms_before_first_program_use
decode_encode_srgb_for_generatemipmap
disable_decode_swap_chain
disable_direct_composition_sw_video_overlays
enable_bgra8_overlays_with_yuv_overlay_support
exit_on_context_lost
max_msaa_sample_count_4
msaa_is_slow
disabled_extension_GL_KHR_blend_equation_advanced
disabled_extension_GL_KHR_blend_equation_advanced_coherent
Problems Detected
Some drivers are unable to reset the D3D device in the GPU process sandbox
Applied Workarounds: exit_on_context_lost
Clear uniforms before first program use on all platforms: 124764, 349137
Applied Workarounds: clear_uniforms_before_first_program_use
On Intel GPUs MSAA performance is not acceptable for GPU rasterization: 527565
Applied Workarounds: msaa_is_slow
Disable KHR_blend_equation_advanced until cc shaders are updated: 661715
Applied Workarounds: disable(GL_KHR_blend_equation_advanced), disable(GL_KHR_blend_equation_advanced_coherent)
Decode and Encode before generateMipmap for srgb format textures on Windows: 634519
Applied Workarounds: decode_encode_srgb_for_generatemipmap
Disable DecodeSwapChain for Intel Gen9 and older devices: 1107403
Applied Workarounds: disable_decode_swap_chain
Intel GPUs fail to report BGRA8 overlay support: 1119491
Applied Workarounds: enable_bgra8_overlays_with_yuv_overlay_support
8x MSAA for WebGL contexts is slow on Win Intel: 1145793
Applied Workarounds: max_msaa_sample_count_4
Disable software overlays for Intel GPUs. All Skylake+ devices support hw overlays, older devices peform poorly.: 1192748
Applied Workarounds: disable_direct_composition_sw_video_overlays
Check YCbCr_Studio_G22_Left_P709 color space for NV12 overlay support on Intel: 1103852
Applied Workarounds: check_ycbcr_studio_g22_left_p709_for_nv12_support
ANGLE Features
allow_compressed_formats (Frontend workarounds): Enabled: true
Allow compressed formats
disable_anisotropic_filtering (Frontend workarounds): Disabled
Disable support for anisotropic filtering
disable_program_binary (Frontend features) anglebug:5007: Disabled
Disable support for GL_OES_get_program_binary
disable_program_caching_for_transform_feedback (Frontend workarounds): Disabled
On some GPUs, program binaries don't contain transform feedback varyings
enableCompressingPipelineCacheInThreadPool (Frontend workarounds) anglebug:4722: Disabled: false
Enable compressing pipeline cache in thread pool.
enable_capture_limits (Frontend features) anglebug:5750: Disabled
Set the context limits like frame capturing was enabled
lose_context_on_out_of_memory (Frontend workarounds): Enabled: true
Some users rely on a lost context notification if a GL_OUT_OF_MEMORY error occurs
scalarize_vec_and_mat_constructor_args (Frontend workarounds) 1165751: Disabled: false
Always rewrite vec/mat constructors to be consistent
sync_framebuffer_bindings_on_tex_image (Frontend workarounds): Disabled
On some drivers TexImage sometimes seems to interact with the Framebuffer
add_mock_texture_no_render_target (D3D workarounds) anglebug:2152: Disabled: isIntel && capsVersion < IntelDriverVersion(4815)
On some drivers when rendering with no render target, two bugs lead to incorrect behavior
allow_clear_for_robust_resource_init (D3D workarounds) 941620: Enabled: true
Some drivers corrupt texture data when clearing for robust resource initialization.
allow_translate_uniform_block_to_structured_buffer (D3D workarounds) anglebug:3682: Enabled: IsWin10OrGreater()
There is a slow fxc compile performance issue with dynamic uniform indexing if translating a uniform block with a large array member to cbuffer.
call_clear_twice (D3D workarounds) 655534: Disabled: isIntel && isSkylake && capsVersion < IntelDriverVersion(4771)
Using clear() may not take effect
depth_stencil_blit_extra_copy (D3D workarounds) anglebug:1452: Disabled
Bug in some drivers triggers a TDR when using CopySubresourceRegion from a staging texture to a depth/stencil
disable_b5g6r5_support (D3D workarounds): Disabled: (isIntel && capsVersion < IntelDriverVersion(4539)) || isAMD
Textures with the format DXGI_FORMAT_B5G6R5_UNORM have incorrect data
emulate_isnan_float (D3D workarounds) 650547: Disabled: isIntel && isSkylake && capsVersion < IntelDriverVersion(4542)
Using isnan() on highp float will get wrong answer
emulate_tiny_stencil_textures (D3D workarounds): Disabled: isAMD && !(deviceCaps.featureLevel < D3D_FEATURE_LEVEL_10_1)
1x1 and 2x2 mips of depth/stencil textures aren't sampled correctly
expand_integer_pow_expressions (D3D workarounds): Enabled: true
The HLSL optimizer has a bug with optimizing 'pow' in certain integer-valued expressions
flush_after_ending_transform_feedback (D3D workarounds): Disabled: isNvidia
Some drivers sometimes write out-of-order results to StreamOut buffers when transform feedback is used to repeatedly write to the same buffer positions
force_atomic_value_resolution (D3D workarounds) anglebug:3246: Disabled: isNvidia
On some drivers the return value from RWByteAddressBuffer.InterlockedAdd does not resolve when used in the .yzw components of a RWByteAddressBuffer.Store operation
get_dimensions_ignores_base_level (D3D workarounds): Disabled: isNvidia
Some drivers do not take into account the base level of the texture in the results of the HLSL GetDimensions builtin
mrt_perf_workaround (D3D workarounds): Enabled: true
Some drivers have a bug where they ignore null render targets
pre_add_texel_fetch_offsets (D3D workarounds): Enabled: isIntel
HLSL's function texture.Load returns 0 when the parameter Location is negative, even if the sum of Offset and Location is in range
rewrite_unary_minus_operator (D3D workarounds): Disabled: isIntel && (isBroadwell || isHaswell) && capsVersion < IntelDriverVersion(4624)
Evaluating unary minus operator on integer may get wrong answer in vertex shaders
select_view_in_geometry_shader (D3D workarounds): Disabled: !deviceCaps.supportsVpRtIndexWriteFromVertexShader
The viewport or render target slice will be selected in the geometry shader stage for the ANGLE_multiview extension
set_data_faster_than_image_upload (D3D workarounds): Enabled: !(isIvyBridge || isBroadwell || isHaswell)
Set data faster than image upload
skip_vs_constant_register_zero (D3D workarounds): Disabled: isNvidia
In specific cases the driver doesn't handle constant register zero correctly
use_instanced_point_sprite_emulation (D3D workarounds): Disabled: isFeatureLevel9_3
Some D3D11 renderers do not support geometry shaders for pointsprite emulation
use_system_memory_for_constant_buffers (D3D workarounds) 593024: Enabled: isIntel
Copying from staging storage to constant buffer storage does not work
zero_max_lod (D3D workarounds): Disabled: isFeatureLevel9_3
Missing an option to disable mipmaps on a mipmapped texture

Version Information
Data exported	2021-08-17T02:59:17.204Z
Chrome version	Chrome/92.0.4515.159
Operating system	Windows NT 10.0.19043
Software rendering list URL	https://chromium.googlesource.com/chromium/src/+/0185b8a19c88c5dfd3e6c0da6686d799e9bc3b52/gpu/config/software_rendering_list.json
Driver bug list URL	https://chromium.googlesource.com/chromium/src/+/0185b8a19c88c5dfd3e6c0da6686d799e9bc3b52/gpu/config/gpu_driver_bug_list.json
ANGLE commit id	f11eb737212f
2D graphics backend	Skia/92 d9b8efde6df32e7480c985177118cdd4b72a5b0e
Command Line	"C:\Program Files\Google\Chrome\Application\chrome.exe" --flag-switches-begin --flag-switches-end
Driver Information
Initialization time	114
In-process GPU	false
Passthrough Command Decoder	true
Sandboxed	true
GPU0	VENDOR= 0x8086, DEVICE=0x9bc4, SUBSYS=0x76b41458, REV=5, LUID={0,82756} *ACTIVE*
GPU1	VENDOR= 0x10de, DEVICE=0x1f14, SUBSYS=0x76b41458, REV=161, LUID={0,84008}
GPU2	VENDOR= 0x1414, DEVICE=0x008c, LUID={0,83959}
Optimus	false
AMD switchable	false
Desktop compositing	Aero Glass
Direct composition	true
Supports overlays	true
YUY2 overlay support	SCALING
NV12 overlay support	SCALING
BGRA8 overlay support	SCALING
RGB10A2 overlay support	SOFTWARE
Diagonal Monitor Size of \\.\DISPLAY1	15.5"
Driver D3D12 feature level	D3D 12.1
Driver Vulkan API version	Vulkan API 1.2.0
Driver vendor	Intel
Driver version	<IP_ADDRESS>83
GPU CUDA compute capability major version	0
Pixel shader version	5.0
Vertex shader version	5.0
Max. MSAA samples	16
Machine model name
Machine model version
GL_VENDOR	Google Inc. (Intel)
GL_RENDERER	ANGLE (Intel, Intel(R) UHD Graphics Direct3D11 vs_5_0 ps_5_0, D3D11-<IP_ADDRESS>83)
GL_VERSION	OpenGL ES 2.0.0 (ANGLE 2.1.15713 git hash: f11eb737212f)
GL_EXTENSIONS	GL_ANGLE_base_vertex_base_instance GL_ANGLE_client_arrays GL_ANGLE_depth_texture GL_ANGLE_explicit_context GL_ANGLE_explicit_context_gles1 GL_ANGLE_framebuffer_blit GL_ANGLE_framebuffer_multisample GL_ANGLE_get_serialized_context_string GL_ANGLE_get_tex_level_parameter GL_ANGLE_instanced_arrays GL_ANGLE_lossy_etc_decode GL_ANGLE_memory_size GL_ANGLE_multi_draw GL_ANGLE_multiview_multisample GL_ANGLE_pack_reverse_row_order GL_ANGLE_program_cache_control GL_ANGLE_provoking_vertex GL_ANGLE_request_extension GL_ANGLE_robust_client_memory GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_ANGLE_texture_usage GL_ANGLE_translated_shader_source GL_CHROMIUM_bind_generates_resource GL_CHROMIUM_bind_uniform_location GL_CHROMIUM_color_buffer_float_rgb GL_CHROMIUM_color_buffer_float_rgba GL_CHROMIUM_copy_compressed_texture GL_CHROMIUM_copy_texture GL_CHROMIUM_lose_context GL_CHROMIUM_sync_query GL_EXT_EGL_image_external_wrap_modes GL_EXT_blend_func_extended GL_EXT_blend_minmax GL_EXT_color_buffer_half_float GL_EXT_debug_label GL_EXT_debug_marker GL_EXT_discard_framebuffer GL_EXT_disjoint_timer_query GL_EXT_draw_buffers GL_EXT_draw_elements_base_vertex GL_EXT_float_blend GL_EXT_frag_depth GL_EXT_instanced_arrays GL_EXT_map_buffer_range GL_EXT_multisampled_render_to_texture GL_EXT_occlusion_query_boolean GL_EXT_read_format_bgra GL_EXT_robustness GL_EXT_sRGB GL_EXT_shader_texture_lod GL_EXT_texture_compression_bptc GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_rgtc GL_EXT_texture_compression_s3tc_srgb GL_EXT_texture_filter_anisotropic GL_EXT_texture_format_BGRA8888 GL_EXT_texture_rg GL_EXT_texture_storage GL_EXT_unpack_subimage GL_KHR_debug GL_KHR_parallel_shader_compile GL_NV_EGL_stream_consumer_external GL_NV_fence GL_NV_pack_subimage GL_NV_pixel_buffer_object GL_OES_EGL_image GL_OES_EGL_image_external GL_OES_compressed_EAC_R11_signed_texture GL_OES_compressed_EAC_R11_unsigned_texture GL_OES_compressed_EAC_RG11_signed_texture GL_OES_compressed_EAC_RG11_unsigned_texture GL_OES_compressed_ETC2_RGB8_texture GL_OES_compressed_ETC2_RGBA8_texture GL_OES_compressed_ETC2_punchthroughA_RGBA8_texture GL_OES_compressed_ETC2_punchthroughA_sRGB8_alpha_texture GL_OES_compressed_ETC2_sRGB8_alpha8_texture GL_OES_compressed_ETC2_sRGB8_texture GL_OES_depth24 GL_OES_depth32 GL_OES_draw_elements_base_vertex GL_OES_element_index_uint GL_OES_fbo_render_mipmap GL_OES_get_program_binary GL_OES_mapbuffer GL_OES_packed_depth_stencil GL_OES_rgb8_rgba8 GL_OES_standard_derivatives GL_OES_surfaceless_context GL_OES_texture_border_clamp GL_OES_texture_float GL_OES_texture_float_linear GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_OES_texture_npot GL_OES_texture_stencil8 GL_OES_vertex_array_object GL_WEBGL_video_texture
Disabled Extensions	GL_KHR_blend_equation_advanced GL_KHR_blend_equation_advanced_coherent
Disabled WebGL Extensions
Window system binding vendor	Google Inc. (Intel)
Window system binding version	1.5 (ANGLE 2.1.15713 git hash: f11eb737212f)
Window system binding extensions	EGL_EXT_create_context_robustness EGL_ANGLE_d3d_share_handle_client_buffer EGL_ANGLE_d3d_texture_client_buffer EGL_ANGLE_surface_d3d_texture_2d_share_handle EGL_ANGLE_query_surface_pointer EGL_ANGLE_window_fixed_size EGL_ANGLE_keyed_mutex EGL_ANGLE_surface_orientation EGL_ANGLE_direct_composition EGL_NV_post_sub_buffer EGL_KHR_create_context EGL_KHR_image EGL_KHR_image_base EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_get_all_proc_addresses EGL_KHR_stream EGL_KHR_stream_consumer_gltexture EGL_NV_stream_consumer_gltexture_yuv EGL_ANGLE_flexible_surface_compatibility EGL_ANGLE_stream_producer_d3d_texture EGL_ANGLE_create_context_webgl_compatibility EGL_CHROMIUM_create_context_bind_generates_resource EGL_CHROMIUM_sync_control EGL_EXT_pixel_format_float EGL_KHR_surfaceless_context EGL_ANGLE_display_texture_share_group EGL_ANGLE_display_semaphore_share_group EGL_ANGLE_create_context_client_arrays EGL_ANGLE_program_cache_control EGL_ANGLE_robust_resource_initialization EGL_ANGLE_create_context_extensions_enabled EGL_ANDROID_blob_cache EGL_ANDROID_recordable EGL_ANGLE_image_d3d11_texture EGL_ANGLE_create_context_backwards_compatible EGL_KHR_create_context_no_error EGL_KHR_reusable_sync
Direct rendering version	unknown
Reset notification strategy	0x8252
GPU process crash count	0
gfx::BufferFormats supported for allocation and texturing	R_8: not supported, R_16: not supported, RG_88: not supported, BGR_565: not supported, RGBA_4444: not supported, RGBX_8888: not supported, RGBA_8888: not supported, BGRX_8888: not supported, BGRA_1010102: not supported, RGBA_1010102: not supported, BGRA_8888: not supported, RGBA_F16: not supported, YVU_420: not supported, YUV_420_BIPLANAR: not supported, P010: not supported
Compositor Information
Tile Update Mode	One-copy
Partial Raster	Enabled
GpuMemoryBuffers Status
R_8	Software only
R_16	Software only
RG_88	Software only
BGR_565	Software only
RGBA_4444	Software only
RGBX_8888	GPU_READ, SCANOUT
RGBA_8888	GPU_READ, SCANOUT
BGRX_8888	Software only
BGRA_1010102	Software only
RGBA_1010102	Software only
BGRA_8888	Software only
RGBA_F16	Software only
YVU_420	Software only
YUV_420_BIPLANAR	GPU_READ, SCANOUT, SCANOUT_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE
P010	Software only
Display(s) Information
Info	Display[2528732444] bounds=[0,0 1536x864], workarea=[0,0 1536x824], scale=1.25, rotation=0, panel_rotation=0 internal.
Color space (sRGB/no-alpha)	{primaries_d50_referred: [[0.6484, 0.3281], [0.3216, 0.6048], [0.1609, 0.0657]], transfer:IEC61966_2_1, matrix:RGB, range:FULL}
Buffer format (sRGB/no-alpha)	BGRX_8888
Color space (sRGB/alpha)	{primaries_d50_referred: [[0.6484, 0.3281], [0.3216, 0.6048], [0.1609, 0.0657]], transfer:IEC61966_2_1, matrix:RGB, range:FULL}
Buffer format (sRGB/alpha)	BGRA_8888
Color space (WCG/no-alpha)	{primaries_d50_referred: [[0.6484, 0.3281], [0.3216, 0.6048], [0.1609, 0.0657]], transfer:IEC61966_2_1, matrix:RGB, range:FULL}
Buffer format (WCG/no-alpha)	BGRX_8888
Color space (WCG/alpha)	{primaries_d50_referred: [[0.6484, 0.3281], [0.3216, 0.6048], [0.1609, 0.0657]], transfer:IEC61966_2_1, matrix:RGB, range:FULL}
Buffer format (WCG/alpha)	BGRA_8888
Color space (HDR/no-alpha)	{primaries_d50_referred: [[0.6484, 0.3281], [0.3216, 0.6048], [0.1609, 0.0657]], transfer:IEC61966_2_1, matrix:RGB, range:FULL}
Buffer format (HDR/no-alpha)	BGRX_8888
Color space (HDR/alpha)	{primaries_d50_referred: [[0.6484, 0.3281], [0.3216, 0.6048], [0.1609, 0.0657]], transfer:IEC61966_2_1, matrix:RGB, range:FULL}
Buffer format (HDR/alpha)	BGRA_8888
SDR white level in nits	80
Bits per color component	8
Bits per pixel	24
Refresh Rate in Hz	240
Video Acceleration Information
Decode h264 baseline	64x64 to 4096x4096 pixels
Decode h264 main	64x64 to 4096x4096 pixels
Decode h264 high	64x64 to 4096x4096 pixels
Decode vp9 profile0	64x64 to 8192x8192 pixels
Decode vp9 profile2	64x64 to 8192x8192 pixels
Encode h264 baseline	0x0 to 1920x1088 pixels, and/or 30.000 fps
Encode h264 main	0x0 to 1920x1088 pixels, and/or 30.000 fps
Encode h264 high	0x0 to 1920x1088 pixels, and/or 30.000 fps
Vulkan Information
Device Performance Information
Total Physical Memory (Gb)	31
Total Disk Space (Gb)	100
Hardware Concurrency	16
System Commit Limit (Gb)	31
D3D11 Feature Level	12_1
Has Discrete GPU	yes
Intel GPU Generation	9
Software Rendering	No
Diagnostics
0
b3DAccelerationEnabled	true
b3DAccelerationExists	true
bAGPEnabled	true
bAGPExistenceValid	true
bAGPExists	true
bCanRenderWindow	true
bDDAccelerationEnabled	true
bDriverBeta	false
bDriverDebug	false
bDriverSigned	false
bDriverSignedValid	false
bNoHardware	false
dwBpp	32
dwDDIVersion	12
dwHeight	1080
dwRefreshRate	240
dwWHQLLevel	0
dwWidth	1920
iAdapter	0
lDriverSize	1470024
lMiniVddSize	0
szAGPStatusEnglish	Enabled
szAGPStatusLocalized	Enabled
szChipType	Intel(R) UHD Graphics Family
szD3DStatusEnglish	Enabled
szD3DStatusLocalized	Enabled
szDACType	Internal
szDDIVersionEnglish	12
szDDIVersionLocalized	12
szDDStatusEnglish	Enabled
szDDStatusLocalized	Enabled
szDXVAHDEnglish	Supported
szDXVAModes	ModeMPEG2_A ModeMPEG2_C ModeWMV9_C ModeVC1_C
szDescription	Intel(R) UHD Graphics
szDeviceId	0x9BC4
szDeviceIdentifier	{D7B78E66-D884-11CF-A755-D056BEC2D635}
szDeviceName	\\.\DISPLAY1
szDisplayMemoryEnglish	16446 MB
szDisplayMemoryLocalized	16446 MB
szDisplayModeEnglish	1920 x 1080 (32 bit) (240Hz)
szDisplayModeLocalized	1920 x 1080 (32 bit) (240Hz)
szDriverAssemblyVersion	<IP_ADDRESS>83
szDriverAttributes	Final Retail
szDriverDateEnglish	9/23/2020 8:00:00 PM
szDriverDateLocalized	9/23/2020 20:00:00
szDriverLanguageEnglish	English
szDriverLanguageLocalized	English
szDriverModelEnglish	WDDM 2.7
szDriverModelLocalized	WDDM 2.7
szDriverName	C:\Windows\System32\DriverStore\FileRepository\iigd_dch.inf_amd64_0fb791859acb502e\igdumdim64.dll,C:\Windows\System32\DriverStore\FileRepository\iigd_dch.inf_amd64_0fb791859acb502e\igd10iumd64.dll,C:\Windows\System32\DriverStore\FileRepository\iigd_dch.inf_amd64_0fb791859acb502e\igd10iumd64.dll,C:\Windows\System32\DriverStore\FileRepository\iigd_dch.inf_amd64_0fb791859acb502e\igd12umd64.dll
szDriverNodeStrongName	oem66.inf:5f63e534c17b7cb3:iCML_w10_DS:<IP_ADDRESS>83:PCI\VEN_8086&DEV_9BC4&SUBSYS_76B41458
szDriverSignDate	Unknown
szDriverVersion	27.20.0100.8783
szKeyDeviceID	Enum\PCI\VEN_8086&DEV_9BC4&SUBSYS_76B41458&REV_05
szKeyDeviceKey	\Registry\Machine\System\CurrentControlSet\Control\Video\{8F33215D-F7E0-11EA-B3CE-ECB67C69DE77}\0000
szManufacturer	Intel Corporation
szMiniVdd	unknown
szMiniVddDateEnglish	Unknown
szMiniVddDateLocalized	unknown
szMonitorMaxRes	Unknown
szMonitorName	Generic PnP Monitor
szNotesEnglish	No problems found.
szNotesLocalized	No problems found.
szOverlayEnglish	Supported
szRankOfInstalledDriver	00CF0001
szRegHelpText	Unknown
szRevision	Unknown
szRevisionId	0x0005
szSubSysId	0x76B41458
szTestResultD3D7English	Not run
szTestResultD3D7Localized	Not run
szTestResultD3D8English	Not run
szTestResultD3D8Localized	Not run
szTestResultD3D9English	Not run
szTestResultD3D9Localized	Not run
szTestResultDDEnglish	Not run
szTestResultDDLocalized	Not run
szVdd	unknown
szVendorId	0x8086
1
b3DAccelerationEnabled	true
b3DAccelerationExists	true
bAGPEnabled	true
bAGPExistenceValid	false
bAGPExists	false
bCanRenderWindow	false
bDDAccelerationEnabled	true
bDriverBeta	false
bDriverDebug	false
bDriverSigned	false
bDriverSignedValid	false
bNoHardware	false
dwBpp	0
dwDDIVersion	12
dwHeight	0
dwRefreshRate	0
dwWHQLLevel	0
dwWidth	0
iAdapter	0
lDriverSize	1056272
lMiniVddSize	0
szAGPStatusEnglish	Enabled
szAGPStatusLocalized	Enabled
szChipType	NVIDIA GeForce RTX 2070 with Max-Q Design
szD3DStatusEnglish	Enabled
szD3DStatusLocalized	Enabled
szDACType	Integrated RAMDAC
szDDIVersionEnglish	12
szDDIVersionLocalized	12
szDDStatusEnglish	Enabled
szDDStatusLocalized	Enabled
szDXVAHDEnglish	Unknown
szDXVAModes	Unknown
szDescription	NVIDIA GeForce RTX 2070 with Max-Q Design
szDeviceId	0x1F14
szDeviceIdentifier	Unknown
szDeviceName	Unknown
szDisplayMemoryEnglish	24349 MB
szDisplayMemoryLocalized	24349 MB
szDisplayModeEnglish	Unknown
szDisplayModeLocalized	unknown
szDriverAssemblyVersion	<IP_ADDRESS>41
szDriverAttributes	Final Retail
szDriverDateEnglish	7/11/2021 8:00:00 PM
szDriverDateLocalized	7/11/2021 20:00:00
szDriverLanguageEnglish	English
szDriverLanguageLocalized	English
szDriverModelEnglish	WDDM 2.7
szDriverModelLocalized	WDDM 2.7
szDriverName	C:\Windows\System32\DriverStore\FileRepository\nvgbi.inf_amd64_b73d06c2b1a04fd7\nvldumdx.dll,C:\Windows\System32\DriverStore\FileRepository\nvgbi.inf_amd64_b73d06c2b1a04fd7\nvldumdx.dll,C:\Windows\System32\DriverStore\FileRepository\nvgbi.inf_amd64_b73d06c2b1a04fd7\nvldumdx.dll,C:\Windows\System32\DriverStore\FileRepository\nvgbi.inf_amd64_b73d06c2b1a04fd7\nvldumdx.dll
szDriverNodeStrongName	oem95.inf:0f066de389410f20:Section031:<IP_ADDRESS>41:pci\ven_10de&dev_1f14&subsys_76b41458
szDriverSignDate	Unknown
szDriverVersion	30.00.0014.7141
szKeyDeviceID	Enum\PCI\VEN_10DE&DEV_1F14&SUBSYS_76B41458&REV_A1
szKeyDeviceKey	Unknown
szManufacturer	NVIDIA
szMiniVdd	unknown
szMiniVddDateEnglish	Unknown
szMiniVddDateLocalized	unknown
szMonitorMaxRes	Unknown
szMonitorName	Unknown
szNotesEnglish	No problems found.
szNotesLocalized	No problems found.
szOverlayEnglish	Unknown
szRankOfInstalledDriver	00CF0001
szRegHelpText	Unknown
szRevision	Unknown
szRevisionId	0x00A1
szSubSysId	0x76B41458
szTestResultD3D7English	Not run
szTestResultD3D7Localized	Not run
szTestResultD3D8English	Not run
szTestResultD3D8Localized	Not run
szTestResultD3D9English	Not run
szTestResultD3D9Localized	Not run
szTestResultDDEnglish	Not run
szTestResultDDLocalized	Not run
szVdd	unknown
szVendorId	0x10DE
Log Messages
GpuProcessHost: The info collection GPU process exited normally. Everything is okay.
[10052:8460:0816/225916.306:WARNING:ipc_message_attachment_set.cc(49)] : MessageAttachmentSet destroyed with unconsumed attachments: 0/1
[10052:8460:0816/225916.313:WARNING:ipc_message_attachment_set.cc(49)] : MessageAttachmentSet destroyed with unconsumed attachments: 0/1

Interesting-- what type of computer is this?  I don't see anything off-hand in the chrome://gpu which looks suspicious.  And I'm assuming chrome://flags are set to default values?  (Some of the experimental flags could definitely contribute to this, otherwise).
A few things to try:
(1) Chrome does share a single GPU process across all of its tabs/windows, and does automatically cap framerate according to its measured GPU usage, so background processes could potentially be impacting throughput here.  Have we checked to see if this issue repros if we close all Chrome windows/tabs (and disable extensions) [we can check running processes to ensure we fully killed Chrome], and then open just this demo?
(2) If you take a performance trace of one of the programs while it runs (and do mention which demo you test for this), where does it appear that the slowdown is occurring?  (maybe grab a few screenshots of this?).  You can do this by opening up the Chrome Developer Console while the demo is running, going to the "Performance" tab, and then recording for 5-6 seconds (the first few seconds will not always be accurate).
(3) To see if this is the result of a Chrome version or experiment, two amazing tools are:

https://www.chromium.org/developers/bisect-builds-py
https://source.chromium.org/chromium/chromium/src/+/master:tools/variations/bisect_variations.py
The first of these can determine if specific versions of Chrome are to blame (so we can use this to easily check a wider range of Chrome versions without actually installing lots of Chromes; for example you can see if Chrome Canary would fix the problem, without actually installing Chrome Canary on your computer).  The second takes your current Chrome and turns on and off the different experimental flags to try to find if a particular setting is breaking you.  Maybe start with this second one, since we expect/hope that this strange behavior isn't normal, but more likely is the result of an experiment.

what type of computer is this?

It is a Gigabyte laptop, Intel i7-10875H and nVidia RTX 2070 Max-Q, so hardware shall be more than enough to run. I also tried on a second laptop with MX250, and on that machine the fps ends up being 15, slightly better but still very under preformed.

chrome://flags are set to default values?

Yes.

Have we checked to see if this issue repros if we close all Chrome windows/tabs (and disable extensions) [we can check running processes to ensure we fully killed Chrome], and then open just this demo?

Yes, every time I kill the process and open only a single tab directly to the CodePen page, and I can reproduce every time.

If you take a performance trace of one of the programs while it runs (and do mention which demo you test for this), where does it appear that the slowdown is occurring?

Here are the screenshots for a ~7s tracing from the start of page loading, running the face detection demo. The first one is an overall looking and the second/third one is a close look to two frames:

The observations I have is that there seems to be a long waiting/blocking time after each wasm function call, which I assume shall be the Run() call of the graph. The very short lines in screenshot 2 is magnified in screenshot 4 which seems to be frame rendering, but they seem to run for only several nano-seconds, and then the process just keeps waiting.

To see if this is the result of a Chrome version or experiment, two amazing tools are:

https://www.chromium.org/developers/bisect-builds-py
https://source.chromium.org/chromium/chromium/src/+/master:tools/variations/bisect_variations.py

I tried both, and turns out the problem is universal. For field-trails, I ran bisect_variations.py on Linux/chromium 92.0.4515.131 since the script somehow throw [Error 87] on Windows. Since there is actually only one parameter in Command-line variations, I think field trails are not the problem:
[user@localhost variations]$ python2 bisect_variations.py --input-file="/run/media/user/Data/test/variations_cmd.txt" --browser=chromium --url="https://codepen.io/mediapipe/full/dyOzvZM"
Run Chrome with variations file /run/media/user/Data/test/variations_cmd.txt
Can we reproduce with given variations file [(y)es/(n)o/(r)etry/(s)tdout/(q)uit]: y
Bisecting succeeded: --force-fieldtrials=UkmSamplingRate/Sampled_NoSeed_Other/ --enable-features=UkmSamplingRate<UkmSamplingRate --force-fieldtrial-params=UkmSamplingRate.Sampled_NoSeed_Other:_default_sampling/1

For versions, I ran the script on Windows and gave it a range from 782793 (85.0.4183.121) to 912534 (Canary, 95.0.4611.0). I also manually verified M85 and Canary. Turns out every version has this problem, except for M85 which failed to run the demo at all. The log is as follows:
F:\bisect_builds>python tools/bisect-builds.py -a win64 -g 912534 -b 782793 --use-local-cache -- --no-first-run
Scanning from 912534 to 782793 (129741 revisions).
Downloading list of known revisions...
Loaded revisions<PHONE_NUMBER>79 from F:\bisect_builds\tools\.bisect-builds-cache.json
Downloading revision 839301...
Received 165231949 of 165231949 bytes, 100.00%
Bisecting range [782797 (bad), 912532 (good)], roughly 14 steps left.
Trying revision 839301...
Revision 839301 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b
Downloading revision 875714...
Received 176357479 of 176357479 bytes, 100.00%
Bisecting range [839301 (bad), 912532 (good)], roughly 13 steps left.
Trying revision 875714...
Revision 875714 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b
Downloading revision 894172...
Received 179809582 of 179809582 bytes, 100.00%
Bisecting range [875714 (bad), 912532 (good)], roughly 12 steps left.
Trying revision 894172...
Revision 894172 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b
Downloading revision 902856...
Received 180720286 of 180720286 bytes, 100.00%
Bisecting range [894172 (bad), 912532 (good)], roughly 11 steps left.
Trying revision 902856...
Revision 902856 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b
Downloading revision 907469...
Received 181162294 of 181162294 bytes, 100.00%
Bisecting range [902856 (bad), 912532 (good)], roughly 10 steps left.
Trying revision 907469...
Revision 907469 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b
Downloading revision 909739...
Received 182359155 of 182359155 bytes, 100.00%
Bisecting range [907469 (bad), 912532 (good)], roughly 9 steps left.
Trying revision 909739...
Revision 909739 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b
Downloading revision 911544...
Received 181196039 of 181196039 bytes, 100.00%
Bisecting range [909739 (bad), 912532 (good)], roughly 8 steps left.
Trying revision 911544...
Revision 911544 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b
Downloading revision 912005...
Received 181308716 of 181308716 bytes, 100.00%
Bisecting range [911544 (bad), 912532 (good)], roughly 7 steps left.
Trying revision 912005...
Revision 912005 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b
Downloading revision 912045...
Received 181305782 of 181305782 bytes, 100.00%
Bisecting range [912005 (bad), 912532 (good)], roughly 6 steps left.
Trying revision 912045...
Revision 912045 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b
Downloading revision 912261...
Received 181358561 of 181358561 bytes, 100.00%
Bisecting range [912045 (bad), 912532 (good)], roughly 5 steps left.
Trying revision 912261...
Revision 912261 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b
Downloading revision 912465...
Received 181409940 of 181409940 bytes, 100.00%
Bisecting range [912261 (bad), 912532 (good)], roughly 4 steps left.
Trying revision 912465...
Revision 912465 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b
Downloading revision 912508...
Received 181415660 of 181415660 bytes, 100.00%
Bisecting range [912465 (bad), 912532 (good)], roughly 3 steps left.
Trying revision 912508...
Revision 912508 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b
Downloading revision 912517...
Received 181415166 of 181415166 bytes, 100.00%
Bisecting range [912508 (bad), 912532 (good)], roughly 2 steps left.
Trying revision 912517...
Revision 912517 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b
Downloading revision 912523...
Received 181414162 of 181414162 bytes, 100.00%
Bisecting range [912517 (bad), 912532 (good)], roughly 2 steps left.
Trying revision 912523...
Revision 912523 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b
You are probably looking for a change made after 912523 (known bad), but no later than 912532 (first known good).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/9a59481955730df5897785bd7bf36d96d8d3dbb8..2743430c1810b962229f9b20d52c1dc30e71d4e6

Thank you for the thorough report!  That behavior is quite odd indeed-- especially the performance trace.  It shows that the actual MediaPipe processing time is extremely low (~5ms/frame), so there are no unexpected CPU-side costs to speak of.
Our entire run loop is actually finished by the end of that thin call stack, so we don't make any explicit calls past that point-- however, GPU processing usually continues past that point.  Seeing so little CPU processing but such long wait times between when video frames are passed in would normally make me suspect an over-busy GPU process, but the trace makes it look like our GPU processing is also relatively low as well-- this makes me wonder if something strange is happening to the video playback, or else maybe something is bogging down the GPU in some strange way (perhaps a subframe or background process in the CodePen site?).  To narrow it down even further, here are some ideas:
(1)  While the demo is running, can we check the Chrome CPU and GPU utilization?  This seems like a good quick check to try to determine if there's some large over-utilization occurring from somewhere.
(2) To try to confirm the issue really is GPU-specific, we can switch our pipeline to a less efficient CPU-based one by adding       options.useCpuInference = true; right beneath const options = x as mpFaceDetection.Options; in the CodePen JS code.  Then we can see if there still exists a large performance delta between Firefox and Chrome.  This won't get rid of all our GPU processing, but it switches the bulk of our operations from GPU to CPU, leaving only light rendering.
(3)  We can try moving the code out of the CodePen site and into a standalone demo.  We can just copy all of the code/settings directly into a local folder and then use python3 -m http.server to stage locally.  This can determine whether or not CodePen plays a part in the issue.
(4)  We can grab a full Chrome trace (chrome://tracing), for Javascript+Rendering.  These have a lot more details on the system as a whole, although I must profess I'm not an expert yet at reading through them.

While the demo is running, can we check the Chrome CPU and GPU utilization?

Both are very low, <10%.

we can switch our pipeline to a less efficient CPU-based one by adding options.useCpuInference = true;

After experimenting a little, it seems the problem happens with both CPU and GPU version, so probably GPU is not the only problem. For the CPU version, Firefox will hang so I cannot get an fps from it, but in chromium it gave me the same 8 fps as running on GPU.

We can try moving the code out of the CodePen site and into a standalone demo.

I tried it and that didn't help. I ran the page using python server as mentioned, and it gave me the same 8 fps.
I will try grabbing a full trace later, but here are some other discoveries:

I tried disabling canvas rendering by commenting out the whole onResults(results) function, but that didn't change anything.
I tried to record Memory usage alongside JS frames in Performance tab for a much longer period of time (90s), and I believe I am looking at a pattern of memory leak. Here are the screenshots:

A closer look gives me this:

Notice the zigzag pattern along the slopes. I am not sure whether it is related to the slow down, but probably this can be a hint.
Also notice the red bars at the top below the ms notations. They actually says something like 117.7ms ~ 8 fps Dropped Frame, and the green bar between them says 8.1ms ~ 123ms Frame. I am not sure what exactly it means but it looks like GPU is limited when not running graphs, which I found strange (I suppose it is not related to power management because I do not think GPU can switch power states that often).

I think that sort of memory graph is fairly normal, since a lot of freed memory will still be left lying around until JS needs it and decides to garbage collect (the large drops in the graph).  It's only if those low points in the memory graph rise over time (so the memory usage increases from one "drop" to the next) that a leak is present.  If you use the Developer console to force garbage collection right before recording a memory reading, that can help control for this behavior.  Also, any leaks in the C++ WebAssembly memory have a rather unique behavior of their own-- you'll see sudden large "jumps" in memory between long breaks, owing to how the C++ memory heap is grown.
The fact that none of our previous tests affected the video playback rate is very telling.  Usually issues like this are due to GPU overutilization, but I think perhaps something very different is happening for you (since even with CPU ML inference the issue persists, and there's no sign of GPU or CPU strain).  So I think we can systematically remove higher-level pipeline components to hopefully narrow it down a little more-- basically taking the canvas rendering disabling experiment you tried and pushing that further.  Specifically:

Does the issue persist if we don't even send frames into MediaPipe FaceDetection?  (see if FaceDetection processing affects issue)
If so, then does the issue persist if we don't even construct FaceDetection? (see if WebAssembly/MP API at all affects issue)
If so, then does the issue persist if we use an alternate method to play the video stream?  (see if our helper Camera API affects issue)

And since we seem to be honing in on the video playback itself (possibly even a Chromium issue, as you posited, rather than a MediaPipe one), just to eliminate a few other possibly related variables, are you using a webcam for testing?  If so, what kind?  If not, what are you using for the video stream?  (uploaded video duration and resolution?).  And one other side-question: are you using an external monitor, and if so, does disconnecting that have an effect?

I should clearify a little that I made a small mistake in my previous comment, that I didn't remove faceDetection.onResults(onResults); but rather commented out the canvasCtx drawings inside that function, since removing the onResults function will prevent fpsControl.tick() from being called.

Does the issue persist if we don't even send frames into MediaPipe FaceDetection?

I commented out await faceDetection.send({image: input});, and that caused onResults() to stop being called too, so I did two experiments:

I first tried switching to using requestAnimationFrame to measure fps on canvas, and fps on canvas itself turns out to be 60.

I went further on this and tested running the same measuring function when FaceDetection is active, and it turns out the canvas itself is still at 60fps, only the onResults function is called at a rate of 10 fps (I am testing on my second laptop). The JS code snippet I modified is here: https://gist.github.com/AzureRain1/c4fea9fd2eb16b38b22229ea0b3d09cc

The white number on the top left corner of canvas is calculated based on how often onResults() is called, and it is equal to the result from fpsControl.tick(). The bottom number is calculated from requestAnimationFrame. The fps counter on the left top side of the whole page is from the rendering tab of Developer Tools.

I then went ahead and put fpsControl.tick(); right after async (input: controls.InputImage, size: controls.Rectangle) => { and again commented out await faceDetection.send({image: input});. In this setting the fps counter still gave me a reading of 10.

If so, then does the issue persist if we don't even construct FaceDetection?

For this I commented out everything related to faceDetection, as well as put fpsControl.tick(); right after async (input: controls.InputImage, size: controls.Rectangle) => { like the previous setting. The fps counter still gave me a reading of 10.

If so, then does the issue persist if we use an alternate method to play the video stream?

For this, I removed the controls part completely and instead using
if (navigator.mediaDevices.getUserMedia) {
  navigator.mediaDevices.getUserMedia({ video: true })
    .then(function (stream) {
      window.stream = stream;
      videoElement.srcObject = stream;
      videoElement.play();
    })
    .catch(function (err0r) {
      console.log("Something went wrong!");
    });
}

and draw on canvs using canvasCtx.drawImage(videoElement, 0, 0, 1280, 720);. The fps measured by requestAnimationFrame in this case is 60 fps.
So it seems the problem is related to the controls somehow? It seems to make sense if the video is fed with a low fps, and that can explain the long idle times between calls. However I am not sure why the low video frame rate can be accross platform/accross devices.

are you using a webcam for testing? If so, what kind? If not, what are you using for the video stream? (uploaded video duration and resolution?). And one other side-question: are you using an external monitor, and if so, does disconnecting that have an effect?

None of the tests involved an external monitor. I made a table about the devices I have tested, so things are easier to understand:

Device
Platform/OS
CPU
GPU
Camera
Chrome/Chromium
Version
FPS

Gigabyte Laptop
Windows 10 Home
Intel i7-10875H
nVIDIA RTX 2070 Max-Q
Laptop Embedded
Chrome (Official Build)
92.0.4515.131
8

Acer Laptop
Fedora 34, KDE/X11
Intel i7-8550U
nVIDIA MX250
Laptop Embedded
Chromium (Fedora RPM)
91.0.4472.164
10

Sony XZ1 Compact
Android 10 (AOSP)
Qualcomm Snapdragon 835
Adreno 540
Phone Front Camera
Chromium (Developer Build)
92.0.4515.131
12~14

Samsung Galaxy S10+
Android 11 (OEM/Samsung One UI)
Exynos 9820
Mali-G76 MP12
Phone Back Camera
Chrome (Official Build)
92.0.4515.131
~17

The Android numbers aren't too far from what I'd expect, but the Desktop numbers are definitely strangely low.  However, from the experiments it sounds like the MediaPipe JS APIs are actually functioning perfectly there (and are very fast), but the video playback is where the issue is occurring.  The main difference between the final snippet you posted and the code in controls is that we have an additional check so that we don't process the same video frame twice.  Specifically, whenever we process a frame, we store video.currentTime, and if it matches the last-seen value, we do not process.
I suspect that if you add that check in as well, then you'll see the 10fps capping even with your final snippet, confirming that this is in fact a Chromium bug.  Then the only question would be whether the issue is with video.currentTime not updating properly (so video playback is actually at 60fps even though frame updates are not being reported), or whether the video stream itself really is at 10fps-- the apparent smoothness of the video for you when it reports that it is playing at 60fps should be the determining factor there. (Many built-in webcams are just always capped at 30fps, so I'd expect you'd be visually comparing between 30fps and 10fps; it's the Chromium browser max refresh rate which is 60fps).
As one other side-test, the experimental "requestVideoFrameCallback" call was created so that users didn't have to try to manually control for video frame updates from the browser.  If that call exists for you, you could try using that as a replacement for requestAnimationFrame and see if that helps?

I added the currentTime check to the requestAnimationFrame calls and indeed the fps is capped there too. However I happened to figure out that the low fps is caused by hardware, namely when the camera is in low-light conditions, then it will cap its output to a lower fps of 10, and only in bright conditions it will output a full 30 fps. I then went ahead and tested this theory on unmodified CodePen examples and indeed with bright light conditions they now run at full 30 fps, on both of my laptops.
So to summarize, it was the hardware outputting low fps video streams the whole time, starving the downstream processing. There appears to be nothing wrong with the JS API.
I think you can considered this solved now.

Ahhh; I've run into some slight variations in FPS from changes in lighting conditions, but never anything near that drastic before.  Good to know!  Closing as resolved.


Adding support for tracking aggregated metrics.

Hi @akurmi, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!

It looks like you're working at Microsoft (akurmi). If you're full-time, we DON'T require a contribution license agreement.

If you are a vendor, DO please sign the electronic contribution license agreement. It will take 2 minutes and there's no faxing! https://cla.azure.com.

TTYL, AZPRBOT;

@akurmi out of curiosity, is there a reason to use EventProvider and not EventSource here?

Ok, check it in.


Update to use new attribute API and pyright

Closing #50

https://github.com/DiamondLightSource/fastcs-eiger/blob/3f397066861cc1a40b4baff01d01b5e47db7b39e/src/fastcs_eiger/eiger_controller.py#L378
I'll need to fix this too


venv not detected when created with Anaconda base environment

Environment data

VS Code version: 1.36.1
Extension version: 2019.8.29288
OS and version: Windows 10 1803 b17134.885
Python version: Python 3.7.4, Anaconda 4.7.11
Type of virtual environment used: venv, conda
Relevant/affected Python packages and their versions: N/A
Jedi or Language Server? (i.e. what is "python.jediEnabled" set to; more info #3977): false

Expected behaviour
No matter which anaconda environment is active after running python -m venv venv, the extension will detect the new python environment in the folder venv.
Actual behaviour
The extension does not detect venvs created from the base environment, but will if created from another environment.
Steps to reproduce:

Install anaconda, then run conda init from the anaconda PowerShell prompt and restart. This adds the following to your profile:

(& "C:\Users\GGallo\AppData\Local\Continuum\anaconda3\Scripts\conda.exe" "shell.powershell" "hook") | Out-String | Invoke-Expression

In VS Code, create a clean directory and cd inside. Make this the base of a new workspace. The rest happens on an integrated terminal.
conda activate to make sure you have the base environment.
python -m venv venv. Check for new interpreters, the new venv does not appear.
rm -Recurse -Force .\venv
conda create --name test python
conda activate test
python -m venv venv. Check for new interpreters, there it is!

Sorry I can't GIF this whole thing, not an option right now.
You can even conda remove --name test --all and the venv will continue operating as normal.

Thanks for reporting this issue and providing detailed steps.

@ggallo Unfortunately I'm unable to replicate this at my end.
Please could you:

Check if there are any errors in the console window (go to Help->Toggle Developer Tools).

In order. Note that none of these errors happen when I switch to other interpreters.
(node:19396) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.

Error Python Extension: 2019-08-16 14:57:01: Detection of Python Interpreter for Command py and args -2 failed as file  does not exist

Error Python Extension: 2019-08-16 14:57:01: Failed to download and store experiments, Class name = S, completed in 668ms, , Return Value: undefined { [Error: unable to get local issuer certificate	at TLSSocket.onConnectSecure (_tls_wrap.js:1049:34)	at TLSSocket.emit (events.js:182:13)	at TLSSocket._finishInit (_tls_wrap.js:631:8)] code: 'UNABLE_TO_GET_ISSUER_CERT_LOCALLY' }

Error Python Extension: 2019-08-16 14:57:01: Failed to initialize experiments, Class name = S, completed in 668ms, , Return Value: undefined { [Error: unable to get local issuer certificate	at TLSSocket.onConnectSecure (_tls_wrap.js:1049:34)	at TLSSocket.emit (events.js:182:13)	at TLSSocket._finishInit (_tls_wrap.js:631:8)] code: 'UNABLE_TO_GET_ISSUER_CERT_LOCALLY' }

Error Python Extension: 2019-08-16 14:57:01: Failed to parse interpreter information for 'c:\Users\GGallo\source\repos\remote_ftp_sync\venv\Scripts\python.exe' with JSON  [SyntaxError: Unexpected end of JSON input	at JSON.parse (<anonymous>)	at p.getInterpreterInformation (C:\Users\GGallo\.vscode\extensions\ms-python.python-2019.8.30787\out\client\extension.js:75:290659)]

Error Python Extension: 2019-08-16 14:57:01: Unable to determine shell using VS Code API. [Error: [ms-python.python]: Proposed API is only available when running out of dev or with the following command line switch: --enable-proposed-api ms-python.python	at a (c:\Program Files\Microsoft VS Code\resources\app\out\vs\workbench\services\extensions\node\extensionHostProcess.js:472:367)	at Object.t.checkProposedApiEnabled (c:\Program Files\Microsoft VS Code\resources\app\out\vs\workbench\services\extensions\node\extensionHostProcess.js:473:343)	at Object.get shell [as shell] (c:\Program Files\Microsoft VS Code\resources\app\out\vs\workbench\services\extensions\node\extensionHostProcess.js:726:799)	at p.get shell [as shell] (C:\Users\GGallo\.vscode\extensions\ms-python.python-2019.8.30787\out\client\extension.js:75:305726)	at u.identify (C:\Users\GGallo\.vscode\extensions\ms-python.python-2019.8.30787\out\client\extension.js:75:445660)	at p.identifyTerminalShell (C:\Users\GGallo\.vscode\extensions\ms-python.python-2019.8.30787\out\client\extension.js:75:440845)	at m.identifyTerminalShell (C:\Users\GGallo\.vscode\extensions\ms-python.python-2019.8.30787\out\client\extension.js:75:437149)	at de (C:\Users\GGallo\.vscode\extensions\ms-python.python-2019.8.30787\out\client\extension.js:9:113358)	at C:\Users\GGallo\.vscode\extensions\ms-python.python-2019.8.30787\out\client\extension.js:9:117102]

Error Python Extension: 2019-08-16 14:57:02: Failed to parse interpreter information for 'c:\Users\GGallo\source\repos\remote_ftp_sync\venv\Scripts\python.exe' with JSON  [SyntaxError: Unexpected end of JSON input	at JSON.parse (<anonymous>)	at p.getInterpreterInformation (C:\Users\GGallo\.vscode\extensions\ms-python.python-2019.8.30787\out\client\extension.js:75:290659)]

Just an update, I'm not sure what happened since the last comment being that I haven't changed any of my conda environments, but now I cannot get any venv created through Anaconda to appear in in the environment. I think this screenshot summarizes in one shot: a clear venv folder with python executable located under the root of the current workspace, but is not available in the interpreter window.

@ggallo
Curious about your use of conda and venv. Conda has its own mechanism to create virtual environments (conda environments). Is creating venvs using conda officially supported? It feels wrong to use conda in such a manner, its not technically designed for such use cases.
@brettcannon /cc
@ericsnowcurrently I remember you looked into a similar issue in the past.

@DonJayamanne fair enough, to be honest I would jettison Anaconda if it weren't the only way to use python in my current setup, I like venv over conda env to make deployments easier. I'll defer to experts on the matter but FWIW I have not (yet) come across documentation explicitly discouraging the use of venv.

@ggallo it is an atypical setup because you need to have the conda environment activated in order for things to work appropriately.
But in your screenshot you have source/ open, but your virtual environment is in source/clean/venv. We only automatically detect at the top of your open folder, so we would never notice that virtual environment. I would either create directly under source/ or set "python.venvPath" to point to clean to notice that venv/ folder.

Thanks for figuring that out @brettcannon


Support subword cursor navigation

Continuation of #5806 in preparation to merge.
@dsandstrom I've changed the regular expression a little bit so we don't need a hack to move the cursor to the beginning of the buffer. It also required a change to text-buffer to allow regex matches at the beginning of the scan range.
One of the tests changed slightly in behavior, but it's still seeming reasonable and things are working intuitively in all my tests.
I'm considering adding the following emacs-style bindings for those of us who are averse to the arrow keys:

ctrl-alt-f Move subword forward
ctrl-alt-b Move subword backward
ctrl-alt-d Delete subword forward
ctrl-alt-h Delete subword backward
ctrl-alt-shift-F Select subword forward
ctrl-alt-shift-B Select subword backward

ctrl-alt-f Move subword forward

Are these the defaults in any other editor? They are strange on a qwerty keyboard because the f key is left of the b key. If there are default bindings, my vote would be for arrow key chord defaults.

@benogle We already have very similar character and word movement bindings (derived from Emacs). I would definitely leave the arrow bindings, but I think it makes sense to provide Emacs equivalents since we already have Emacs word and character bindings.

I would definitely leave the arrow bindings

Noted

Awesome, thanks.  I have not tried building this version, but does subword navigation work on mini editors?  If not, the keymaps should be under the :not([mini]) selectors.
Btw, congrats on 1.0.

:tada: glad to have this in

I have not tried building this version, but does subword navigation work on mini editors? If not, the keymaps should be under the :not([mini]) selectors.

I just confirmed that the bindings and commands work in mini-editors, as I think they should.


Integer Overflow problem in stake reward calculation

This was discovered in the Ember coin source code, I found the same circumstances in the code for PoS coin, just moving it forward to this coin so people don't get up in arms:
https://github.com/posdevv/pos/blob/f566cce9bb952fc720a232c5e9580dd8cdc2c14b/src/main.cpp#L1020
This is the simple fix (otherwise after 38.81million nCoinAge overflow and incorrect calculation occurs). In main.cpp (comment out old line and replace with nCoinAge at the end) :+1:
//  int64_t nSubsidy = nCoinAge * COIN_YEAR_REWARD * 33 / (365 * 33 + 8);
    int64_t nSubsidy = COIN_YEAR_REWARD * 33 / (365 * 33 + 8) * nCoinAge;

To avoid the loss of accuracy and force floating point, simply add .0 to one of the numbers instead (nSubsidy is obviously still an integer):
int64_t nSubsidy = nCoinAge * COIN_YEAR_REWARD * 33.0 / (365 * 33 + 8);

I'm pretty sure this was only found to be a problem in Ember due to the stupid high total supply that keeps growing exponentially. Still might be a good idea to patch this in any event.


Add the ability to set a minimum label width on containers

This PR proposes to add a new minimumLabelWidth parameter to Container instances.
I've found in my own preference panes, that the automatically calculated width for labels can be a bit tight, especially for wider panes.

Thanks :)


Any way to port for Xamarin Forms/MUAI?

Any easy way to port for Xamarn Form/MUAI

I don't know much about those UX frameworks (Xamarin Forms and .NET MAUI). Below are a few links which might be helpful in conversion:

https://www.syncfusion.com/blogs/post/guest-blog-from-winforms-to-xamarin-one-developer-s-journey.aspx
https://learn.microsoft.com/en-us/answers/questions/683367/migrate-from-winforms-to-net-maui.html
https://learn.microsoft.com/en-us/answers/questions/295634/from-winforms-to-xamarin-maui-for-windows-mac-linu.html
https://stackoverflow.com/questions/40251492/how-to-translate-windows-form-app-to-work-in-xamarin


Output is "stuck" after ~ 13h14m

Which version are you using?
v0.16.1 / v0.15.5
Which operating system are you using?

OS

[x] Linux
[ ] Windows
[ ] macOS

Architecture

[x] amd64
[ ] arm64
[ ] arm7
[ ] arm6

Describe the issue
Hi @aler9,
First of all, thanks for your work ; it really help me to quickly setup lot of rtsp server.
We (myself and my co-worker @iksela) encounter some strange issue ; let me explain with some context.
We consume a lot of live streams. They came in two categories :

"pure" UDP ; mpegts or h264
SRT ; h264

For both, we use ffmpeg (latest stable version : 4.4), to feed rtsp-simple-server; something like ffmpeg -i source -f rtsp rtsp://<IP_ADDRESS>:8554/stream_name. There is no encoding/decoding, just a "passthrough".
For SRT streams, we use first srt-live-transmit to feed ffmpeg.
That's all for the input.
For the output, we consume the rtsp steam with ffmpeg, and we basically extract all frames of the feed.
Every 13 hours and 14/15 minutes (13h14m50s), the ouput rtsp stream is "stuck"; ffmpeg doesn't crash but it doesn't extract frames anymore.
We can detect the issue automatically so we reboot our "rtsp consumers" and it works again ; there is a delay of 30s between "omg there is no more frame extracted" and "reboot yourself" ; so it more like 13h14m20s than 13h14m50s.
First, we found this particual issue: “Non-monotonous DTS in output stream” every 13 hours 14 minutes ; enabling or disabled correct_ts_overflow doesn't solve the problem. Moreover, the overflow seems to have been fixed in ffmpeg >= 4.4 with commit https://github.com/FFmpeg/FFmpeg/commit/d82ee907d6caafbc1212c4b63ecac2dcd30f23b0.
We looked at #144 #197 and #233 too since it might be related to the above issue.
We dropped rtsp-simple-server and go back to a non-flexible solution with only ffmpeg; the problem doesn't happens.
So we think the issue could come from rtsp-simple-server (or aler9/gortsplib / pion/rtp / pion/rtcp ?) ;
it's hard to test because it need to be running during a long period.
Additionally, we are running everything in Docker / Kubernetes environment.
We use 1 rtsp-simple-server for 1 stream (and not all stream on the same rtsp-simple-server) ; we use directly the image Docker image you provide without modifications. The feeders and the consumers are runnings in separate containers (under alpine linux and debian ; it depends)
1 video source [-> srt-live-transmit] -> ffmpeg ouput rtsp -> rtsp-simple-server -> at least 2 ffmpeg consumers

As example, below the output of ffmpeg when it works without problems (this instance is running since 300 hours)
[...]
frame=27322286 fps= 24 q=2.0 size=368716871kB time=303:34:50.96 bitrate=2763.8kbits/s dup=5 drop=0 speed=0.958x
frame=27322301 fps= 24 q=2.0 size=368717036kB time=303:34:51.56 bitrate=2763.8kbits/s dup=5 drop=0 speed=0.958x
frame=27322319 fps= 24 q=2.0 size=368717238kB time=303:34:52.28 bitrate=2763.8kbits/s dup=5 drop=0 speed=0.958x
rtsp://the.ip.address.of.one.rtsp.server:8554/stream_name: corrupt decoded frame in stream 0

    Last message repeated 2 times

frame=27322332 fps= 24 q=2.0 size=368717385kB time=303:34:52.80 bitrate=2763.8kbits/s dup=5 drop=0 speed=0.958x
frame=27322348 fps= 24 q=2.0 size=368717557kB time=303:34:53.44 bitrate=2763.8kbits/s dup=5 drop=0 speed=0.958x
frame=27322364 fps= 24 q=2.0 size=368717728kB time=303:34:54.08 bitrate=2763.8kbits/s dup=5 drop=0 speed=0.958x
rtsp://the.ip.address.of.one.rtsp.server:8554/stream_name: corrupt decoded frame in stream 0

frame=27322379 fps= 24 q=2.0 size=368717889kB time=303:34:54.68 bitrate=2763.8kbits/s dup=5 drop=0 speed=0.958x
frame=27322394 fps= 24 q=2.0 size=368718053kB time=303:34:55.28 bitrate=2763.8kbits/s dup=5 drop=0 speed=0.958x
frame=27322411 fps= 24 q=2.0 size=368718241kB time=303:34:55.96 bitrate=2763.8kbits/s dup=5 drop=0 speed=0.958x
rtsp://the.ip.address.of.one.rtsp.server:8554/stream_name: corrupt decoded frame in stream 0

frame=27322425 fps= 24 q=2.0 size=368718395kB time=303:34:56.52 bitrate=2763.8kbits/s dup=5 drop=0 speed=0.958x
frame=27322441 fps= 24 q=2.0 size=368718569kB time=303:34:57.16 bitrate=2763.8kbits/s dup=5 drop=0 speed=0.958x
frame=27322456 fps= 24 q=2.0 size=368718728kB time=303:34:57.76 bitrate=2763.8kbits/s dup=5 drop=0 speed=0.958x
frame=27322472 fps= 24 q=2.0 size=368718899kB time=303:34:58.40 bitrate=2763.8kbits/s dup=5 drop=0 speed=0.958x
frame=27322488 fps= 24 q=2.0 size=368719077kB time=303:34:59.04 bitrate=2763.8kbits/s dup=5 drop=0 speed=0.958x

And below, when there the "13 hours" problem:
[...]
frame=1191546 fps= 24 q=2.0 size=21511155kB time=13:14:20.52 bitrate=3697.4kbits/s dup=125 drop=0 speed=0.944x
frame=1191546 fps= 24 q=2.0 size=21511155kB time=13:14:20.52 bitrate=3697.4kbits/s dup=125 drop=0 speed=0.944x
frame=1191546 fps= 24 q=2.0 size=21511155kB time=13:14:20.52 bitrate=3697.4kbits/s dup=125 drop=0 speed=0.944x
frame=1191546 fps= 24 q=2.0 size=21511155kB time=13:14:20.52 bitrate=3697.4kbits/s dup=125 drop=0 speed=0.944x
frame=1191546 fps= 24 q=2.0 size=21511155kB time=13:14:20.52 bitrate=3697.4kbits/s dup=125 drop=0 speed=0.944x
frame=1191546 fps= 24 q=2.0 size=21511155kB time=13:14:20.52 bitrate=3697.4kbits/s dup=125 drop=0 speed=0.944x
frame=1191546 fps= 24 q=2.0 size=21511155kB time=13:14:20.52 bitrate=3697.4kbits/s
dup=125 drop=0 speed=0.944x
frame=1191546 fps= 24 q=2.0 size=21511155kB time=13:14:20.52 bitrate=3697.4kbits/s dup=125 drop=0 speed=0.944x
frame=1191546 fps= 24 q=2.0 size=21511155kB time=13:14:20.52 bitrate=3697.4kbits/s dup=125 drop=0 speed=0.944x
frame=1191546 fps= 24 q=2.0 size=21511155kB time=13:14:20.52 bitrate=3697.4kbits/s dup=125 drop=0 speed=0.944x
frame=1191546 fps= 24 q=2.0 size=21511155kB time=13:14:20.52 bitrate=3697.4kbits/s dup=125 drop=0 speed=0.944x
frame=1191546 fps= 24 q=2.0 size=21511155kB time=13:14:20.52 bitrate=3697.4kbits/s dup=125 drop=0 speed=0.944x
frame=1191546 fps= 24 q=2.0 size=21511155kB time=13:14:20.52 bitrate=3697.4kbits/s dup=125 drop=0 speed=0.944x
frame=1191546 fps= 24 q=2.0 size=21511155kB time=13:14:20.52 bitrate=3697.4kbits/s dup=125 drop=0 speed=0.944x

The same log is produced over and over; it's stucked after 13h14m20s ; there are no more frame extracted.
Below the log of rtsp-simple-server ; nothing particular ; we just see that our "consumers" disconnect/reconnect every ~ 13h15m (because we restart them)
2021/05/10 22:40:14 [I] [0/0/0] rtsp-simple-server v0.15.5
2021/05/10 22:40:14 [I] [0/0/0] [metrics] opened on :9998
2021/05/10 22:40:14 [I] [0/0/0] [RTSP/UDP/RTP listener] opened on :8000
2021/05/10 22:40:14 [I] [0/0/0] [RTSP/UDP/RTCP listener] opened on :8001
2021/05/10 22:40:14 [I] [0/0/0] [RTSP/TCP listener] opened on :8554
2021/05/10 22:40:14 [I] [0/0/0] [RTMP listener] opened on :1935
2021/05/10 22:40:46 [I] [1/0/0] [client <IP_ADDRESS>:38930] connected (RTSP/TCP)
2021/05/10 22:40:46 [I] [1/1/0] [client <IP_ADDRESS>:38930] is publishing to path 'stream_name', 2 tracks with udp
2021/05/10 22:41:01 [I] [2/1/0] [client <IP_ADDRESS>:59994] connected (RTSP/TCP)
2021/05/10 22:41:01 [I] [2/1/1] [client <IP_ADDRESS>:59994] is reading from path 'stream_name', 2 tracks with udp
2021/05/11 07:43:06 [I] [3/1/1] [client <IP_ADDRESS>:48260] connected (RTSP/TCP)
2021/05/11 07:43:06 [I] [3/1/2] [client <IP_ADDRESS>:48260] is reading from path 'stream_name', 2 tracks with udp
2021/05/11 11:55:53 [I] [2/1/1] [client <IP_ADDRESS>:59994] disconnected
2021/05/11 11:55:55 [I] [3/1/1] [client <IP_ADDRESS>:46256] connected (RTSP/TCP)
2021/05/11 11:55:55 [I] [3/1/2] [client <IP_ADDRESS>:46256] is reading from path 'stream_name', 2 tracks with udp
2021/05/12 01:10:43 [I] [2/1/1] [client <IP_ADDRESS>:46256] disconnected
2021/05/12 01:10:45 [I] [3/1/1] [client <IP_ADDRESS>:38188] connected (RTSP/TCP)
2021/05/12 01:10:45 [I] [3/1/2] [client <IP_ADDRESS>:38188] is reading from path 'stream_name', 2 tracks with udp
2021/05/12 07:34:30 [I] [2/1/1] [client <IP_ADDRESS>:48260] disconnected
2021/05/12 07:34:41 [I] [3/1/1] [client <IP_ADDRESS>:60778] connected (RTSP/TCP)
2021/05/12 07:34:41 [I] [3/1/2] [client <IP_ADDRESS>:60778] is reading from path 'stream_name', 2 tracks with udp
2021/05/12 14:26:00 [I] [2/1/1] [client <IP_ADDRESS>:38188] disconnected
2021/05/12 14:26:01 [I] [3/1/1] [client <IP_ADDRESS>:53406] connected (RTSP/TCP)
2021/05/12 14:26:01 [I] [3/1/2] [client <IP_ADDRESS>:53406] is reading from path 'stream_name', 2 tracks with udp
2021/05/13 03:41:20 [I] [2/1/1] [client <IP_ADDRESS>:53406] disconnected
2021/05/13 03:41:21 [I] [3/1/1] [client <IP_ADDRESS>:44180] connected (RTSP/TCP)
2021/05/13 03:41:21 [I] [3/1/2] [client <IP_ADDRESS>:44180] is reading from path 'stream_name', 2 tracks with udp
2021/05/13 16:56:41 [I] [2/1/1] [client <IP_ADDRESS>:44180] disconnected
2021/05/13 16:56:42 [I] [3/1/1] [client <IP_ADDRESS>:40428] connected (RTSP/TCP)
2021/05/13 16:56:42 [I] [3/1/2] [client <IP_ADDRESS>:40428] is reading from path 'stream_name', 2 tracks with udp
2021/05/14 06:11:34 [I] [2/1/1] [client <IP_ADDRESS>:40428] disconnected
2021/05/14 06:11:36 [I] [3/1/1] [client <IP_ADDRESS>:35178] connected (RTSP/TCP)
2021/05/14 06:11:36 [I] [3/1/2] [client <IP_ADDRESS>:35178] is reading from path 'stream_name', 2 tracks with udp
2021/05/14 19:26:55 [I] [2/1/1] [client <IP_ADDRESS>:35178] disconnected
2021/05/14 19:26:56 [I] [3/1/1] [client <IP_ADDRESS>:40210] connected (RTSP/TCP)
2021/05/14 19:26:56 [I] [3/1/2] [client <IP_ADDRESS>:40210] is reading from path 'stream_name', 2 tracks with udp
2021/05/15 08:41:45 [I] [2/1/1] [client <IP_ADDRESS>:40210] disconnected
2021/05/15 08:41:46 [I] [3/1/1] [client <IP_ADDRESS>:50806] connected (RTSP/TCP)
2021/05/15 08:41:46 [I] [3/1/2] [client <IP_ADDRESS>:50806] is reading from path 'stream_name', 2 tracks with udp
2021/05/15 21:57:04 [I] [2/1/1] [client <IP_ADDRESS>:50806] disconnected
2021/05/15 21:57:05 [I] [3/1/1] [client <IP_ADDRESS>:46566] connected (RTSP/TCP)
2021/05/15 21:57:05 [I] [3/1/2] [client <IP_ADDRESS>:46566] is reading from path 'stream_name', 2 tracks with udp
2021/05/16 11:11:56 [I] [2/1/1] [client <IP_ADDRESS>:46566] disconnected
2021/05/16 11:11:57 [I] [3/1/1] [client <IP_ADDRESS>:57994] connected (RTSP/TCP)
2021/05/16 11:11:57 [I] [3/1/2] [client <IP_ADDRESS>:57994] is reading from path 'stream_name', 2 tracks with udp
2021/05/17 00:26:46 [I] [2/1/1] [client <IP_ADDRESS>:57994] disconnected
2021/05/17 00:26:48 [I] [3/1/1] [client <IP_ADDRESS>:57102] connected (RTSP/TCP)
2021/05/17 00:26:48 [I] [3/1/2] [client <IP_ADDRESS>:57102] is reading from path 'stream_name', 2 tracks with udp
2021/05/17 13:42:07 [I] [2/1/1] [client <IP_ADDRESS>:57102] disconnected
2021/05/17 13:42:09 [I] [3/1/1] [client <IP_ADDRESS>:54318] connected (RTSP/TCP)
2021/05/17 13:42:09 [I] [3/1/2] [client <IP_ADDRESS>:54318] is reading from path 'stream_name', 2 tracks with udp
2021/05/18 02:56:57 [I] [2/1/1] [client <IP_ADDRESS>:54318] disconnected
2021/05/18 02:56:59 [I] [3/1/1] [client <IP_ADDRESS>:59762] connected (RTSP/TCP)
2021/05/18 02:56:59 [I] [3/1/2] [client <IP_ADDRESS>:59762] is reading from path 'stream_name', 2 tracks with udp
2021/05/18 14:02:25 [I] [4/1/2] [client <IP_ADDRESS>:44112] connected (RTSP/TCP)
2021/05/18 14:02:25 [I] [4/1/3] [client <IP_ADDRESS>:44112] is reading from path 'stream_name', 2 tracks with udp
2021/05/18 14:02:57 [I] [5/1/3] [client <IP_ADDRESS>:47504] connected (RTSP/TCP)
2021/05/18 14:02:57 [I] [5/1/4] [client <IP_ADDRESS>:47504] is reading from path 'stream_name', 2 tracks with udp
2021/05/18 14:20:21 [I] [4/1/3] [client <IP_ADDRESS>:44112] disconnected
2021/05/18 14:20:51 [I] [3/1/2] [client <IP_ADDRESS>:47504] disconnected
2021/05/18 14:26:14 [I] [4/1/2] [client <IP_ADDRESS>:42330] connected (RTSP/TCP)
2021/05/18 14:26:14 [I] [4/1/3] [client <IP_ADDRESS>:42330] is reading from path 'stream_name', 2 tracks with udp
2021/05/18 14:26:15 [I] [5/1/3] [client <IP_ADDRESS>:43242] connected (RTSP/TCP)
2021/05/18 14:26:15 [I] [5/1/4] [client <IP_ADDRESS>:43242] is reading from path 'stream_name', 2 tracks with udp
2021/05/18 16:11:48 [I] [4/1/3] [client <IP_ADDRESS>:59762] disconnected
2021/05/18 16:11:50 [I] [5/1/3] [client <IP_ADDRESS>:36612] connected (RTSP/TCP)
2021/05/18 16:11:50 [I] [5/1/4] [client <IP_ADDRESS>:36612] is reading from path 'stream_name', 2 tracks with udp
2021/05/19 03:41:04 [I] [4/1/3] [client <IP_ADDRESS>:42330] disconnected
2021/05/19 03:41:05 [I] [5/1/3] [client <IP_ADDRESS>:43126] connected (RTSP/TCP)
2021/05/19 03:41:05 [I] [5/1/4] [client <IP_ADDRESS>:43126] is reading from path 'stream_name', 2 tracks with udp
2021/05/19 05:26:41 [I] [4/1/3] [client <IP_ADDRESS>:36612] disconnected
2021/05/19 05:26:43 [I] [5/1/3] [client <IP_ADDRESS>:54198] connected (RTSP/TCP)
2021/05/19 05:26:43 [I] [5/1/4] [client <IP_ADDRESS>:54198] is reading from path 'stream_name', 2 tracks with udp
2021/05/19 16:55:58 [I] [4/1/3] [client <IP_ADDRESS>:43126] disconnected
2021/05/19 16:55:59 [I] [5/1/3] [client <IP_ADDRESS>:48122] connected (RTSP/TCP)
2021/05/19 16:55:59 [I] [5/1/4] [client <IP_ADDRESS>:48122] is reading from path 'stream_name', 2 tracks with udp
2021/05/19 18:42:02 [I] [4/1/3] [client <IP_ADDRESS>:54198] disconnected
2021/05/19 18:42:03 [I] [5/1/3] [client <IP_ADDRESS>:58244] connected (RTSP/TCP)
2021/05/19 18:42:03 [I] [5/1/4] [client <IP_ADDRESS>:58244] is reading from path 'stream_name', 2 tracks with udp
2021/05/20 06:10:49 [I] [4/1/3] [client <IP_ADDRESS>:48122] disconnected
2021/05/20 06:10:51 [I] [5/1/3] [client <IP_ADDRESS>:42942] connected (RTSP/TCP)
2021/05/20 06:10:51 [I] [5/1/4] [client <IP_ADDRESS>:42942] is reading from path 'stream_name', 2 tracks with udp
2021/05/20 07:56:56 [I] [4/1/3] [client <IP_ADDRESS>:58244] disconnected
2021/05/20 07:56:57 [I] [5/1/3] [client <IP_ADDRESS>:39586] connected (RTSP/TCP)
2021/05/20 07:56:57 [I] [5/1/4] [client <IP_ADDRESS>:39586] is reading from path 'stream_name', 2 tracks with udp
2021/05/20 19:25:36 [I] [4/1/3] [client <IP_ADDRESS>:42942] disconnected
2021/05/20 19:25:37 [I] [5/1/3] [client <IP_ADDRESS>:55286] connected (RTSP/TCP)
2021/05/20 19:25:37 [I] [5/1/4] [client <IP_ADDRESS>:55286] is reading from path 'stream_name', 2 tracks with udp
2021/05/20 21:12:17 [I] [4/1/3] [client <IP_ADDRESS>:39586] disconnected
2021/05/20 21:12:18 [I] [5/1/3] [client <IP_ADDRESS>:34006] connected (RTSP/TCP)
2021/05/20 21:12:18 [I] [5/1/4] [client <IP_ADDRESS>:34006] is reading from path 'stream_name', 2 tracks with udp
2021/05/21 08:40:27 [I] [4/1/3] [client <IP_ADDRESS>:55286] disconnected
2021/05/21 08:40:28 [I] [5/1/3] [client <IP_ADDRESS>:42472] connected (RTSP/TCP)
2021/05/21 08:40:28 [I] [5/1/4] [client <IP_ADDRESS>:42472] is reading from path 'stream_name', 2 tracks with udp
2021/05/21 10:27:37 [I] [4/1/3] [client <IP_ADDRESS>:34006] disconnected
2021/05/21 10:27:38 [I] [5/1/3] [client <IP_ADDRESS>:36070] connected (RTSP/TCP)
2021/05/21 10:27:38 [I] [5/1/4] [client <IP_ADDRESS>:36070] is reading from path 'stream_name', 2 tracks with udp
2021/05/21 21:55:47 [I] [4/1/3] [client <IP_ADDRESS>:42472] disconnected
2021/05/21 21:55:47 [I] [5/1/3] [client <IP_ADDRESS>:49168] connected (RTSP/TCP)
2021/05/21 21:55:47 [I] [5/1/4] [client <IP_ADDRESS>:49168] is reading from path 'stream_name', 2 tracks with udp
2021/05/21 23:42:24 [I] [4/1/3] [client <IP_ADDRESS>:36070] disconnected
2021/05/21 23:42:25 [I] [5/1/3] [client <IP_ADDRESS>:44216] connected (RTSP/TCP)
2021/05/21 23:42:25 [I] [5/1/4] [client <IP_ADDRESS>:44216] is reading from path 'stream_name', 2 tracks with udp
2021/05/22 10:14:12 [I] [4/1/3] [client <IP_ADDRESS>:49168] disconnected
2021/05/22 12:57:45 [I] [3/1/2] [client <IP_ADDRESS>:44216] disconnected
2021/05/22 12:57:46 [I] [4/1/2] [client <IP_ADDRESS>:58126] connected (RTSP/TCP)
2021/05/22 12:57:46 [I] [4/1/3] [client <IP_ADDRESS>:58126] is reading from path 'stream_name', 2 tracks with udp
2021/05/23 02:13:06 [I] [3/1/2] [client <IP_ADDRESS>:58126] disconnected
2021/05/23 02:13:07 [I] [4/1/2] [client <IP_ADDRESS>:41346] connected (RTSP/TCP)
2021/05/23 02:13:07 [I] [4/1/3] [client <IP_ADDRESS>:41346] is reading from path 'stream_name', 2 tracks with udp
2021/05/23 15:27:56 [I] [3/1/2] [client <IP_ADDRESS>:41346] disconnected
2021/05/23 15:27:57 [I] [4/1/2] [client <IP_ADDRESS>:37158] connected (RTSP/TCP)
2021/05/23 15:27:57 [I] [4/1/3] [client <IP_ADDRESS>:37158] is reading from path 'stream_name', 2 tracks with udp
2021/05/24 04:42:47 [I] [3/1/2] [client <IP_ADDRESS>:37158] disconnected
2021/05/24 04:42:50 [I] [4/1/2] [client <IP_ADDRESS>:51334] connected (RTSP/TCP)
2021/05/24 04:42:50 [I] [4/1/3] [client <IP_ADDRESS>:51334] is reading from path 'stream_name', 2 tracks with udp
2021/05/24 17:57:37 [I] [3/1/2] [client <IP_ADDRESS>:51334] disconnected
2021/05/24 17:57:38 [I] [4/1/2] [client <IP_ADDRESS>:36620] connected (RTSP/TCP)
2021/05/24 17:57:38 [I] [4/1/3] [client <IP_ADDRESS>:36620] is reading from path 'stream_name', 2 tracks with udp
2021/05/25 07:12:26 [I] [3/1/2] [client <IP_ADDRESS>:36620] disconnected
2021/05/25 07:12:28 [I] [4/1/2] [client <IP_ADDRESS>:36778] connected (RTSP/TCP)
2021/05/25 07:12:28 [I] [4/1/3] [client <IP_ADDRESS>:36778] is reading from path 'stream_name', 2 tracks with udp

Since we are in a k8s environment, we can monitor RAM, CPU and Network. Everything looks "fine". All components are stable ; no spike in CPU usage, no memory leak.
Describe how to replicate the issue

start the server
feed the server with a long live stream (> 13h14)

Are we doing something wrong?
Can you investigate? Do you need more infos / input to investigate?
Thanks;
Regards.

Hello, first of all thanks for your detailed report.
The timing of the issue (13h 14s) suggests that it's related to an overflow of a uint32 90khz clock that starts from zero when someone starts reading:
2^32 / 90000 = 47721 secs = 13 hours 15 mins

There are no such clocks in the ffmpeg publisher nor in the RTSP server, since in RTSP all timestamps have a random initial offset (i.e., the instant 0:00 corresponds to a random number in a RTP packet), and indeed both components are running without problems in your scenario.
The problem lays in the ffmpeg readers, that evidently get confused when their internal clock overflows. I don't know what's the source of this confusion, what we can do is checking whether this issue disappears when a couple of RTSP components are disabled inside the server, in particular:

RTCP packets
RTP-Info headers

These contains additional timing informations that readers receive in addition to RTP packets, therefore disabling them could lead to some effect. Try the attached nightly release and let me know if there's a difference:
rtsp-simple-server_v0.16.2_darwin_amd64.tar.gz
rtsp-simple-server_v0.16.2_linux_amd64.tar.gz
rtsp-simple-server_v0.16.2_linux_arm6.tar.gz
rtsp-simple-server_v0.16.2_linux_arm7.tar.gz
rtsp-simple-server_v0.16.2_linux_arm64v8.tar.gz
rtsp-simple-server_v0.16.2_windows_amd64.zip
In the meanwhile i'm starting this on a VPS:
./rtsp-simple-server &
sleep 1
ffmpeg -stream_loop -1 -re -i sample_1080p_h264.mp4 -c copy -f rtsp rtsp://localhost:8554/stream >/dev/null 2>&1 &
sleep 1
ffmpeg -i rtsp://localhost:8554/stream -c copy -f mpegts -y /dev/null

and we'll see in 13h 15mins

Any updates on this?

Hi,
I didn't test the "debug packages" provided, because we has to switch to another system.
But I can confirm that the problem doesn't come from rtsp-simple-server like @aler9 suggested/analyzed. It all comes from the configuration of the video producer / video receiver.


Lock glob to specific version.

Closes https://github.com/broccolijs/broccoli-kitchen-sink-helpers/issues/27.

@joliss - Can we get a release for this?

Done :)

And thanks for fixing. We should really investigate some time, I'm a bit worried that this will break things left and right for us.

@joliss - node-glob is attempting to match the behavior of bash, which changed in the symlink following case so node-glob "fixed" it.  Unfortunately, we actually want the old behavior (always follow dir symlinks).  There is an issue (https://github.com/isaacs/node-glob/issues/139) to add a follow: true option to always follow symlinks, but there doesn't seem to be any movement on implementation there yet.


[SPARK-5380][GraphX]  Solve an ArrayIndexOutOfBoundsException when build graph with a file format error

When I build a graph with a file format error, there will be an ArrayIndexOutOfBoundsException

Can one of the admins verify this patch?

The argument I can see against it is simply that you want to fail fast on bad input, not sort of continue. If all of the file is like this you'll just log a zillion warnings instead of just stopping. How about changing the warning to throw a standard exception like IllegalArgumentException using require?

I wonder if stopping the process is the best solution.
If there is only one illegal entry in a last line, we need to re-try loading a whole file,
which is time-consuming.
An other idea is that illegal entries are silently re-directed into a file or something.
Finally, # of the re-directed entries is only output in the last phase of bulk-loading.
Moreover, I think that it'd be better to add a new API to append these entries into existing Graph
such as GraphOps.addEdges(val edges: RDD[Edge[ED]]).

Since this was a very simple change, I went ahead and merged it as my first test-drive of the commit bit. Looks like it worked!

I've also merged this into branch-1.3 (1.3.0).

Ah sounds like I should have done more back-porting. I was conservative and only put these several small fixes in master. Go ahead and I'll recalibrate a little accordingly.

@srowen From now until we cut a 1.3.0 preview, I'd merge all bug fixes into at least master and branch-1.3.  We'll raise the bar for getting fixes into branch-1.3 as we get closer to the RC voting period.


Unexpected behaviour when focusing out an editable title field

When focussing out of an editable series title or event title field, some unexpected behaviour occurs (jeditable form gets submitted).
Steps to reproduce:

Click on an editable series title or event title field in the batch edit
Click on a series in the left modules/series list

Reassigning to @Coenego for review.


After migration to 3.7.2, subscription doesn't work

I have a question. I modified spree_product_subscriptions for spree 3.7.2 by folking below.
https://github.com/hardreggaecafe/spree_product_subscriptions/tree/migrate_for_3.7.2
Some of feature is working, but when I add subscribed products to cart, subscription doesn't work correctly(see below).

How should I fix this problems? Tell me please.

@sawangupta92 Can someone look at this and respond.

@mjuneja sure, we will looking into it

@hardreggaecafe You are working with an older version of this extension. We had upgraded this extension a while back, here is the PR for the same https://github.com/vinsol-spree-contrib/spree_product_subscriptions/pull/58/files. Please try this branch. You will need to do some changes in the "Appraisals" file to accommodate it for Spree 3.7. But there shouldn't be any big challenge there.
Please let us know if you get into any other issue.

@sawangupta92 Oops! I didn't know that. I'll check it later.
I'll let you know how it turns out. Thanks.

@sawangupta92 I applied what you suggested earlier. Here's the one.
https://github.com/hardreggaecafe/spree_product_subscriptions/tree/migrate_for_3.7.2
But regrettably, still same. Any idea?

@hardreggaecafe We have reproduced the issue and unfortunately this extension is only working fine for spree versions up to 3.5.
Spree 3.7 is using the latest V2 API for adding the line items to an order, which is not supported in this extension as of now.
We do plan to upgrade this extension in the future. Meanwhile, if you have already fixed the issues in upgrades, you can raise a pull request and we will review and merge it.
For pointers, you can check the OrdersController in the extension. That should help you in debugging & fixing the issue.

@sawangupta92 Oh, I knew it. Every time I press 'subscribe' button, spree calls '/api/v2/storefront/cart/add_item' API. I felt bit strange and confused why this could happen in this gem.
Therefore, could you give me some more advise how to fix this gem if I do it by myself?
What about adding 'app/controllers/spree/api/v2/storefront/cart_controller.rb' and adding some modification to 'add_item' like this?
          def add_item
            variant = Spree::Variant.find(params[:variant_id])

            spree_authorize! :update, spree_current_order, order_token
            spree_authorize! :show, variant

            result = add_item_service.call(
              order: spree_current_order,
              variant: variant,
              quantity: params[:quantity],
              options: params[:options]
            )
            #Add record to Spree:Subscription

            render_order(result)
          end

@hardreggaecafe Yes, this should be the starting point. I think that updating the params[:options] as per the #add_subscription_fields and permitting the params, should be the first step to solve the issue.

Hi @hardreggaecafe!
Just bumped into the same issue. So I thought I'd try your branch while I'm at it.
However, there seems to be a problem, so I thought I'd might as well drop you a line..
BR
Georg
Showing ..../spree_product_subscriptions-spree_v3.7/app/views/spree/shared/_taxonomies.html.erb where line #4 raised:

My gemfile is
source 'https://rubygems.org'
git_source(:github) { |repo| "https://github.com/#{repo}.git" }

ruby '2.7.2'

gem 'spree', '= 3.7.2'
gem 'spree_auth_devise', '~> 3.5'
gem 'spree_gateway', '~> 3.4'

gem 'spree_product_subscriptions', github: 'hardreggaecafe/spree_product_subscriptions', branch: 'migrate_for_3.7.2'

# Bundle edge Rails instead: gem 'rails', github: 'rails/rails'
gem 'rails', '~> 5.2.4', '>= <IP_ADDRESS>'
# Use sqlite3 as the database for Active Record
gem 'sqlite3'
# Use Puma as the app server
gem 'puma', '~> 3.11'
# Use SCSS for stylesheets
gem 'sass-rails', '~> 5.0'
# Use Uglifier as compressor for JavaScript assets
gem 'uglifier', '>= 1.3.0'
# See https://github.com/rails/execjs#readme for more supported runtimes
# gem 'mini_racer', platforms: :ruby

# Use CoffeeScript for .coffee assets and views
gem 'coffee-rails', '~> 4.2'
# Turbolinks makes navigating your web application faster. Read more: https://github.com/turbolinks/turbolinks
gem 'turbolinks', '~> 5'
# Build JSON APIs with ease. Read more: https://github.com/rails/jbuilder
gem 'jbuilder', '~> 2.5'
# Use Redis adapter to run Action Cable in production
# gem 'redis', '~> 4.0'
# Use ActiveModel has_secure_password
# gem 'bcrypt', '~> 3.1.7'

# Use ActiveStorage variant
# gem 'mini_magick', '~> 4.8'

# Use Capistrano for deployment
# gem 'capistrano-rails', group: :development

# Reduces boot times through caching; required in config/boot.rb
gem 'bootsnap', '>= 1.1.0', require: false

group :development, :test do
  # Call 'byebug' anywhere in the code to stop execution and get a debugger console
  gem 'byebug', platforms: [:mri, :mingw, :x64_mingw]
end

group :development do
  # Access an interactive console on exception pages or by calling 'console' anywhere in the code.
  gem 'web-console', '>= 3.3.0'
  gem 'listen', '>= 3.0.5', '< 3.2'
  # Spring speeds up development by keeping your application running in the background. Read more: https://github.com/rails/spring
  gem 'spring'
  gem 'spring-watcher-listen', '~> 2.0.0'
end

group :test do
  # Adds support for Capybara system testing and selenium driver
  gem 'capybara', '>= 2.15'
  gem 'selenium-webdriver'
  # Easy installation and use of chromedriver to run system tests with Chrome
  gem 'chromedriver-helper'
end

# Windows does not include zoneinfo files, so bundle the tzinfo-data gem
gem 'tzinfo-data', platforms: [:mingw, :mswin, :x64_mingw, :jruby]

Hi @hardreggaecafe!
Just bumped into the same issue. So I thought I'd try your branch while I'm at it.
However, there seems to be a problem, so I thought I'd might as well drop you a line..
BR
Georg
Showing ..../spree_product_subscriptions-spree_v3.7/app/views/spree/shared/_taxonomies.html.erb where line #4 raised:

My gemfile is
source 'https://rubygems.org'
git_source(:github) { |repo| "https://github.com/#{repo}.git" }

ruby '2.7.2'

gem 'spree', '= 3.7.2'
gem 'spree_auth_devise', '~> 3.5'
gem 'spree_gateway', '~> 3.4'

gem 'spree_product_subscriptions', github: 'hardreggaecafe/spree_product_subscriptions', branch: 'migrate_for_3.7.2'

# Bundle edge Rails instead: gem 'rails', github: 'rails/rails'
gem 'rails', '~> 5.2.4', '>= <IP_ADDRESS>'
# Use sqlite3 as the database for Active Record
gem 'sqlite3'
# Use Puma as the app server
gem 'puma', '~> 3.11'
# Use SCSS for stylesheets
gem 'sass-rails', '~> 5.0'
# Use Uglifier as compressor for JavaScript assets
gem 'uglifier', '>= 1.3.0'
# See https://github.com/rails/execjs#readme for more supported runtimes
# gem 'mini_racer', platforms: :ruby

# Use CoffeeScript for .coffee assets and views
gem 'coffee-rails', '~> 4.2'
# Turbolinks makes navigating your web application faster. Read more: https://github.com/turbolinks/turbolinks
gem 'turbolinks', '~> 5'
# Build JSON APIs with ease. Read more: https://github.com/rails/jbuilder
gem 'jbuilder', '~> 2.5'
# Use Redis adapter to run Action Cable in production
# gem 'redis', '~> 4.0'
# Use ActiveModel has_secure_password
# gem 'bcrypt', '~> 3.1.7'

# Use ActiveStorage variant
# gem 'mini_magick', '~> 4.8'

# Use Capistrano for deployment
# gem 'capistrano-rails', group: :development

# Reduces boot times through caching; required in config/boot.rb
gem 'bootsnap', '>= 1.1.0', require: false

group :development, :test do
  # Call 'byebug' anywhere in the code to stop execution and get a debugger console
  gem 'byebug', platforms: [:mri, :mingw, :x64_mingw]
end

group :development do
  # Access an interactive console on exception pages or by calling 'console' anywhere in the code.
  gem 'web-console', '>= 3.3.0'
  gem 'listen', '>= 3.0.5', '< 3.2'
  # Spring speeds up development by keeping your application running in the background. Read more: https://github.com/rails/spring
  gem 'spring'
  gem 'spring-watcher-listen', '~> 2.0.0'
end

group :test do
  # Adds support for Capybara system testing and selenium driver
  gem 'capybara', '>= 2.15'
  gem 'selenium-webdriver'
  # Easy installation and use of chromedriver to run system tests with Chrome
  gem 'chromedriver-helper'
end

# Windows does not include zoneinfo files, so bundle the tzinfo-data gem
gem 'tzinfo-data', platforms: [:mingw, :mswin, :x64_mingw, :jruby]


File read doesn't work in strict mode

Hi,
I tried to run this example from README in my browser:
var octo = new Octokat();
var repo = octo.repos('philschatz', 'octokat.js');
repo.contents('README.md').read() // Use `.read` to get the raw file.
.then(function(contents) {        // `.fetch` is used for getting JSON
  console.log(contents);
});

... but it fails with following error:
verb-methods.js:76 Uncaught TypeError: Cannot create property 'url' on string '# Octokat.js

Error line is following (verb-methods.js:76):
      obj.url = path;

Somehow, obj becomes a response string, and it's forbidden to make new properties for strings in strict mode.

It works fine for me on this demo page: https://tonicdev.com/npm/octokat

Closing this because the code seems to work on tonicdev (Thanks @timaschew for responding!)
If it does not work, please reopen the Issue


Remove gas price bounds from general config

This change is

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (e47310e) 70.88% compared to head (1f58950) 70.92%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1329      +/-   ##
==========================================
+ Coverage   70.88%   70.92%   +0.03%
==========================================
  Files          59       59
  Lines        7350     7346       -4
  Branches     7350     7346       -4
==========================================
  Hits         5210     5210
+ Misses       1726     1722       -4
  Partials      414      414

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


DotNS.GetNationInfo raises System.FormatException

Looks like something changed with the API and now the headers aren't working.

Hello and thank you for your report!
There was an issue with this exception when no default user-agent is set. It should be fixed now, please update to 0.4.1.


How to determine why flannelized IPs can't see one another?

I've setup flannel 0.2 between some machines using a vagrant+virtualbox recipe with etcd, and docker 1.6.     All indicators which I can think of seem to be green, but containers aren't able to ping/reach one another.  What other items shall I check for ?
So far I've verified:

The following checklist items seem to be working:

can start flannel as the default networking backdrop on two independent VMs in virtualbox,
using one etcd server, which is working perfectly,
and each of the VMs is getting a non 172 default address  (i.e. 10.x.y.z)
the flannel network interface is indeed showing up (so is the docker0) in ip a both appear to be the same subnet.

Additionally, the flanneld logs are not indicating any failures.

machine1:
Jun 21 12:19:09 kube0.ha systemd[1]: Starting Flanneld overlay address etcd agent...
Jun 21 12:19:09 kube0.ha flanneld[19445]: I0621 12:19:09.810365   19445 main.go:247] Installing signal handlers
Jun 21 12:19:09 kube0.ha flanneld[19445]: I0621 12:19:09.810399   19445 main.go:118] Determining IP address of default interface
Jun 21 12:19:09 kube0.ha flanneld[19445]: I0621 12:19:09.810994   19445 main.go:205] Using <IP_ADDRESS> as external interface
Jun 21 12:19:12 kube0.ha flanneld[19445]: I0621 12:19:12.199864   19445 subnet.go:83] Subnet lease acquired: <IP_ADDRESS>/24
Jun 21 12:19:12 kube0.ha flanneld[19445]: I0621 12:19:12.207320   19445 main.go:215] VXLAN mode initialized
Jun 21 12:19:12 kube0.ha flanneld[19445]: I0621 12:19:12.207750   19445 vxlan.go:115] Watching for L2/L3 misses
Jun 21 12:19:12 kube0.ha flanneld[19445]: I0621 12:19:12.208097   19445 vxlan.go:121] Watching for new subnet leases
Jun 21 12:19:12 kube0.ha systemd[1]: Started Flanneld overlay address etcd agent.

machine 2:
[root@kube0 vagrant]#
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Jun 21 12:18:33 kube1.ha systemd[1]: Starting Flanneld overlay address etcd agent...
Jun 21 12:18:33 kube1.ha flanneld[18148]: I0621 12:18:33.116524   18148 main.go:247] Installing signal handlers
Jun 21 12:18:33 kube1.ha flanneld[18148]: I0621 12:18:33.116555   18148 main.go:118] Determining IP address of default interface
Jun 21 12:18:33 kube1.ha flanneld[18148]: I0621 12:18:33.120795   18148 main.go:205] Using <IP_ADDRESS> as external interface
Jun 21 12:18:33 kube1.ha flanneld[18148]: I0621 12:18:33.177517   18148 subnet.go:83] Subnet lease acquired: <IP_ADDRESS>/24
Jun 21 12:18:33 kube1.ha flanneld[18148]: I0621 12:18:33.183422   18148 main.go:215] VXLAN mode initialized
Jun 21 12:18:33 kube1.ha flanneld[18148]: I0621 12:18:33.183441   18148 vxlan.go:115] Watching for L2/L3 misses
Jun 21 12:18:33 kube1.ha flanneld[18148]: I0621 12:18:33.183453   18148 vxlan.go:121] Watching for new subnet leases
Jun 21 12:18:33 kube1.ha systemd[1]: Started Flanneld overlay address etcd agent.

Everything seems okay so far...  So, the next step, I launched two containers.
[root@kube0 vagrant]# docker run -t -i docker.io/jayunit100/k8-petstore-redis-slave:r.2.8.19 /bin/sh
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet <IP_ADDRESS>/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
27: eth0: <BROADCAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default
    link/ether 02:42:0a:00:18:0b brd ff:ff:ff:ff:ff:ff
    inet <IP_ADDRESS>/24 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:aff:fe00:180b/64 scope link
       valid_lft forever preferred_lft forever

The second container had the same (ip was <IP_ADDRESS>, however) but the two containers couldn't reach one another:
# ping <IP_ADDRESS>
PING <IP_ADDRESS> (<IP_ADDRESS>) 56(84) bytes of data.
From <IP_ADDRESS> icmp_seq=1 Destination Host Unreachable

and vice versa as well (<IP_ADDRESS> couldnt ping .4).
How can I determine why it is that these two flannel subnets arent unified / able to reach one another ?  Is there a way i can test for membership in the flannel vxlan, as opposed to just looking to confirm that the IP is on the 10 subnet?
My current thought is that maybe I can do a watch on etcd, to see how coreos.com/network entries are being written... but maybe there is a more natural way to debug flannel connectivity ?

I ultimately found that running tcpdump -i eth1 showed me the error buried ...
kube1.ha > kube2.ha ICMP host kube1.ha unreachable - admin prohibited - length 68
The solution ? I ran "iptables -F" on all of my machines.  This seemed to clear up the issue.

@jayunit100 Yes, this is a known issue with Vagrant, please see https://github.com/coreos/flannel/issues/98
However, also make sure that the network that's been configured for flannel does not overlap with the host's IPs. From
Jun 21 12:19:09 kube0.ha flanneld[19445]: I0621 12:19:09.810994   19445 main.go:205] Using <IP_ADDRESS> as external interface
Jun 21 12:19:12 kube0.ha flanneld[19445]: I0621 12:19:12.199864   19445 subnet.go:83] Subnet lease acquired: <IP_ADDRESS>/24

I see that your host's (well, VM's) IP is <IP_ADDRESS> and the flannel network is probably configured as <IP_ADDRESS>/16. That puts <IP_ADDRESS> within the flannel range.


Allow Jest to run ESM modules

Bug description
Some modules cannot be upgraded because they use ESM syntax. In turn, our tests fail.
How to reproduce
For example see https://github.com/prisma/engines-wrapper/pull/131
Expected behavior
We should be able to run the tests since we are able to compile ES modules.

Tracked in https://github.com/prisma/prisma/issues/7618


[Bug] NOT NULL should not display any null values in the output

Problem:
NOT NULL should not display any null values in the output
No_Dictionary columns wont support double/decimal type, but in case of integer type data this scenario has to be handled.
issue is happening since no dictionary integer type column block contain String value, so when filter comparison happens the actual data which is a non null value  present in block
will be compared with default null member and the null will not get filtered out.
Solution:
To solve this issue while performing data load the no dictionary integer/other type of column excluding String type contains any un parseable data
the system has to convert it to default null member value.

@sujith71955 , there are test cases are failing please fix them. And also add test case for this scenario.