Android throws an error

Hey, I've tried out this library and it seems to be working quite nicely for iOS, but when I run the Android version, I get an error from the measureLayout function saying that there was an error measuring the element. If I log the actual error, it says: Trying to measure a view using measureLayout/measureLayoutRelativeToParent relative to an ancestor that requires custom layout for it's children (RNSScreenContainer). Use measure instead..

Some more details:
I have added the <HighlightableElementProvider> inside App.js
I'm using React-Navigation and I have a custom tab bar where I render each tab bar item and I what I want to achieve is an explanation of each tab for new users in a modal (the modal is just a view with 'absolute' positioning), therefore I wrap the tab item with <HighlightableElement> like this:
return (
    <HighlightableElement id={route.name} key={route.name}>
      <TabButton
        route={route}
        onPress={onPress}
        focused={isFocused}
      />
    </HighlightableElement>
);

I want the current tab bar item to be highlighted and the modal, as well, therefore I place the <HighlightOverlay> inside my modal component like this:
return (
    <>
      <HighlightOverlay onDismiss={() => {}} highlightedElementId="highlightedElement" />
      <View style={{
          backgroundColor: '#fff',
          borderRadius: 10,
          flex: 1,
          left: 15,
          position: 'absolute',
          right: 15,
          top: 10
      }}>
        <ScrollView>
          // content here
        </ScrollView>
      </View>
    </>
  );

Thank you that's super helpful! I'll do some experimenting with react-navigation tab bar. Some questions:

If you try highlighting a normal element on any screen, do you still get the same error? Or is it only when you try to highlight a tab bar button?
If you change your tab button to something like this, does it work then or do you get the same error?

const TabButton = () => {
  return (
    <View>
      <HighlightableElement id={route.name} key={route.name}>
        <TabButton
          route={route}
          onPress={onPress}
          focused={isFocused}
        />
      </HighlightableElement>
    </View>
  )
}

What if you try the same code as above, but you replace <TabButton ... /> with <View style={{ width: 30, height: 30, backgroundColor: "red" }} />?

Fix is up, version 1.2.1 🎉. I hope it fixes your problem. My working code looked like this (the formatting is gonna be ugly, sorry).
("Root" is just any screen, nothing special there).
import type { BottomTabBarProps } from "@react-navigation/bottom-tabs";
import { createBottomTabNavigator } from "@react-navigation/bottom-tabs";
import { NavigationContainer } from "@react-navigation/native";
import React, { useState } from "react";
import { Text, TouchableOpacity, View } from "react-native";
import {
	HighlightableElement,
	HighlightableElementProvider,
	HighlightOverlay,
} from "react-native-highlight-overlay";

import Root from "./Root";

function MyTabBar({
	state,
	descriptors,
	navigation,
	setFocus,
}: BottomTabBarProps & { setFocus: (focus: string) => void }) {
	return (
		<View style={{ flexDirection: "row", justifyContent: "space-evenly" }}>
			{state.routes.map((route, index) => {
				const { options } = descriptors[route.key];
				const label =
					options.tabBarLabel !== undefined
						? options.tabBarLabel
						: options.title !== undefined
						? options.title
						: route.name;

				const isFocused = state.index === index;

				const onPress = () => {
					const event = navigation.emit({
						type: "tabPress",
						target: route.key,
						canPreventDefault: true,
					});

					if (!isFocused && !event.defaultPrevented) {
						// The `merge: true` option makes sure that the params inside the tab screen are preserved
						navigation.navigate({ name: route.name, merge: true });
					}
				};

				const onLongPress = () => {
					navigation.emit({
						type: "tabLongPress",
						target: route.key,
					});
				};

				return (
					<HighlightableElement
						id={label.toString()}
						key={label.toString()}
						style={{ flex: 1 }}
					>
						<TouchableOpacity
							accessibilityRole="button"
							accessibilityState={isFocused ? { selected: true } : {}}
							accessibilityLabel={options.tabBarAccessibilityLabel}
							testID={options.tabBarTestID}
							onPress={() => {
								setFocus(label.toString());
								onPress();
							}}
							onLongPress={onLongPress}
							style={{
								height: 55,
								justifyContent: "center",
								alignItems: "center",
								backgroundColor: ["red", "green", "blue", "yellow"][index],
							}}
						>
							<Text style={{ color: isFocused ? "white" : "#222" }}>{label}</Text>
						</TouchableOpacity>
					</HighlightableElement>
				);
			})}
		</View>
	);
}

const TabNavigator = createBottomTabNavigator();

function App() {
	const [focus, setFocus] = useState<string | null>("0");
	return (
		<HighlightableElementProvider>
			<NavigationContainer>
				<TabNavigator.Navigator
					tabBar={(props) => <MyTabBar setFocus={setFocus} {...props} />}
				>
					<TabNavigator.Screen name="1" component={Root} />
					<TabNavigator.Screen name="2" component={Root} />
					<TabNavigator.Screen name="3" component={Root} />
					<TabNavigator.Screen name="4" component={Root} />
				</TabNavigator.Navigator>
			</NavigationContainer>
			<HighlightOverlay highlightedElementId={focus} onDismiss={() => setFocus(null)} />
		</HighlightableElementProvider>
	);
}

export default App;

Hmm that's weird. Perhaps something to do with the status bar; what happens if you add / remove it? Could also be the Android navigation bar (with the back button etc. at the bottom).
As for the clip path not changing I'll have to look into it. Perhaps I missed a dependency on a hook so it doesn't re-render, but I think ESLint would've warned about that. It might be another edge-case when using react-navigation, I'll test some more.
The iOS message is a known bug with react-native-svg and the pointerEvent prop. Everything should work, but you might not be able to click the highlighted element on iOS and would just dismiss the overlay instead. I've forked react-native-svg to see if I can find a fix but I can't make any promises (it's an old bug so it's likely difficult to fix). I'll at least make a quick fix that removes the prop on iOS so you don't get the warning message.
If I can't find the solution to this I'll push a fix that allows you to manually specify an offset for the highlight, not the most elegant fix but at least it won't look weird.
Thank you for taking the time to report this :)


Remote repo management feature #60

https://github.com/neel1996/gitconvex/issues/60

Remote management feature front-end changes

https://github.com/neel1996/gitconvex/issues/60
https://github.com/neel1996/gitconvex/issues/131

