Re: [BUG] LOGBOOK makes property search (in org-agenda) too slow(?)
are there intereim workarounds like semi-automatically moving large logbook entries, or entire logbooks, to a task that says "was logbook for ..." and then archiving that task? or automatically archiving old logbook entries? On 3/12/22, Ihor Radchenko wrote: > "fr...@t-online.de" writes: > >> I have just one headline and do a simple property search (prop1="blah1") >> for the 'org-agenda', but this takes about 10 seconds! > > Thanks for providing a reproducible example! We know about this > performance issue. Performance has been improved in the development > version of Org (not released yet). Using your example, agenda generation > is instant on main. > > Best, > Ihor > > -- The Kafka Pandemic A blog about science, health, human rights, and misopathy: https://thekafkapandemic.blogspot.com
Re: [PATCH] Fix FAQ entry about mailto links.
Sorry for the noise. Another attempt to remove the record from https://updates.orgmode.org Canceled. Another variant based on https://list.orgmode.org/9437ade2-af18-f97e-8790-a2df27c90...@gmail.com has been committed. On 07/01/2022 01:34, Robert Goldman wrote: The old entry referred to the variable =org-link-mailto-program= which was removed from org-mode almost eight years ago! See org-mode commit b9f2e17f07faf01109fc6f7f1eb5a34e0f97eafb --- org-faq.org | 18 +++--- 1 file changed, 15 insertions(+), 3 deletions(-)
Re: [BUG] Scheduled task shows up wrong day in agenda [9.5.2 (release_9.5.2-22-g33543d @ /usr/local/share/emacs/29.0.50/lisp/org/)]
Ihor Radchenko writes: > Can you try to update Emacs? From my experience, there are sometimes > cryptic issues in Org, which disappear as you update Emacs from more > recent master. Per your advice I uninstalled, grabbed all source files and rebuilt from scratch. Result: testcase running under "emacs -Q" passes OK now, don't see Scheduled task shows up wrong day in agenda.
[BUG] Resolving idle clocks needs multiple keystrokes [9.5.2 (release_9.5.2-24-g668205 @ /home/ignacio/repos/emacs/lisp/org/)]
Hello, > CONTEXT: When I'm idling with the clock running, Org asks if I want > to resolve the clock when I come back (this is by setting > org-clock-idle-time). > > PROBLEM: I'm not sure how recent the change was, but Org started > asking me _multiple times_ what I want to do when back. I have this problem, already reported but not solved in these threads and maybe others: https://lists.gnu.org/archive/html/emacs-orgmode/2019-02/msg00333.html, https://lists.gnu.org/archive/html/emacs-orgmode/2010-08/msg00188.html. I have investigated a little and it seems that there is a timer that calls org-resolve-clocks-if-idle every minute, and if (org-user-idle-seconds) is greater than 60*org-clock-idle-time, that function prompts the user to resolve the clock. The problem is that this prompt blocks Emacs, and if you are idle (org-clock-idle-time + N) minutes, the other N scheduled calls to org-resolve-clocks-if-idle occur immediately after answering the prompt. But for some reason (a bug?), answering the prompt does not affect (org-user-idle-seconds), so the prompt appears again, and you have to answer it N times (unless your answer was to cancel the clock or clock out). So the problem is in (org-user-idle-seconds), which in my window system boils down to a call to (current-idle-time). It should return 0 after answering the prompt, but in my system it keeps counting up. At this point I stopped investigating since that function is defined in C. Since this bug is already old and I have not found much information about it, I assume that in most systems answering the prompt does reset the idle timer and this bug does not occur. As a quick fix for those systems where this is an issue, we could reset the idle timer ourselves after the prompt in org-resolve-clocks-if-idle. What do yo think? Emacs : GNU Emacs 29.0.50 (build 9, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0) of 2022-03-11 Package: Org mode version 9.5.2 (release_9.5.2-24-g668205 @ /home/ignacio/repos/emacs/lisp/org/)
Re: [PATCH v3] Fix FAQ entry about mailto links.
On 25/02/2022 19:20, Max Nikulin wrote: I pushed the patch without comment block. I decided to suggest `org-link-set-parameters' instead of customization of `org-link-parameters'. See updated variant at https://orgmode.org/worg/org-faq.html#mailto-links. This patch should be removed from the list of pending ones on https://updates.orgmode.org/ so Applied
Re: [BUG] Scheduled task shows up wrong day in agenda [9.5.2 (release_9.5.2-22-g33543d @ /usr/local/share/emacs/29.0.50/lisp/org/)]
Jeffrey DeLeo writes: > Save "foobar.org" and "testcase_startup.el" into a directory. Start > emacs in that directory as "emacs -Q -l testcase_startup.el". When emacs > comes up, hit "a" to get agenda. > > "foobar.org" has one task scheduled for Sunday. When I write this, it is > Saturday. Task is displayed in agenda for Saturday. > > Happy to investigate myself if you have suggestions of things I can look > at to track this down. > > (org-version) > "9.5.2" > > (emacs-version) > "GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo > version 1.16.0) > of 2022-03-09" I followed your steps and I got the following: Week-agenda (W10): Monday 7 March 2022 W10 Tuesday 8 March 2022 Wednesday 9 March 2022 Thursday 10 March 2022 Friday 11 March 2022 Saturday 12 March 2022 Sunday 13 March 2022 foobar: Scheduled: TODO Something I do not see any problem with agenda. M-x org-version Org mode version 9.5.2 (release_9.5.2-9-g7ba24c @ /usr/share/emacs/29.0.50/lisp/org/) M-x emacs-version GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, cairo version 1.16.0) of 2022-01-29 Can you try to update Emacs? From my experience, there are sometimes cryptic issues in Org, which disappear as you update Emacs from more recent master. Best, Ihor
Re: [BUG] Scheduled task shows up wrong day in agenda [9.5.2 (release_9.5.2-22-g33543d @ /usr/local/share/emacs/29.0.50/lisp/org/)]
Ihor Radchenko writes:
>
> I am unable to reproduce using built-in Org version of my own Emacs
> build (GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, cairo version
> 1.16.0) of 2022-01-29).
>
> Can you provide more details steps to reproduce starting from emacs
> -Q?
Sure.
Save "foobar.org" and "testcase_startup.el" into a directory. Start
emacs in that directory as "emacs -Q -l testcase_startup.el". When emacs
comes up, hit "a" to get agenda.
"foobar.org" has one task scheduled for Sunday. When I write this, it is
Saturday. Task is displayed in agenda for Saturday.
Happy to investigate myself if you have suggestions of things I can look
at to track this down.
(org-version)
"9.5.2"
(emacs-version)
"GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo
version 1.16.0)
of 2022-03-09"
load-path:
("/usr/local/share/emacs/29.0.50/lisp"
"/usr/local/share/emacs/29.0.50/lisp/vc"
"/usr/local/share/emacs/29.0.50/lisp/url"
"/usr/local/share/emacs/29.0.50/lisp/textmodes"
"/usr/local/share/emacs/29.0.50/lisp/progmodes"
"/usr/local/share/emacs/29.0.50/lisp/play"
"/usr/local/share/emacs/29.0.50/lisp/org"
"/usr/local/share/emacs/29.0.50/lisp/nxml"
"/usr/local/share/emacs/29.0.50/lisp/net"
"/usr/local/share/emacs/29.0.50/lisp/mh-e"
"/usr/local/share/emacs/29.0.50/lisp/mail"
"/usr/local/share/emacs/29.0.50/lisp/leim"
"/usr/local/share/emacs/29.0.50/lisp/language"
"/usr/local/share/emacs/29.0.50/lisp/international"
"/usr/local/share/emacs/29.0.50/lisp/image"
"/usr/local/share/emacs/29.0.50/lisp/gnus"
"/usr/local/share/emacs/29.0.50/lisp/eshell"
"/usr/local/share/emacs/29.0.50/lisp/erc"
"/usr/local/share/emacs/29.0.50/lisp/emulation"
"/usr/local/share/emacs/29.0.50/lisp/emacs-lisp"
"/usr/local/share/emacs/29.0.50/lisp/cedet"
"/usr/local/share/emacs/29.0.50/lisp/calendar"
"/usr/local/share/emacs/29.0.50/lisp/calc"
"/usr/local/share/emacs/29.0.50/lisp/obsolete")
* Tasks
** TODO Something
SCHEDULED: <2022-03-13 Sun>
testcase_startup.el
Description: application/emacs-lisp
Re: Bug: org-agenda search is slow on Windows 10 [9.4.4 (release_9.4.4 @ c:/Program Files/Emacs/x86_64/share/emacs/27.2/lisp/org/)]
Robert Mastragostino writes: > Hello, > > Org-agenda search is being unreasonably slow, taking several seconds to > search through ~100 small files (a simple python program is practically > instantaneous). I'm not familiar with proper emacs profiling but pausing in > the middle of the search essentially always gives the stack trace below, > where some recursion attempting to figure out file names is waiting on > w32-long-file-name. > > I've also attached my init.el, though as far as I can tell this isn't > interference from another package. We have significantly improved Org mode performance on development (main) branch. AFAIU, 100 small files should not be an issue on latest Org. Best, Ihor
Re: [BUG] Scheduled task shows up wrong day in agenda [9.5.2 (release_9.5.2-22-g33543d @ /usr/local/share/emacs/29.0.50/lisp/org/)]
Jeffrey DeLeo writes: > Single org file "foobar.org", containing one task scheduled for > Sunday. It is displayed on agenda for Saturday. I build my own emacs, > which includes org, on OS Ubuntu 20.04. > > foobar.org contents: > > * Tasks > ** TODO Something > SCHEDULED: <2022-03-06 Sun> > > Agenda Displays: > > Day-agenda (W09): > Saturday5 March 2022 > foobar: Scheduled: TODO Something > > > > Emacs : GNU Emacs 29.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version > 3.24.20, cairo version 1.16.0) > of 2022-02-28 > Package: Org mode version 9.5.2 (release_9.5.2-22-g33543d @ > /usr/local/share/emacs/29.0.50/lisp/org/) I am unable to reproduce using built-in Org version of my own Emacs build (GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, cairo version 1.16.0) of 2022-01-29). Can you provide more details steps to reproduce starting from emacs -Q? Best, Ihor
Re: [BUG] org-element--cache: (nil) Cached element is incorrect in test3.org. (Cache tic up to date: "yes") Resetting. [9.6 (9.6-??-0c9b30e @ /Users/hamid/.emacs.d/.local/straight/build-27.2/org/)]
Thanks for the report! You are using a 3 month old version of Org. Could you update Org to latest main and let us know if the warning appears again? Best, Ihor
Re: [BUG] error after reading in contents of other file [9.6 (9.6-??-e7ea951 @ /home/user/.emacs.d/.local/straight/build-28.0.50/org/)]
Mark Edgington writes: > I manually opened a new daily file, and read in some content from > another file (using ':r filename.txt' with Evil). After doing this, the > content was inserted, but the following traceback occurred: > > Warning (org-element-cache): org-element--cache: Org parser error in > 2022-03-10.org::193. Resetting. > The error was: (error "Invalid search bound (wrong side of point)") Thanks for the report! Are you still seeing the traceback if you update Org to latest main? 5da9d6810 in more recent versions should help with some cases when the error like in your backtrace appears. Best, Ihor
Re: Problems with babel reading Japanese paths in Windows
Jonathan Nogueira writes: > Hi all, > > I've been working with emacs and org on Windows 10.0.19042 and was recently > trying to get babel to produce plantuml diagrams. > > I've managed to (I think) narrow the issue down to Babel either not being > able to read/write Japanese paths to shell commands, as when I attempt to > build the diagrams in folders with only ASCII paths, they build fine, but > when babel attempts to execute any source code for paths that contain > Japanese characters, babel gives back the cmd error "The System Cannot Find > the Path Specified." I do not use Windows, but I recall somewhat relevant discussion on planuml recently: https://orgmode.org/list/5d7eba13-b717-a12a-5f89-7d2c94149...@gmail.com It seems that plantuml might have some issues with UTF unless you pass relevant command line args. Did you try to run plantuml manually from windows cmd using the problematic path? Best, Ihor
Re: [BUG] LOGBOOK makes property search (in org-agenda) too slow(?)
"fr...@t-online.de" writes: > I have just one headline and do a simple property search (prop1="blah1") > for the 'org-agenda', but this takes about 10 seconds! Thanks for providing a reproducible example! We know about this performance issue. Performance has been improved in the development version of Org (not released yet). Using your example, agenda generation is instant on main. Best, Ihor
Re: [BUG] Agenda no longer works for timestamps inside properties drawer [9.5.2 (release_9.5.2-24-g668205 @ /home/ignacio/repos/emacs/lisp/org/)]
Ignacio Casso writes: > In Emacs 27.2, with an up to date version of org from ELPA (9.5.2), > org-agenda considers timestamps that appear in property drawers, so the > entry below appears in the daily agenda view. > > * Heading > :PROPERTIES: > :timestamp: <2022-03-12 sáb> > :END: > > However, in the latest Emacs version built from source (29.0.50), with > the built-in version of org (also 9.5.2, but the latest release, I > assume), this is no longer the case and that entry does not appear in > the agenda view. > > I know that maybe it's unorthodox, but I have some org files that rely > in the previous behavior, with entries like the following: > > * Some friend > :PROPERTIES: > :birth-date: <1994-03-12 sáb +1y> > :END: > > Is this a bug? If it's not, can someone point me to the functions I need > to touch to restore the previous behavior? Or maybe I should stop doing > this and start moving those timestamps out of the properties drawer in > my files? What you see in the new Org version is not a bug. Property values are treated as plain text by Org. In the older versions, agenda code did not rely on Org's internal parsing and matched timestamps in places where timestamps are not allowed (inside code blocks, for example). See https://orgmode.org/list/20220101122409.ga29...@itccanarias.org Dear all, I was unable to find a place in manual describing that timestamps cannot be placed inside property values: >> A timestamp is a specification of a date (possibly with a time or a >> range of times) in a special format, either ‘<2003-09-16 Tue>’ or >> ‘<2003-09-16 Tue 09:39>’ or ‘<2003-09-16 Tue 12:00-12:30>’(1). A >> timestamp can appear anywhere in the headline or body of an Org tree >> entry. Its presence causes entries to be shown on specific dates in the >> agenda (see *note Weekly/daily agenda::). We distinguish: I personally see allowing timestamps (and links) inside property values as a useful feature. Would it be of interest for other users? In any case, we should probably clarify manual in this regard. Best, Ihor
Re: [PATCH] org-protocol.org: updated Linux setup (Gnome) section
Applied ...with some minor tweaks (let me know if you do not like them). Thank you. https://orgmode.org/worg/org-contrib/org-protocol.html has been updated. On 12/03/2022 02:37, Wilko Meyer wrote: As the XDG Desktop Entry Specification should be a de facto standard by now, adding a new universal GNU/Linux section seems to be a good idea. It should work with KDE and other DEs as well (though I have only tested Mate and Gnome 3 so far). It is a burden to test such issues. A bunch of virtual machines helps, but it is necessary to start from clean user profiles each time. I can not suggest a better category, e.g. Utility is hardly better that System, but it is not really a system application as well. Having considered this I'd advocate to use the "Other" category here. Utility or System would make sense as well, but as users most likely won't interact with said .desktop entry via their application menu, it probably would be beneficial to put it in a more generic place. I do not see "Other" in https://specifications.freedesktop.org/menu-spec/latest/apa.html but it caused appearance of the new section (even with localized name) in KDE, so it works fine. Agreed. Something I'm unsure of is, wether using the update-desktop-database command can be seen as universal. It is part of the package desktop-file-utils in arch linux (emacs has it as a dependency, so it'll be installed anyways) but I cannot see KDE/plasma depending on it. In kubuntu kubuntu-desktop meta-package recommends desktop-file-utils. Anyway with your changes the page is more helpfil than it was before. In a minimal container xdg-open fallback functions are able to find .desktop file without updating of MIME types cache. Sometimes I just add x-scheme-handler/org-protocol=org-protocol.desktop to [Default Applications] or [Added Associations] section in ~/.config/mimeapps.list to make firefox aware of it. Unfortunately shipped emacsclient.desktop is not suitable to just recommend to adjust the mimeapps.list file. Have you managed to adjust emacs server or general buffer settings to ensure new graphical frame (on the same virtual desktop) in such cases? I haven't put much thought into this yet. I ran a quick test by starting firefox from command line and tried bookmarking a random page via org-capture. It seems that your approach is more productive. I tried to get more experience (e.g. I know that an attempt to select the emacsclient executable file in firefox as a custom handler leads to a silent failure when the browser is installed as a snap package that is new default in Ubuntu) so I believed that I am not ready yet to update the recipes.
Re: Cannot link to files with no extension
> Nick Dokos writes:
> Nick Dokos writes:
>> Check also the value of the system-specific variable
>> `org-file-apps-{gnus,windowsnt,macos}' - whichever is applcible
>> to your case.
> That should be `org-file-apps-{gnu,windowsnt,macos}'. -- Nick
> "There are only two hard problems in computer science: cache
> invalidation, naming things, and off-by-one errors." -Martin
> Fowler
It turns out I was clicking the wrong mouse button. On my setup, the
right-hand mouse button opens files 'b' and 'b.',
whereas the left-hand button only opens links to 'b.'. I was
not aware that the behaviour of org-mode links was mouse-button
dependent.
Best wishes,
[BUG] Agenda no longer works for timestamps inside properties drawer [9.5.2 (release_9.5.2-24-g668205 @ /home/ignacio/repos/emacs/lisp/org/)]
Hello, In Emacs 27.2, with an up to date version of org from ELPA (9.5.2), org-agenda considers timestamps that appear in property drawers, so the entry below appears in the daily agenda view. * Heading :PROPERTIES: :timestamp: <2022-03-12 sáb> :END: However, in the latest Emacs version built from source (29.0.50), with the built-in version of org (also 9.5.2, but the latest release, I assume), this is no longer the case and that entry does not appear in the agenda view. I know that maybe it's unorthodox, but I have some org files that rely in the previous behavior, with entries like the following: * Some friend :PROPERTIES: :birth-date: <1994-03-12 sáb +1y> :END: Is this a bug? If it's not, can someone point me to the functions I need to touch to restore the previous behavior? Or maybe I should stop doing this and start moving those timestamps out of the properties drawer in my files? Regards, Ignacio Emacs : GNU Emacs 29.0.50 (build 9, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0) of 2022-03-11 Package: Org mode version 9.5.2 (release_9.5.2-24-g668205 @ /home/ignacio/repos/emacs/lisp/org/)
Re: [BUG] LOGBOOK makes property search (in org-agenda) too slow(?)
> "fmd" == fr ml@t-online de writes: fmd> I have just one headline and do a simple property search fmd> (prop1="blah1") for the 'org-agenda', but this takes about 10 fmd> seconds! Org versions from recent years don’t like large logbooks and don’t like large files. For agenda, org-super-agenda & org-ql provide solution, they are generally much faster, don’t suffer from the logbook problem and are also much powerful. For other purposes, it can be more difficult. For example, I had to split my single org-drill file into multiple smaller files when editing and using the file became unusable due to Org slowness in some new Org version. The increasing Org slowness is a limiting factor (and perhaps the only limiting factor) of what can be done with Org. Regards, Milan
[BUG] LOGBOOK makes property search (in org-agenda) too slow(?)
Hello, I have just one headline and do a simple property search (prop1="blah1") for the 'org-agenda', but this takes about 10 seconds! --- FILE: * empty item but with a long logbook :PROPERTIES: :prop1: blah1 :END: :LOGBOOK: CLOCK: [2022-03-12 Sat 05:05]--[2022-03-12 Sat 05:24] => 0:19 CLOCK: [2022-03-11 Fri 20:50]--[2022-03-11 Fri 21:20] => 0:30 CLOCK: [2022-03-11 Fri 17:13]--[2022-03-11 Fri 17:25] => 0:12 CLOCK: [2022-03-11 Fri 06:10]--[2022-03-11 Fri 06:30] => 0:20 CLOCK: [2022-03-10 Thu 23:14]--[2022-03-11 Fri 00:25] => 1:11 CLOCK: [2022-03-10 Thu 16:45]--[2022-03-10 Thu 17:07] => 0:22 CLOCK: [2022-03-10 Thu 05:19]--[2022-03-10 Thu 06:30] => 1:11 CLOCK: [2022-03-09 Wed 22:29]--[2022-03-09 Wed 22:35] => 0:06 CLOCK: [2022-03-09 Wed 16:45]--[2022-03-09 Wed 17:01] => 0:16 CLOCK: [2022-03-12 Sat 05:05]--[2022-03-12 Sat 05:24] => 0:19 CLOCK: [2022-03-11 Fri 20:50]--[2022-03-11 Fri 21:20] => 0:30 CLOCK: [2022-03-11 Fri 17:13]--[2022-03-11 Fri 17:25] => 0:12 CLOCK: [2022-03-11 Fri 06:10]--[2022-03-11 Fri 06:30] => 0:20 CLOCK: [2022-03-10 Thu 23:14]--[2022-03-11 Fri 00:25] => 1:11 CLOCK: [2022-03-10 Thu 16:45]--[2022-03-10 Thu 17:07] => 0:22 CLOCK: [2022-03-10 Thu 05:19]--[2022-03-10 Thu 06:30] => 1:11 CLOCK: [2022-03-09 Wed 22:29]--[2022-03-09 Wed 22:35] => 0:06 CLOCK: [2022-03-09 Wed 16:45]--[2022-03-09 Wed 17:01] => 0:16 CLOCK: [2022-03-09 Wed 05:20]--[2022-03-09 Wed 06:30] => 1:10 CLOCK: [2022-03-08 Tue 22:15]--[2022-03-08 Tue 22:30] => 0:15 CLOCK: [2022-03-08 Tue 16:10]--[2022-03-08 Tue 16:23] => 0:13 CLOCK: [2022-03-12 Sat 05:25]--[2022-03-12 Sat 06:40] => 1:15 CLOCK: [2022-03-12 Sat 05:10]--[2022-03-12 Sat 05:24] => 0:14 CLOCK: [2022-03-11 Fri 20:45]--[2022-03-11 Fri 21:25] => 0:40 CLOCK: [2022-03-11 Fri 16:00]--[2022-03-11 Fri 16:30] => 0:30 CLOCK: [2022-03-11 Fri 06:05]--[2022-03-11 Fri 06:40] => 0:35 CLOCK: [2022-03-12 Sat 06:38]--[2022-03-12 Sat 06:40] => 0:02 CLOCK: [2022-03-12 Sat 05:05]--[2022-03-12 Sat 05:24] => 0:19 CLOCK: [2022-03-11 Fri 20:50]--[2022-03-11 Fri 21:20] => 0:30 CLOCK: [2022-03-11 Fri 17:13]--[2022-03-11 Fri 17:25] => 0:12 CLOCK: [2022-03-11 Fri 06:10]--[2022-03-11 Fri 06:30] => 0:20 CLOCK: [2022-03-10 Thu 23:14]--[2022-03-11 Fri 00:25] => 1:11 CLOCK: [2022-03-10 Thu 16:45]--[2022-03-10 Thu 17:07] => 0:22 CLOCK: [2022-03-10 Thu 05:19]--[2022-03-10 Thu 06:30] => 1:11 CLOCK: [2022-03-09 Wed 22:29]--[2022-03-09 Wed 22:35] => 0:06 CLOCK: [2022-03-09 Wed 16:45]--[2022-03-09 Wed 17:01] => 0:16 CLOCK: [2022-03-09 Wed 05:20]--[2022-03-09 Wed 06:30] => 1:10 CLOCK: [2022-03-08 Tue 22:15]--[2022-03-08 Tue 22:30] => 0:15 CLOCK: [2022-03-08 Tue 16:10]--[2022-03-08 Tue 16:23] => 0:13 CLOCK: [2022-03-12 Sat 05:25]--[2022-03-12 Sat 06:40] => 1:15 CLOCK: [2022-03-12 Sat 05:05]--[2022-03-12 Sat 05:24] => 0:19 CLOCK: [2022-03-11 Fri 20:50]--[2022-03-11 Fri 21:20] => 0:30 CLOCK: [2022-03-11 Fri 17:13]--[2022-03-11 Fri 17:25] => 0:12 CLOCK: [2022-03-11 Fri 06:10]--[2022-03-11 Fri 06:30] => 0:20 CLOCK: [2022-03-10 Thu 23:14]--[2022-03-11 Fri 00:25] => 1:11 CLOCK: [2022-03-10 Thu 16:45]--[2022-03-10 Thu 21:07] => 4:22 CLOCK: [2022-03-10 Thu 05:19]--[2022-03-10 Thu 06:30] => 1:11 CLOCK: [2022-03-09 Wed 22:29]--[2022-03-09 Wed 22:35] => 0:06 CLOCK: [2022-03-09 Wed 16:45]--[2022-03-09 Wed 17:01] => 0:16 CLOCK: [2022-03-09 Wed 05:20]--[2022-03-09 Wed 06:30] => 1:10 CLOCK: [2022-03-08 Tue 22:15]--[2022-03-08 Tue 22:30] => 0:15 CLOCK: [2022-03-08 Tue 16:10]--[2022-03-08 Tue 16:23] => 0:13 CLOCK: [2022-03-12 Sat 05:25]--[2022-03-12 Sat 06:40] => 1:15 CLOCK: [2022-03-12 Sat 05:10]--[2022-03-12 Sat 05:24] => 0:14 CLOCK: [2022-03-11 Fri 20:45]--[2022-03-11 Fri 21:25] => 0:40 CLOCK: [2022-03-11 Fri 16:00]--[2022-03-11 Fri 16:30] => 0:30 CLOCK: [2022-03-11 Fri 06:05]--[2022-03-11 Fri 06:40] => 0:35 CLOCK: [2022-03-12 Sat 06:38]--[2022-03-12 Sat 06:38] => 0:00 CLOCK: [2022-03-12 Sat 05:05]--[2022-03-12 Sat 05:24] => 0:19 CLOCK: [2022-03-11 Fri 20:50]--[2022-03-11 Fri 21:20] => 0:30 CLOCK: [2022-03-11 Fri 17:13]--[2022-03-11 Fri 17:25] => 0:12 CLOCK: [2022-03-11 Fri 06:10]--[2022-03-11 Fri 06:30] => 0:20 CLOCK: [2022-03-10 Thu 23:14]--[2022-03-11 Fri 00:25] => 1:11 CLOCK: [2022-03-10 Thu 16:45]--[2022-03-10 Thu 17:07] => 0:22 CLOCK: [2022-03-10 Thu 05:19]--[2022-03-10 Thu 06:30] => 1:11 CLOCK: [2022-03-09 Wed 22:29]--[2022-03-09 Wed 22:35] => 0:06 CLOCK: [2022-03-09 Wed 16:45]--[2022-03-09 Wed 17:01] => 0:16 CLOCK: [2022-03-09 Wed 05:20]--[2022-03-09 Wed 06:30] => 1:10 CLOCK: [2022-03-08 Tue 22:15]--[2022-03-08 Tue 22:30] => 0:15 CLOCK: [2022-03-08 Tue 16:10]--[2022-03-08 Tue 16:23] => 0:13 CLOCK: [2022-03-12 Sat 05:25]--[2022-03-12 Sat 06:40] => 1:15 CLOCK: [2022-03-12 Sat 05:05]--[2022-03-12 Sat 05:24] => 0:19 CLOCK: [2022-03-11 Fri 20:50]--[2022-03-11 Fri 21:20] => 0:30 CLOCK: [2022-03-11 Fri 17:13]--[2022-03-11 Fri 17:25] => 0:12 CLOCK: [2022-03-11 Fri 06:10]--[2022-03-11 Fri 06:30] => 0:20 CLOCK: [2022-03-10 Thu 23:14]--[2022-03-11 Fri 00:25] => 1:11 CLOCK: [2022-03-10 Thu 16:45]--[2022-03-10 Thu 17:07]