Remote management feature front-end changes

https://github.com/neel1996/gitconvex/issues/60
https://github.com/neel1996/gitconvex/issues/131


Support async request handling in JettyService

Related: #3320
Motivation:
JettyService is currently incapable of running a Jetty handler which
makes use of Request.startAsync(). It'd be great if we support it as
well.
Modifications:

Use HttpChannel.handle() instead of Server.handle() so that
request state is managed correctly by Jetty, fixing issues with
asynchronous request processing.
Simplify ArmeriaHttpTransport.

It doesn't have to buffer everything before sending out a response
anymore.
Content-Length header is not set anymore when a Servlet sends a
streaming response, which is normal.

Write HttpData with the endOfStream flag set when Jetty tells us
it's sending the last content.
Write trailers set by Jetty (for Jetty 9.4+).

Result:

Closes #3320
JettyService can now handle asynchronous Servlets.
JettyService now streams the response earlier than before.

As a result, dynamic responses will not have a Content-Length
header set, which is actually a usual behavior in Servlets.

JettyService now sends the trailers if a user set trailers with
Response.setTrailers(Supplier).

https://ci.appveyor.com/project/line/armeria/builds/37631599/job/15vadgaxqsts4svf#L226
check style failed. 😄


Problem with instalation

Hi, i have a problem with the intalation process in my conda virtual env. When i run command "pip install chefshatgym", the command line show up this error:

Can anyone help me please ?
the laptop im use is a mackbook pro mid 2012.

Hi!
I think we solved, right?
I updated the dependencies list, and if you having trouble, try to install the latest version from pip:https://pypi.org/project/ChefsHatGym/


Added featured section

Coverage remained the same at 100.0% when pulling d039e554cf87ac1e31f05808bd48fb3ca5969766 on featured-section into c858b972bb5db13de748a0229b95084e46974be5 on master.

Codecov Report

Merging #223 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##           master   #223   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files          18     18
  Lines         461    461
  Branches       43     43
=====================================
  Hits          461    461


Feature/sync editor merge

Sync Page UI
Sync from editor
Sync merge for existing project other than replace
version changes for ag-setting , ag-user-settings
backup for synced projects
display conflict files

This is a video walk-through of the feature:
https://user-images.githubusercontent.com/8311862/188961957-5fca8a02-c8d3-4b7b-99c6-d167ade2fc81.mp4


Update the timeout of CI builds

PR Summary
In some CI builds we are either hitting the 1 hour CI job timeout or getting very close to it. Increasing this to 2 hours.
PR Checklist

[x] PR has a meaningful title

Use the present tense and imperative mood when describing your changes

[x] Summarized changes
[x] Change is not breaking
[x] Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
[x] This PR is ready to merge and is not Work in Progress.

If the PR is work in progress, please add the prefix WIP: to the beginning of the title and remove the prefix when the PR is ready.

User-facing changes

[x] Not Applicable
OR
[ ] User-facing Documentation needed

[ ] Issue filed - Issue link:

Testing - New and feature

[x] Not Applicable or can only be tested interactively
OR
[ ] Make sure you've added a new test if existing tests do not effectively test the code changed

[ ] Add [feature] if the change is significant or affects feature tests

linux.yml (Line: 39, Col: 3): Unexpected value 'timeoutInMinutes'
Most likely rename phase(s) -> job(s)


CB-13963: (android) Fix error in platform guide.

Platforms affected
android
What does this PR do?
remove "or later" post "install jdk8" because jdk 9 doesn't work with cordova (or android).
What testing has been done on this change?
none
Checklist

[x] Reported an issue in the JIRA database
[x] Commit message follows the format: "CB-3232: (android) Fix bug with resolving file paths", where CB-xxxx is the JIRA ID & "android" is the platform affected.
[x] Added automated test coverage as appropriate for this change.

Awesome, thank you. Can you also check dev if there is the same problem and change it as well so it won't reappear when the 8.x docs are released please?

 Not sure what you mean by dev, I don't see any branch by that name.

@goleary www/docs/en/dev is the current version of docs. www/docs/en/7.x is the frozen version at the time when Cordova 7.X was released

Thanks for explaining @kant2002 - the versioning here is indeed folder and not branch based, should have mentioned that @goleary

Ok i've gone ahead and modified it in both folders for the english language.  Is there some process to translate the update to other languages that can be kicked off or should I not worry about that?

Nothing you have to worry about - translations are currently stalled unfortunately.
Thanks, will merge this as soon as possible (just leaving for a week of vacation, so not the best time for me - but when I am back).

sure thing, happy to help


Introduce Windows 10 LTSC 2022 and Windows Server image

LTSC is a bit weird: it's not exactly an alias to 21H1, and 21H1
hasn't been released yet. For now, let's consider that they are
independent releases and that 21H1 isn't yet available.
Also introduce the "windows/server" image that replaces the "windows"
image starting with ltsc2022.

I don't think we should introduce the  `Server tag - what Microsoft's really doing is renaming the repo from windows to windows/server (by only adding new tags to windows/server). The point in their docs is that the windows repo has always been Windows Server (+ a few extra binaries) not the Windows 10 Client. I think win10_docker_base_image encompasses the distribution of Windows Server which you're expecting: Nano Server, Core or "Full" and they've just changed the repo for Full in ltsc2022 from windows to windows/server. Does that make sense? At the moment, there are match cases missing to exclude say (`Server, `V2004) in win10_docker_status but I think the problem is the type, not the missing match cases!

I agree with everything, in the end it's just a matter of renaming.

At the moment, there are match cases missing to exclude say (Server, V2004) in win10_docker_status

The compiler would have caught that and I mostly compile my code before sending it :smile:

 | `Server, _ -> `Not_available

The compiler would have caught that and I mostly compile my code before sending it 😄

 | `Server, _ -> `Not_available

Oops - my bad. I completely missed that line! 🙂 The compiler wouldn't have caught it, though, because of the wildcards below.

LGTM - let's test this as part of the docker-base-images update and then merge.

The repo needs updating here:
https://github.com/avsm/ocaml-dockerfile/blob/313b1c9b91b49bdc5b536f2992f079ae91047611/src-opam/dockerfile_windows.ml#L162-L166

Thanks, fixed by exposing a function and a type to get the image and tag for Windows base container images.

ltsc2022/Windows 11 images now build 🥳


Console commands basic implementation

I introduce a new grammar that extends the CypherParser with more client side commands like :param x => 23 and :use foo. It can be toggled on/off, and I've added proper errors, completions, highlighting for the client side commands. See the new test cases for a fuller picture
This PR also fixes semantic analysis for multi-statement queries, like RETURN a; RETURN b; since I had to split the string into parts to avoid sending the client commands regardless.

@ncordon the odd behavior you saw in vsocde/codemirror was caused by the parseToCommands crashing on parse errors. I fixed the errors and added a few tests.
Is it fine to leave in the issue of the error message suggesting a keyword on : for now and re-visit it if it comes up again?


Feature/fbp 73 ij community support

Fixes #73

Codecov Report

Merging #366 (4d874dc) into master (0172499) will not change coverage.
The diff coverage is 0.00%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@            Coverage Diff            @@
##             master     #366   +/-   ##
=========================================
  Coverage     64.92%   64.92%
  Complexity     1419     1419
=========================================
  Files           227      227
  Lines          7188     7188
  Branches        916      916
=========================================
  Hits           4667     4667
  Misses         2180     2180
  Partials        341      341

Flag
Coverage Δ

unittests
64.92% <0.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...lij/plugin/core/properties/PropertiesVisualizer.kt
81.25% <0.00%> (ø)

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


 I've tried running the example project as well with no luck.
Any help would be appreciated, thanks!

I've also noticed that the iOS native controls don't work well on the current master branch. Using 0.7.1 in my project and controls work fine in that version, not sure where it broke.

If I manually change the default from NO to YES in RCTVideo.m I can get them to show up, it seems as if the property isn't being passed correctly.

@hassankhan if you will use 0.8.0-beta you should be able to display the controls by setting fullscreen on component and presentFullscreenPlayer (let me know if I am wrong but I guess that should help).

Is presentFullscreenPlayer also available to Android? I couldn't manage to work it my own project.

No, it isn't.

so what's the purpose of fullscreen prop now?
and what can I do to have android similar full screen+controls

Wicked, thanks @dwaligora

Bump  @yonatanmn's question. Is there a workaround for android fullscreen w/ controls?

Fixed now -> https://github.com/react-native-community/react-native-video/pull/270


Presets, Plugin Updates and JCAMP-DX

I probably should have broken this up into more PRs.

plugins

removed plugin 'dependencies'; increase default plugin Marquee period
support events in functional plugins
provide self.marquee_message for functional plugins
add combobox datatype for plugin fields
allow plugin fields to have stylesheets

file_io

save as JCAMP-DX
support loading columnar CSV files which don't happen to include 'Integration Time'

added PresetFeature
refactoring

moved RamanIntensityCorrection, ScanAveragingFeature, BaselineCorrection, BoxcarFeature, IntegrationTimeFeature to ctl
docs and cleanup around ScrollStealFilter and MouseWheelFilter
simplified Configuration.save

Yes this is kind of a lot to review at once, but most of it looks good.
Two things stand out to me.
1. Deprecation of plugin dependencies
Appears to be a duplicate of #311 . This can be handled a number of ways, but it may be worthwhile to diff the two branches to see if they differ more than expected. One way to do this would be.

# should contain the largest set of filenames
git diff --name-only mzieg-followup-testing 4.1.0-dev

# should contain a strict subset of filenames, plugin related
git diff --name-only mzieg-4.1.0-plugin-features 4.1.0-dev

# should contain a strict subset of filenames, not plugin related
git diff --name-only mzieg-followup-testing mzieg-4.1.0-plugin-features

Overall, it's a non-issue. If both branches are good, then they can both be merged in any order and the whole thing should be fine, but it's a bit curious that such an overlap happened.
2. Preset Feature API
There's a nice comment that explains the preset feature's API.
"""
    External API would be something like:
         class IntegrationTimeFeature:
             def __init__:
                 ctl.presets.register(self, ["integration_time_ms"])
             def get_preset(self, attr):
                 if attr == "integration_time_ms":
                     return self.current_ms
             def set_preset(self, attr, value):
                 if attr == "integration_time_ms":
                     self.set_ms(int(value))
"""

This looks pretty good, it handles situations where we need to do more than update a variable--for example modifying the GUI to match. This is not the soln I had in mind, but that's okay. The main thing I would suggest is to avoid passing attr's, and to explicitly state callbacks in the registration step. Also, avoid passing an array to register--rather call it multiple times.
"""
    External API would be something like:
         class IntegrationTimeFeature:
             def __init__:
                 ctl.presets.register(self, "integration_time_ms", get_integration_time, set_integration_time_ms)

             def get_integration_time_ms():
                 return self.current_ms

            def set_integration_time_ms(value):
                value = int(value)
                # existing definition ...
"""

For completeness, the solution I had in mind would be to use resolution and search-paths. This would involve creating a parameter construct which represents the kinds of things that we might want to preset, persist, etc. Classes that depend on Enlighten Parameters access those values via a third party every time (kind of like how we access spec from multispec). Setting the value also uses the same third party. The parameter access routine will have some logic to decide whether to load the value from the .ini file, eeprom, a hardcoded default, or from the active preset. It requires that upon selecting a preset, that the GUI is updated to call in new resolutions for each parameter. Parameters perform validation and correction at access time.

check jcamp save

Can you expand on that?  I have definitely saved many .dx files successfully...but that may be because I have ..\jcamp in my PYTHONPATH.
I'll add it to requirements.txt.

I'll add it to requirements.txt.

Actually...we should probably fork the version of jcamp that has writefile, and add it as a manual dependency...hmm.

The main thing I would suggest is to avoid passing attr's, and to explicitly state callbacks in the registration step. Also, avoid passing an array to register--rather call it multiple times.

Updated.

Thank you for including that suggestion.
Note: Not that this particularly matters, but the spelling is getter/setter not gettor/settor.

getter/setter not gettor/settor

TIL


How to integrate React-Big-Calendar

Hey dear Community,
everyday i get a little forward with my app ^^ Today i want to add the Calendar and found react-big-calendar (a FullCalendar synonym for React). I installed it properly and added it to the Calendar-Page.
One thing i didnt managed to do is to give it the appropiate style ^^
In normal cases i can use like  TESTCSS[testclass] to give the object the corresponding css.
But since this is a Package i dont managed to do it.
Here is the Container, where i build the Calendar (LINK)
Thanks for any help in advance

My question is:  How i add a css-file globally so the module uses it

Can't you just import it?

scss

@include('~react-big-calendar/lib/css/react-big-calendar.css');

js

import 'react-big-calendar/lib/css/react-big-calendar.css';

Tried it but since every cssclass gets a hashtag they dont get applied correctly...
Fixed it by making a new file  (>CLICK<)
And then applying the calendarStyle Class to the Calendar .
Fixed it

Actually loading css files from node_modules directory should not modulize the class name..
you can add that exception easily to the webpack config file 👍

The new version now won't modulize css files by default, feel free to try it 😸


WIL for Rust

WIL is an invaluable library for Windows development using C++. Is there a Rust equivalent?
RAII helpers for Windows APIs like in win32_helpers.h, token_helpers.h and more would be welcome for Windows development using Rust. A 'WIL for Rust' moral equivalent or 'port to Rust language and idioms, to bring the same productivity gains to Rust as WIL brings to C++ development.

Thanks Howard. While I agree that there's value to having something like WIL For Rust developers, I'm not sure that it belongs in a single Rust crate. It's more likely that a family of crates will provide useful wrappers for individual Win32 APIs. We may also find that some are unnecessary depending on what overlap exists in Rust's standard library and many such crates may already exist.

There are two crates that attempt to provide safe wrappers that I'm aware of:

wio
winapi-util

wio is published by Peter Atashian, maintainer of the winapi crate, and winapi-util by Andrew Gallant. Both authors are very capable, yet neither crate is anywhere near complete, nor do they show any significant signs of life.

Closing as this is not specific to the Rust language projection. Feel free to keep the conversation going.

@kennykerr Fair enough. I have no preference over the form. Just interested to see the relevant functionality also available to Rust developers. Is there a better venue for that discussion?

I'll create a dedicated repo and link to it here.


cache /get_transactions call on lastblocks collector

depending on the scraping interval, it can be somewhat expensive on monerod to serve the requests it takes from monero-exporter.
it we look at the lastblocks collector's fetchData (when it reaches out to monerod), we can note the call to /get_transactions passing the hash of every transaction included in that block:
https://github.com/cirocosta/monero-exporter/blob/652cf4022780a8d4f101e729a2a097bb398ddff9/pkg/collector/collector_lastblock.go#L79-L82
as we expect blocks to arrive every 2min, a prometheus instance configured with a polling interval of 15s would be making 8 times more calls to that endpoint than it really should (as they'll all return the same answer).
in that case, because the call /get_block is made using a hash (rather than a height), we could cache the response from get_transactions for such block, thus reducing the load on monerod.
BEFORE

        on every scrape:

                lastBlockHeader := get_lastblock_header()
                lastBlock := get_block(lastBlockHeader.hash)
                txns := get_transactions(lastBlock.hashes)

AFTER

        on every scrape:

                lastBlockHeader := get_lastblock_header()

                cacheEntry, found := blocksCache.get(lastBlockHeader.hash)
                if found {
                        // we're good
                        return
                }

                lastBlock := get_block(lastBlockHeader.hash)
                txns := get_transactions(lastBlock.hashes)

note that get_transactions is  indeed solely used by the lastblock collector - transactionpool does not need it as the call to get_transaction_pool already returns the detailed information we need.
looking at rpc_access_tracking, we can tell get_transaction is indeed quite expensive atm
 ~ $ monero daemon rpc-access-tracking
RPC                             COUNT   TIME SPENT SERVING      CREDITS
get_version                     90      499.904µs               0
hard_fork_info                  46      611.606µs               46
get_alternate_chains            1       952.902µs               0
rpc_access_info                 416     1.807211ms              0
get_public_nodes                1       3.617268ms              0
get_txpool_backlog              81      11.612045ms             81
get_block_header_by_height      154     15.306969ms             154
get_block_headers_range         58      17.226973ms             58
get_net_stats                   12434   23.167619ms             0
get_outs                        21      31.506649ms             161
getblockcount                   8578    37.103013ms             0
get_outs_bin                    13      85.465299ms             3149
sync_info                       10      91.58133ms              20
get_bans                        8577    118.654689ms            0
send_raw_tx                     12      175.204242ms            1200
get_height<PHONE_NUMBER>38ms            0
rpc_access_tracking             14847   346.920509ms            0
get_hashes                      281     2.024486379s            5886
get_output_distribution_bin     13      2.359060579s            260
get_base_fee_estimate           8604    4.66403806s             8604
get_last_block_header           28780   46.608057363s           28780
get_peer_list                   12561   1m10.117860338s         0
get_block                       20159   1m31.193389823s         20159
get_blocks                      99032   2m30.302909893s         137586
get_transaction_pool_stats      20121   4m3.598594881s          20121
get_connections                 31671   4m27.280631191s         0
get_transaction_pool            11606   5m5.373659997s          513958
get_transaction_pool_hashes     98092   8m3.274738272s          131568
get_info                        65858   10m3.184014312s         65858
get_transactions                93120   37m27.277965493s        592453

how much of a big deal this is? well, not a lot

but, there's clearly an opportunity for improvements here


Add tutorial tweaks

Made some tweaks as I went through the tutorials.  Most of them were formatting and correcting a couple broken image links.
Signed-off-by: John Shepherd<EMAIL_ADDRESS>

I noticed that here  The code makes mention of the old and new way of doing things, but there is no difference in the code, I tried to look for the replacement line but wasn't quite sure what this section of code was in the ignition equivalent.


Show rows at gutter instead of as-editor's normal-text.

Pros

Easier to correspond narrowEditor's text to underlying editor's text.
When introduce inline-edit feature(Update bounded-editor's text by editing narrowEditor.)

Cons

When copying, no longer copy rows(possibly, sometimes useful to share row info to other person).

Changed my mind.


Could not determine type of stream

A good day to you,
When using my own oauth clientid, and "Hi resolution", Strawberry complaints with "Could not determine type of stream".
This does not happen if using a working API token.
On terminal, i get the logs down below for that error.
Any advise ?
06:36:22.064 DEBUG MainWindow:1002                  Started QThread(0x55db3ab85c80) 06:36:22.076 INFO  DeviceManager:442                Device added: "Gio/unmounted/140704806428704" ("Gio/unmounted/140704806428704") 06:36:29.829 DEBUG MainWindow:1300                  Song changed to "Sandi Patty" "Everlasting" "God & King" 06:36:29.853 DEBUG MusixmatchLyricsProvider:88      MusixmatchLyrics: Sending request for "sandi-patty" "god-king" QUrl("https://www.musixmatch.com/lyrics/sandi-patty/god-king") 06:36:29.854 DEBUG PlaylistBackend:336              Saving playlist 39 06:36:29.854 DEBUG Player:349                       URL handler for QUrl("tidal:29344511") is loading asynchronously 06:36:30.176 DEBUG LoloLyricsProvider:148           LoloLyrics: No lyrics for "Sandi Patty" "God & King" "Error transferring http://api.lololyrics.com/0.5/getLyric?artist=Sandi Patty&track=God %26 King - server replied: Not Found (203)" 06:36:30.388 ERROR MusixmatchLyricsProvider:223     MusixmatchLyrics: "Json lyrics is missing body." 06:36:30.388 DEBUG MusixmatchLyricsProvider:224     QVariant(QJsonObject, QJsonObject()) 06:36:30.388 DEBUG MusixmatchLyricsProvider:211     MusixmatchLyrics: No lyrics for "Sandi Patty" "God & King" 06:36:30.397 DEBUG Player:275                       URL handler for QUrl("tidal:29344511") returned QUrl("http://en-pr-fa.audio.tidal.com/v2/0/d2d660857483f289c2b39752ca2816b9_26.flac?token=1604752590~MDhmYzAzNWZmZDU5ZjE5Yzk0OGY1ZjNkMzBlNmE4ZTIwY2E2YWI0ZA==") 06:36:30.397 DEBUG Player:336                       Playing song "God & King" QUrl("http://en-pr-fa.audio.tidal.com/v2/0/d2d660857483f289c2b39752ca2816b9_26.flac?token=1604752590~MDhmYzAzNWZmZDU5ZjE5Yzk0OGY1ZjNkMzBlNmE4ZTIwY2E2YWI0ZA==") 06:36:30.400 INFO  GstEnginePipeline:366            Setting buffer duration:<PHONE_NUMBER> low watermark: 0.33 high watermark: 0.99 06:36:30.405 DEBUG logging:83(GLib-GIO)             _g_io_module_get_default: Found default implementation dconf (DConfSettingsBackend) for ‘gsettings-backend’ 06:36:30.407 DEBUG logging:83(GLib-GIO)             _g_io_module_get_default: Found default implementation libproxy (GLibproxyResolver) for ‘gio-proxy-resolver’ 06:36:30.408 DEBUG logging:83(GLib-GIO)             _g_io_module_get_default: Found default implementation gnutls (GTlsBackendGnutls) for ‘gio-tls-backend’ 06:36:30.489 DEBUG AuddLyricsProvider:140           AudDLyrics: Got lyrics for "Sandi Patty" "God & King" 06:36:30.667 DEBUG OVHLyricsProvider:105            OVHLyrics: Got lyrics for "Sandi Patty" "God & King" 06:36:30.667 DEBUG LyricsFetcherSearch:129          Using lyrics from "AudD" for "Sandi Patty" "God & King" with score 1.5 06:36:30.815 ERROR GstEnginePipeline:852            ErrorMessageReceived ID: 1 Domain: 4051 Code: 4 Error: "Could not determine type of stream." 06:36:30.815 ERROR GstEnginePipeline:853            ErrorMessageReceived ID: 1 Domain: 4051 Code: 4 Debug: "../gstreamer/plugins/elements/gsttypefindelement.c(999): gst_type_find_element_chain_do_typefinding (): /GstPlayBin:playbin-0/GstURIDecodeBin:uridecodebin0/GstTypeFindElement:typefindelement1" 06:36:30.815 ERROR GstEngine:563                    GStreamer error: 4051 4 "Could not determine type of stream." 06:36:30.815 ERROR GstEnginePipeline:852            ErrorMessageReceived ID: 1 Domain: 4051 Code: 1 Error: "Internal data stream error." 06:36:30.815 ERROR logging:72(GLib)                 Source ID 21 was not found when attempting to remove it 06:36:30.815 ERROR GstEnginePipeline:853            ErrorMessageReceived ID: 1 Domain: 4051 Code: 1 Debug: "../gstreamer/libs/gst/base/gstbasesrc.c(3127): gst_base_src_loop (): /GstPlayBin:playbin-0/GstURIDecodeBin:uridecodebin0/GstSoupHTTPSrc:source:\nstreaming stopped, reason error (-5)" 06:38:17.873 DEBUG Database:489                     Starting database integrity check 06:38:17.943 DEBUG Database:550                     Starting database backup 06:42:07.713 DEBUG GlobalShortcutsSettingsPage:121  Gnome (GSD) D-Bus backend is unavailable. 06:42:07.713 DEBUG GlobalShortcutsSettingsPage:126  X11 backend is available.

Hi there @fiercebrake!
 GStreamer error: 4051 4 "Could not determine type of stream."

This doesn't seem like an error coming from strawberry, would be able to post some code to reproduce this? :)

Hi there @fiercebrake!
 GStreamer error: 4051 4 "Could not determine type of stream."

This doesn't seem like an error coming from strawberry, would be able to post some code to reproduce this? :)

Sure, let me know what you would require

@fiercebrake I checked the issue better, and it seems that maybe you're in the wrong repo?
Are you this maybe? https://github.com/strawberrymusicplayer/strawberry

Ah! my apologies
yes indeed I am in the wrong repo, sorry about that


Add SegmentAllocationQueue to batch allocation actions

Description
In a cluster with a large number of streaming tasks (~1000), SegmentAllocateActions on the overlord can often take very long intervals of time to finish thus causing spikes in the task/action/run/time. This may result in lag building up while a task waits for a segment to get allocated.
The root causes are:

large number of metadata calls made to the segments and pending segments tables
giant lock held in TaskLockbox.tryLock() to acquire task locks and allocate segments

Since the contention typically arises when several tasks of the same datasource try to allocate segments for the same interval/granularity, the allocation run times can be improved by batching the requests together.
Changes
Broad strokes

Add flags

druid.indexer.tasklock.batchSegmentAllocation (default false)
druid.indexer.tasklock.batchAllocationMaxWaitTime (in millis) (default 1000)

Put a bound on the amount of time an allocation action can take by configuring the batchAllocationMaxWaitTime
Add SegmentAllocationQueue to queue and batch allocate actions
Identify a batch uniquely with these fields

dataSource
groupId
preferredAllocationInterval
skipSegmentLineageCheck
useNonRootGenerationPartitionSpace (as a proxy for PartialShardSpec.getClass())
lockGranularity

Metadata calls are now batched
giant lock is acquired just once per batch per tryInterval in TaskLockbox
Rest of the behaviour (order of steps, retries, etc.) in the new flow remains exactly the same as the old flow

Adding a request

Add methods canPerformAsync and performAsync to TaskAction
performAsync currently throws an UnsupportedOperationException for other action types
Submit each allocate action to a SegmentAllocationQueue
Add the action to a batch and execute it when it is due

Processing a request batch

Wait for maxWaitTimeMillis before processing a batch
Send all requests in the batch to TaskLockbox to acquire task locks and allocate segments
Respond to leadership changes and fail items in queue when not leader
Emit batch and request level metrics

Allocating segments

Add TaskLockbox.allocateSegments() retaining the logic from TaskLockbox.tryLock()
Add IndexerMetadataStorageCoordinator.allocatePendingSegments() retaining the logic from allocatePendingSegment()

New metrics
Per batch (dims: dataSource, taskActionType=segmentAllocate):

task/action/batch/runTime
task/action/batch/queueTime
task/action/batch/size
task/action/batch/attempts

Per request (dims: taskId, taskType, dataSource, taskActionType=segmentAllocate):

task/action/failed/count
task/action/success/count

Pending changes

Docs for metrics
Perf eval of new flow against old flow

Further improvements

An improvement could be to free up the HTTP threads on which the request is received by using
HttpServletRequest.startAsync.
There are some metadata queries which have not been batched such as updating the
acquired task lock in the metadata store and fetching a matching pending when skipLineageCheck = false.

Release note
Speed up segment allocation and reduce metadata calls by clubbing multiple requests together.
Set druid.indexer.tasklock.batchSegmentAllocation=true to enable this feature.

This PR has:

[ ] been self-reviewed.

[ ] using the concurrency checklist (Remove this item if the PR doesn't have any relation to concurrency.)

[ ] added documentation for new or modified features or behaviors.
[x] a release note entry in the PR description.
[x] added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links.
[ ] added or updated version, license, or notice information in licenses.yaml
[ ] added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
[x] added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.
[ ] added integration tests.
[ ] been tested in a test Druid cluster.

One note : While I thought that batching was probably the way to go earlier, probably it could be re-considered in favour of caching and combining it with more parallelism if that's easier. The current batching idea also caches data in memory for pendingSegments table and updates the in-memory state for all requests in a batch to resolve their partition-num assignment conflict.
In a local experiment, I was trying the following :

Add striped locking for (datasource, interval, sequence name) tuple in allocatePendingSegment method
The createNewSegment method is the critical section which requires a global lock, but it operates on cached results of pendingSegments table. The cache could be for key (datasource, interval) and gets invalidated with time, access-count or some transaction failure while committing to pendingSegments table
The write to pendingSegments table is also done in the striped lock
More things could be extracted from createNewSegment (like fetching used segments) to the striped locking flow so that there's more parallelism
Generally, the idea was to do DB calls in parallel threads and use cached objects in the global lock.

@AmatyaAvadhanula , @abhishekagarwal87 , thanks for the review. I have addressed your feedback.
Changes made:

Queue polling is now always active irrespective of being leader or not. This can be improved later if needed.
Queue polling starts on lifecycle start and not on becoming leader.
A future now either completes successfully or exceptionally, i.e. it never completes with null. This allows propagation of actual error message to the caller. Added tests for this.
Clarify usage of committedMaxId in the set of pendingSegments
Rename metric batch/retries to batch/attempts

Changes in follow up PR:

docs (mostly just metrics)
cleanup of empty locks from posse map (both old and new flow)
limit number of requests in each batch
cancel the future if it times out on LocalTaskActionClient

All unit and integration tests have run successfully with segment allocation enabled in test PR #13484 .
There was only one flaky test. I couldn't retry that test due to some Travis access issues.

Merging as build is green. Latest commit is only comment change.


⚠ ClamAV has degraded performance

In 749ff03, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 70 ms

Resolved: ClamAV performance has improved in 0bd9ec2 after 14 minutes.


Dimmer doesn't show correct % with beta 3.1

Issue description
Dimmer doesn't show correct % with beta 3.1
Additional information
Zigbee2MQTT version: v.1.21.1 (zStack12 20190608)
Python version: 2.7.16
Domoticz version: 2021.1 (build 13499)
Plugin version: Zigbee2MQTT Plugin (v. 3.1.0-beta)
Left production Domoticz with old version of the plugin right clean Domoticz install on a different PI with beta 3.1

Logs
Attach any additional logs here which might be useful: mqtt, domoticz, plugin logs

Same issue here. Moves back to 0% right after I change it to any %

Could you please post several MQTT messages with the data your receive for this device?
Also, are there anything useful in the Domoticz log when you enable plugin debug mode?

I did see it  by a clean installation. Didn't try it on my production system.
Zigbee2mqtt log
Info MQTT publish: topic 'zigbee2mqtt/links_achter_dimmer', payload '{"brightness":134,"state":"ON"}' Info MQTT publish: topic 'zigbee2mqtt/Ikea 400lm 1', payload '{"brightness":134,"last_seen":"2021-09-20T21:28:32+02:00","linkquality":75,"power_on_behavior":null,"state":"ON","update":{"state":"idle"},"update_available":false}' Info MQTT publish: topic 'zigbee2mqtt/woonkamer_dimmer', payload '{"brightness":134,"state":"ON"}' Info MQTT publish: topic 'zigbee2mqtt/links_achter_dimmer', payload '{"brightness":134,"state":"ON"}' Info MQTT publish: topic 'zigbee2mqtt/Ikea 400lm 1', payload '{"brightness":134,"last_seen":"2021-09-20T21:28:32+02:00","linkquality":75,"power_on_behavior":null,"state":"ON","update":{"state":"idle"},"update_available":false}' Info MQTT publish: topic 'zigbee2mqtt/woonkamer_dimmer', payload '{"brightness":134,"state":"ON"}' Info MQTT publish: topic 'zigbee2mqtt/Tuin Rechts 2', payload '{"brightness":63,"last_seen":"2021-09-20T21:28:35+02:00","linkquality":63,"state":"ON","update":{"state":"available"},"update_available":true}'
Domoticz log
2021-09-20 21:27:57.004 ZigBee 2 MQTT: (ZigBee 2 MQTT) Command "Set Level" from device "Ikea 400lm 1 (Light)" 2021-09-20 21:27:57.005 ZigBee 2 MQTT: (ZigBee 2 MQTT) MqttClient::publish zigbee2mqtt/Ikea 400lm 1/set ({"state": "ON", "brightness": 101}) 2021-09-20 21:27:58.912 ZigBee 2 MQTT: (ZigBee 2 MQTT) [Command] Device 0x000d6ffffefd10de(1): Off(level = 0, color = ) 2021-09-20 21:27:58.939 ZigBee 2 MQTT: (ZigBee 2 MQTT) Command "Off" from device "Ikea 400lm 2 (Light)" 2021-09-20 21:27:58.940 ZigBee 2 MQTT: (ZigBee 2 MQTT) MqttClient::publish zigbee2mqtt/Ikea 400lm 2/set ({"state": "OFF"}) 2021-09-20 21:27:59.951 ZigBee 2 MQTT: (ZigBee 2 MQTT) [Command] Device 0x000d6ffffefd10de(1): On(level = 0, color = ) 2021-09-20 21:27:59.994 ZigBee 2 MQTT: (ZigBee 2 MQTT) Command "On" from device "Ikea 400lm 2 (Light)" 2021-09-20 21:27:59.994 ZigBee 2 MQTT: (ZigBee 2 MQTT) MqttClient::publish zigbee2mqtt/Ikea 400lm 2/set ({"state": "ON"}) 2021-09-20 21:28:02.071 ZigBee 2 MQTT: (ZigBee 2 MQTT) [Command] Device 0x000d6ffffefd10de(1): Set Level(level = 27, color = ) 2021-09-20 21:28:02.132 ZigBee 2 MQTT: (ZigBee 2 MQTT) Command "Set Level" from device "Ikea 400lm 2 (Light)" 2021-09-20 21:28:02.133 ZigBee 2 MQTT: (ZigBee 2 MQTT) MqttClient::publish zigbee2mqtt/Ikea 400lm 2/set ({"state": "ON", "brightness": 68}) 2021-09-20 21:28:06.302 ZigBee 2 MQTT: (ZigBee 2 MQTT) [Command] Device 0x000b3cfffef56a4b(1): Set Level(level = 48, color = ) 2021-09-20 21:28:06.363 ZigBee 2 MQTT: (ZigBee 2 MQTT) Command "Set Level" from device "lamp 2_1 (Light)" 2021-09-20 21:28:06.364 ZigBee 2 MQTT: (ZigBee 2 MQTT) MqttClient::publish zigbee2mqtt/lamp 2_1/set ({"state": "ON", "brightness": 121}) 2021-09-20 21:28:32.820 ZigBee 2 MQTT: (ZigBee 2 MQTT) [Command] Device 0x000d6ffffefd94fc(1): Set Level(level = 53, color = ) 2021-09-20 21:28:32.868 ZigBee 2 MQTT: (ZigBee 2 MQTT) Command "Set Level" from device "Ikea 400lm 1 (Light)" 2021-09-20 21:28:32.868 ZigBee 2 MQTT: (ZigBee 2 MQTT) MqttClient::publish zigbee2mqtt/Ikea 400lm 1/set ({"state": "ON", "brightness": 134})

looks like its related to my bugreport
https://github.com/stas-demydiuk/domoticz-zigbee2mqtt-plugin/issues/726

I can confirm similar behavior. When using domoticz gui to change dimmer level using the slider the level changes as desired, but the slider pops back to the previous position. It does work properly with non-zigbee dimmers in Domoticz and also when using the dashboard of zigbee2mqtt, so it seems to point at this plugin.
Side effect is also that groups containing zigbee devices do 'think' devices are still on, although they have been turned off which results in some scripts behaving oddly (no mixed status in those groups).
Updating this morning to #cf68507 did not fix it :-(.
Gr,
Bart

Raised the issue in Domoticz repository #5010, hopefully someone will be able to take a look

Should be fixed now, could you please update plugin and check

I updated the plugin, but issue persists.
Gr,
Bart

That sounds a bit odd, could you please double-check that you have the latest plugin version from the master branch

I know, I checked for the code changes to be present and they are. Updated it just now to #db397ad, but I still have the same issue. Will experiment with recreating devices.

Recreating device did not help I will experiment further. Happy Christmas!

My hunch is that I use I 'pure' dimmer (no colortemp) and I assume that in that case dimmer.py is involved and not ct.py and dimmer.py has not been touched. Will try to add code to dimmer.py when I find the correct spot.

I (too) crudely added "domoticz_device.LastLevel = Level" to plugin.py and with this it works (I did not yet manage to modify dimmer.py).
def onCommand(self, device_id, unit, command, Level, Color):
    domoticz.debug("[Command] Device " + device_id + '(' + str(unit) + '): ' + command + "(level = " + str(Level) + ", color = " + Color + ')')

    message = None
    domoticz_device = domoticz.get_device(device_id, unit)
    domoticz_device.LastLevel = Level
    zigbee_device_alias = configuration.get_zigbee_feature_data(device_id, unit)

I'm also having problems with regular dimmers not showing the actual dimmer value. I used the fix fromBartole, but this will only work when setting the dimmer slider manually. It still doesn't update the value when the dimmer is set by eg. the event system, or externally.
Is there anything I can do help to debug the issue?

Hi, looks like majority of zigbee dimmers are now showing the dim level correct in GUI. Not sure at which point this changed but very good 👍 😄
One item that still has the "old" behavior (dim level springs back to zero) are zigbee groups - at least my newly created _ct -group with IKEA GU10 bulbs. If I dim it, this shows in zigbee2mqtt logs:
Info MQTT publish: topic 'zigbee2mqtt/Autotallin etuseinä 1', payload '{"brightness":33,"color_mode":"color_temp","color_temp":333,"linkquality":0,"power_on_behavior":null,"state":"ON"}'
Info MQTT publish: topic 'zigbee2mqtt/Etuseinä_ct', payload '{"brightness":33,"color_mode":"color_temp","color_temp":333,"state":"ON"}'
Info MQTT publish: topic 'zigbee2mqtt/Autotallin etuseinä 2', payload '{"brightness":33,"color_mode":"color_temp","color_temp":333,"linkquality":60,"power_on_behavior":null,"state":"ON"}'
Info MQTT publish: topic 'zigbee2mqtt/Etuseinä 1 alas', payload '{"brightness":33,"color_mode":"color_temp","color_temp":333,"linkquality":3,"power_on_behavior":null,"state":"ON"}'
Info MQTT publish: topic 'zigbee2mqtt/Etuseinä 2 alas', payload '{"brightness":33,"color_mode":"color_temp","color_temp":333,"linkquality":12,"power_on_behavior":null,"state":"ON"}'
Info MQTT publish: topic 'zigbee2mqtt/Etuseinä 1 ylös', payload '{"brightness":33,"color_mode":"color_temp","color_temp":333,"linkquality":18,"power_on_behavior":null,"state":"ON"}'
Info MQTT publish: topic 'zigbee2mqtt/Etuseinä 2 ylös', payload '{"brightness":33,"color_mode":"color_temp","color_temp":333,"linkquality":30,"power_on_behavior":null,"state":"ON"}'
Info MQTT publish: topic 'zigbee2mqtt/Etuseinä 3 alas', payload '{"brightness":33,"color_mode":"color_temp","color_temp":333,"linkquality":66,"power_on_behavior":null,"state":"ON"}'
Info MQTT publish: topic 'zigbee2mqtt/Etuseinä 3 ylös', payload '{"brightness":33,"color_mode":"color_temp","color_temp":333,"linkquality":75,"power_on_behavior":null,"state":"ON"}'
Info MQTT publish: topic 'zigbee2mqtt/Etuseinä 4 alas', payload '{"brightness":33,"color_mode":"color_temp","color_temp":333,"linkquality":72,"power_on_behavior":null,"state":"ON"}'
Info MQTT publish: topic 'zigbee2mqtt/Etuseinä 4 ylös', payload '{"brightness":33,"color_mode":"color_temp","color_temp":333,"linkquality":18,"power_on_behavior":null,"state":"ON"}'
Info MQTT publish: topic 'zigbee2mqtt/Etuseinä 5 alas', payload '{"brightness":33,"color_mode":"color_temp","color_temp":333,"linkquality":0,"power_on_behavior":null,"state":"ON"}'
Info MQTT publish: topic 'zigbee2mqtt/Etuseinä 5 ylös', payload '{"brightness":33,"color_mode":"color_temp","color_temp":333,"linkquality":0,"power_on_behavior":null,"state":"ON"}'
Info MQTT publish: topic 'zigbee2mqtt/Etuseinä_alas_ct', payload '{"brightness":33,"color_mode":"color_temp","color_temp":333,"state":"ON"}'
Info MQTT publish: topic 'zigbee2mqtt/Etuseinä_ylös_ct', payload '{"brightness":33,"color_mode":"color_temp","color_temp":333,"state":"ON"}'

The individual devices (bulbs) go to and remain on correct dim level, but the group device dim level goes back to 0.
@stas-demydiuk

Hopefully now should be fixed for regular dimmers as well. Could someone please upgrade the plugin and check

Hi, I did a git pull and should be in the latest version. Also restarted Domoticz, cleared caches etc. Still the behavior of the zigbee _ct group at least is the same. Dimming level is not visible on the GUI.

Should I update zigbee2mqtt bridge to latest version as well (it is not updated for at least a few weeks)?

@odelma, are you talking about dimers related to zigbee groups or regular dimmers from actual devices?

Hi, sorry for being unclear. This was about a zigbee group of _ct devices. Regular zigbee dimmers are working ok in my setup but this group is not reflecting the set dim status. I think the info is available in mqtt messages, e.g.
MQTT publish: topic 'zigbee2mqtt/Etuseinä numero_ct', payload '{"brightness":81,"color_mode":"color_temp","color_temp":294,"state":"ON"}'
I thought it was in general about the same issue mentioned here, but would have been more clear to open a separate issue of course...

Raspbian Buster, kernel 5.10.63-v7+
Domoticz 2022.1 build 14161
Python 3.7.3
Zigbee2MQTT plugin v. 3.1.0-beta (#46839db)
Zigbee2MQTT 1.23.0 (#6ea61ba)
To add information and hopefully not confuse more... Zigbee dimmers (those added by the Z2M plugin) are now keeping their new dimlevel when changed, so that is good!
I still observed something that is not working as expected and maybe it is related or it may be a completely new issue.
Observation: Status of group/scene with two Z2M plugin dimmers does not get updated when individually switching dimmers inside the group (on, off or mixed). It keeps the status it had before.
Expected behavior:

Group/scene gets 'mixed' status if one dimmer is on and the other is off.
Group/scene get 'on' status when both dimmers are on
Group/scene get 'off' status when both dimmers are off

Testing the same with dummy device dimmers does have the expected behavior.

What @Bartole above explains, corresponds to my obesrvations in previous posts under this issue (e.g. https://github.com/stas-demydiuk/domoticz-zigbee2mqtt-plugin/issues/714#issuecomment-1031169992). So zigbee groups are still having the odd behavior of not reflecting the dim level (or color picker / color temp). Not sure if it is related, I also observed that when group status is changed from Domoticz group device, it control all the lights in the group correctly in real life and in Zigbee2Mqtt dashboard, but in Domoticz the status of all lights in the group is not updating.

@odelma / @Bartole, I've pushed a fix, hopefully that will help

@odelma / @Bartole, I've pushed a fix, hopefully that will help

Excellent 👍 I can verify on mybehalf it is working as expected now - even with zigbee groups.

@stas-demydiuk - sorry to come back to this but I noticed one additional device, ”blinds percentage” which does not show the correct level in GUI.


Fix date issue

This will just actually error when we hit the limit - we should figure out a better way to do this, but for now I've deleted some old files to get us under the limit.
I think we should store longer copies of the data for later processing in some smart way - right now we can only keep around about a month's worth of data before querying hits the 1000 item limit, and in any case that gets awkward over 1000 generally
Linked in the code, docs about 1000: http://docs.aws.amazon.com/AmazonS3/latest/API/RESTBucketGET.html

LGTM (after Slack discussion)