Current Server Time: 22:04 (Central Europe)

#apertus IRC Channel Logs

2020/12/14

Timezone: UTC


00:55
illwieckz
left the channel
00:56
illwieckz
joined the channel
00:57
comradekingu
left the channel
01:11
BAndiT1983
changed nick to: BAndiT1983|away
06:16
Bertl_oO
off to bed now ... have a good one everyone!
06:16
Bertl_oO
changed nick to: Bertl_zZ
06:53
BAndiT1983|away
changed nick to: BAndiT1983
08:15
miek
left the channel
08:16
metal_dent[m]
left the channel
08:16
metal_dent[m]
joined the channel
08:19
miek
joined the channel
09:34
comradekingu
joined the channel
09:56
miek
left the channel
10:11
miek
joined the channel
10:31
miek
left the channel
10:42
aombk
left the channel
10:43
aombk
joined the channel
11:39
aombk
left the channel
11:40
aombk
joined the channel
11:59
aombk
left the channel
11:59
aombk
joined the channel
12:03
se6ast1an
all google services seem to be down, can anyone confirm?
12:06
BAndiT1983
yes
12:07
BAndiT1983
someone probably misconfigured the load balancer
12:07
se6ast1an
or pulled out the single ethernet cable that had the "do not unplug" sticky note on it...
12:07
BAndiT1983
just google search works, but mail and youtube are down for a couple of minutes
12:08
BAndiT1983
this is a very bad label, as people won't react properly, it must say: "this is the internet, do not unplug!"
12:09
BAndiT1983
https://stadt-bremerhaven.de/google-mit-stoerung-gmail-youtube-und-weitere/
12:12
comradekingu
left the channel
12:13
se6ast1an
"worldwide", impressive :)
12:14
comradekingu
joined the channel
12:16
futarisIRCcloud
joined the channel
12:35
BAndiT1983
looks like YT is back online
12:36
se6ast1an
true, drive as well
12:36
se6ast1an
and gmail
12:52
EmilJ
hi there
12:52
EmilJ
anuejn, were you talking about digesting stills?
12:52
EmilJ
or captured video?
12:56
aombk
left the channel
12:56
aombk
joined the channel
13:02
miek
joined the channel
13:05
aombk
left the channel
13:06
aombk
joined the channel
13:14
anuejn
EmilJ: when?
13:14
anuejn
hi btw
13:14
anuejn
most of the time I talk about video :)
13:14
EmilJ
> seems like it is somewhat faster (~60fps with the beta 4k images on my laptop)
13:15
anuejn
ah
13:15
EmilJ
I guess it wouldn't make sense to h264 stills
13:15
anuejn
yup that is for video
13:15
EmilJ
is the main video readout method still HDMI capture as the wiki says?
13:15
anuejn
but other than the h264 in the end (which is not done by me) there isnt really any inter frame processing going on
13:16
anuejn
so it could as well be stills
13:16
anuejn
Currently yes but I am working on making the usb3 plugin work
13:16
anuejn
so that is the way I am experimenting with
13:18
EmilJ
With the camera as device or host?
13:19
anuejn
the camera as device
13:19
anuejn
streaming live video to a connected notebook
13:19
anuejn
which then runs said software
13:21
EmilJ
Would be nice if we could replace the notebook with a board with a bit spicier processor than the two cores on the zynq, recording to M.2 or something
13:22
EmilJ
after real-time h265 encoding, I mean
13:22
anuejn
that is more or less the plan
13:23
anuejn
Bertl_zZ: is working on a solution with an ultrascale zynq
13:23
EmilJ
oh awesome
13:23
anuejn
but we also considered multiple other platforms
13:23
EmilJ
I'd love to read through the notes or chat logs for that
13:23
anuejn
the stuff I am working on is currently more leaning towards using an intel based board
13:24
anuejn
(because that closely matches my notebooks hardware)
13:24
anuejn
hm... let me dig that out
13:24
vup
(or amd apu based boards should work aswell)
13:25
aombk
left the channel
13:25
EmilJ
it seems like new bunch-of-ARM-cores SoCs could be a neat, power and price-efficient solution
13:25
EmilJ
NXP has some wild SoCs and I think they're expensive (20USD per part) but I mean, we're comparing stuff to Ultrascale here
13:25
aombk
joined the channel
13:28
anuejn
hm... sadly I cant find the relevant meetings
13:28
anuejn
maybe Bertl_zZ knows
13:28
vup
well we currently use the hardware accelerated h264 encoding, I think any solution not having that won't be competitive, atleast power wise
13:28
anuejn
Yup other arm socs might be an option too
13:29
anuejn
yup
13:29
anuejn
I cant even closely encode h264 in software on my notebook
13:29
vup
well maybe I am about to change that :P
13:29
anuejn
but I guess se6ast1an is not into h264 at all
13:29
anuejn
vup: :)
13:30
EmilJ
do you have a power consumption estimate of accelerated X unaccelerated encode?
13:31
anuejn
EmilJ: I do not own a computer fast enough to do unaccelerated encoding in realtime
13:31
anuejn
so I would say above 15W (which is the power budget of my cpu) for unaccelerated encode
13:32
vup
just as a point of reference: encoding 1080p30 video takes about < 0.8W on my laptop
13:32
anuejn
(accellerated?!)
13:33
EmilJ
Hmm, yeah... I undershot
13:33
vup
yes hardware encoding
13:34
anuejn
but probably h264 is not the compression we end up using for most applications
13:34
anuejn
I have the impression that most people want a format that is more raw
13:34
vup
yeah
13:35
anuejn
but I think we will find something there
13:36
anuejn
(if you are interested, I found https://gopro.github.io/cineform-sdk/ to be a good introductory read on wavelet image compression)
13:37
anuejn
something like that seems like a good fit to implement in an fpga (if memory bandwidth permits) which might be a bit tough
13:40
EmilJ
oh yeah, benched my ryzen 3600, was able to do 40FPS transcoding h264 to h265 (source and destination both 1080p30)
13:40
EmilJ
Handbrake, nvenc off
13:41
anuejn
Yeah I guess h265 is a bit more demanding hardware wise
13:41
aombk
left the channel
13:42
aombk
joined the channel
13:46
EmilJ
so, the current plan is embedded AMD64 from Intel?
13:46
EmilJ
the NXP SoCs are too sucky to encode 4k
13:48
anuejn
the current plan is not really finalized ;)
13:49
anuejn
we might go with an fpga
13:49
anuejn
but the short term solution is probably bring your own notebook :)
13:49
EmilJ
With a hard encoder core?
13:51
EmilJ
By the way, teradek bolt is an impressive product series. "Zero latency" video transmission at 5GHz. They're using proprietary encoding
13:53
EmilJ
https://irc.tywoniak.eu/file/1/26zZSKkRBZuavwNx
14:06
anuejn
yup
14:06
anuejn
gererally i find wireless video very fascinating
14:40
aombk
left the channel
14:41
aombk
joined the channel
14:46
futarisIRCcloud
left the channel
15:03
aombk
left the channel
15:04
aombk
joined the channel
15:39
aombk
left the channel
15:39
aombk
joined the channel
16:06
aombk
left the channel
16:07
aombk
joined the channel
16:14
Bertl_zZ
changed nick to: Bertl
16:14
Bertl
morning folks!
16:17
se6ast1an
good day
16:20
aombk
left the channel
16:21
aombk
joined the channel
16:56
se6ast1an
meeting in 5 minutes!
17:00
se6ast1an
MEETING TIME!
17:00
se6ast1an
who is here?
17:00
Bertl
is here ...
17:00
vup
is here
17:01
se6ast1an
BAndiT1983: messaged me he will be occupied now unfortunately but has nothing new worth reporting
17:02
se6ast1an
vup: do you have news for us?
17:02
vup
a bit and I will also share some news from anuejn
17:02
vup
shall I start?
17:03
se6ast1an
please!
17:04
vup
ok, so first some news from anuejn, he continued working on getting a usb3 stream from the micro to the recorder working
17:05
vup
the recorder can now successfully receive data sent from the zynq to the usb3 plugin module, however there are still some problems
17:05
vup
first the frame alignment is not implemented yet
17:06
vup
and furthermore sometimes it seems like data gets lost
17:06
se6ast1an
frame alignment means to know when data from one image stops and the next starts?
17:06
vup
yes
17:06
se6ast1an
understood
17:06
vup
to do that efficient is a bit tricky, because we want to avoid copying the data around
17:07
vup
so we essentially want to figure out where the frame starts
17:07
Bertl
didn't we agree to reserve some codes for this purpose?
17:07
vup
yes
17:07
vup
that part is not hard
17:07
vup
the not copying part is a bit tricky (but also not too bad)
17:08
vup
The idea is, after figuring out where the frame starts, to read a smaller (than one frame) buffer from the usb3, such that when reading the next frame the buffer is aligned to the start of the frame
17:09
Bertl
hmm, okay, so 'who/what' would be copying?
17:09
vup
this is complicated by the fact, that one cannot read buffers smaller than 2048 * 4 bytes from the ft601, so some final adjustment has to be done after that. (Also frames + padding always have to be a multiple of 2048 * 4 bytes)
17:10
vup
Bertl: well you could just read a framesized buffer, figure out the start and then copy the starting part of the frame into a new buffer. On the next transfer you then get the rest of that frame and also a start of the new frame
17:11
vup
well anyways, its not really hard, but anuejn did not get to implementing the alignmenTyet
17:11
vup
we also found a problem where sometimes some data gets lost (probably by one of the fifos either on the zynq or the machxo2 overflowing)
17:12
vup
so we need to figure out how to handle that best
17:12
Bertl
okay, probably first step to figure out what's overflowing and why
17:12
vup
either by reading more quickly on the computer side, or maybe adding backpressure from the machxo2 to the zynq
17:12
vup
Bertl: well it is most certainly the fifo on the machxo2
17:13
vup
moving some work (mostly allocating new buffers) done on the computer from the thread that does the receiving to another thread eliminated most of the lost data
17:13
vup
*eliminated most of the loosing of data
17:14
Bertl
do we have resources for a second fifo or can we make the fifo larger?
17:14
vup
The fifo on the machxo2 is essentially at the maximum size
17:14
vup
maybe a few more words can be squeezed in by using a dram fifo
17:14
vup
but we already use most of the lut's on the machxo2 (and of course the bram for the fifo)
17:16
vup
Ok, so I also played around a bit with the recorder this week and I started to implement a way to do zerocopy video encoding
17:16
vup
(and zerocopy sharing of the data with other gpu based frameworks like CUDA should be possible aswell)
17:18
vup
We currently do the debayering in the recorder with vulkan, and using a extension we can export a vulkan buffer as something called dma-buf. This is a linux framework to share GPU memory between processes and even access GPU memory from the CPU (CPU access will most certainly be very slow when using a dGPU, but using a iGPU its very fast)
17:18
vup
By passing the debayered data as a dma-buf from vulkan to vaapi (which can export dma-bufs) it should be possible to use the hardware encoding without needing to copy the data once
17:19
vup
In our previous tests, copying the data took more than 70% of the time needed in the encoding process, so that should help quite a lot with the speed there
17:19
se6ast1an
very cool!
17:21
vup
so yeah, now I am working on getting the encoding part working and landing the mesa patch necessary to get writable access to the dma-buf from the CPU
17:21
vup
thats it from we for this week I think
17:21
se6ast1an
great progress
17:21
se6ast1an
do you want to talk about the Micro R3 / R2.1 as well or should I cover that?
17:21
Bertl
vup: sounds nice!
17:21
vup
you can cover that :)
17:22
se6ast1an
right :)
17:22
se6ast1an
many thanks for the report, very exciting!
17:23
se6ast1an
ok brief updates from me then:
17:23
se6ast1an
Max finished editing of Team Talk 15.5 and I am currently writing an article draft around it
17:23
se6ast1an
for review and release in a few days I would assume
17:25
se6ast1an
Will work on reviving the automated pick and place machine at the factoryhub together with daniel tomorrow
17:25
se6ast1an
and on thursday we will visit another electronics manufacturing facility with very low cost machines
17:25
se6ast1an
appointment was actually planned for today but got delayed
17:26
se6ast1an
we still plan to have Tele produce the AXIOM Beta hardware though
17:26
se6ast1an
just more options = good :)
17:27
se6ast1an
There were several meeting over the course of the last week regarding the AXIOM Micro
17:27
se6ast1an
vup and anuejn are working on the Release 3 currently
17:27
Bertl
yay!
17:27
se6ast1an
but this is still a bigger project with several ground decisions to be made
17:28
se6ast1an
like full featured vs low complexity
17:28
se6ast1an
anuejn and vup estimated it will likely take them another year to complete
17:28
se6ast1an
at least
17:29
se6ast1an
but a more immediate result could be fixing the discovered issues and problems with the R2
17:29
se6ast1an
to arrive at something called R2.1 currently
17:29
se6ast1an
including bug fixes, but also cleaning up and removing stuff that turned out to be less useful
17:30
se6ast1an
but not adding anything new (maybe only minor additions, nothing major)
17:30
se6ast1an
so a lot of considerations and discussions have started about what an AXIOM Micro R2.1 could be exactly
17:31
se6ast1an
the goal is to make it very affordable so reaching a certain production volume is vital
17:32
se6ast1an
but who could be interested in it
17:32
Bertl
how about a crowdfunding campaign with a given target volume?
17:32
se6ast1an
yes that would indeed be one approach
17:33
Bertl
(once the price estimate and design has been fixed)
17:33
aombk2
joined the channel
17:33
se6ast1an
anuejn / vup also said they do not want to fund development
17:33
aombk
left the channel
17:33
se6ast1an
rather develop until its ready for production and then funding the production and fulfil right away
17:33
Bertl
yes, that's what I meant
17:34
se6ast1an
yes, so currently a lot of discussion is ongoing what a Micro R2.1 could cater to users
17:34
se6ast1an
a better webcam
17:35
se6ast1an
for recording lectures or streaming conferences
17:35
se6ast1an
FOSDEM was very interested in this
17:35
se6ast1an
of course it should also be a development platform (Zynq + Image acquisition)
17:35
se6ast1an
but maybe it can be more than that already
17:36
se6ast1an
that a raspberry pi camera cannot do ( which we will never be able to compete with from the price anyway)
17:36
xthenode
joined the channel
17:37
se6ast1an
thats it from my side
17:37
se6ast1an
Bertl: the finishing moves?
17:37
Bertl
sure, thanks!
17:38
Bertl
I spent most of the time looking at the schematics and board designs for the panel this week
17:38
xthenode
hello from xthenode aka medusade...
17:38
Bertl
over and over again, to make sure that we do not have overlooked any other issues there
17:39
Bertl
in this process, I did a board rendering (2.1D), which required to update our scripts to imagemagick v7
17:40
Bertl
which took surprisingly long because of a subtle imagemagick bug which looked like some interfaces had changed but instead they were just buggy
17:41
Bertl
the board renderings can be seen here (not the latest though): http://vserver.13thfloor.at/Stuff/AXIOM/BETA/PANEL/axiom_beta_mixed_panel.top.png http://vserver.13thfloor.at/Stuff/AXIOM/BETA/PANEL/axiom_beta_mixed_panel.bottom.png
17:42
se6ast1an
tripple checking is surely tedious work, but its much appreciated and I hope we can place a new order very soon
17:42
Bertl
I also finished the TE0714 carrier board which we plan to use for testing our impedance/loss test strips on the edge of the panel
17:42
Bertl
so we should be able to order that together with the panels
17:43
se6ast1an
most excellent!
17:43
Bertl
I further did some more testing with the 'new' power board and found a tricky issue with the CSO power supply there
17:44
Bertl
which basically has been haunting us since the early power board designs and can, under certain circumstances, lead to 5V on the 3.3V power rails for the CSO modules
17:45
Bertl
so we got that fixed as well now and so far it looks really good (fingers crossed)
17:45
Bertl
I think, if nothing unexpected pops up, we should be ready in the second half of this week
17:46
se6ast1an
perfect
17:46
Bertl
as usual, any additional reviews are more than welcome!
17:46
se6ast1an
did you also look at the impedance isolated gerber layers to highlight the LVDS layers?
17:47
Bertl
i.e. do not hesitate to look through the files and report any findings and/or ask if there are any potential issues
17:48
Bertl
I had a quick look and we adjusted all the net classes to match the LVDS traces, so as discussed with BAndiT1983, it should be fairly straigt forward to pick those by class directly from the board files
17:49
Bertl
my suggestion would be to create a 'new' board file which only contains traces ('wires') from the LVDS class and simply generate gerbers for that as well
17:49
Bertl
those can then be used/combined with the 'normal' board gerbers to locate/highlight the relevant traces
17:49
se6ast1an
we already have everything ready
17:49
se6ast1an
https://github.com/apertus-open-source-cinema/pcb-paneliser/tree/master/output_impedance_filtered/output_stage1
17:49
Bertl
perfect then
17:50
Bertl
finally I also found some time to update kicad to the latest development release
17:50
se6ast1an
I was more intereted if we need to update the results, but I assume the LVDS traces didnt change anywhere
17:50
Bertl
we should not assume anything and always do a full build
17:50
se6ast1an
and if you had look at the results and if they match your expectations
17:50
Bertl
not yet
17:50
se6ast1an
ok
17:51
Bertl
kicad now can do round trace segments (they are called fillet tracks)
17:51
Bertl
also the UI is much more flexible and can be configured to work with easily
17:52
Bertl
there are still some minor issues, especially with the trace rounding but I'm optimistic that this will be resolved in the near future
17:52
Bertl
let's hope that it will be useable in the upcoming 6.x release
17:53
Bertl
that's it from my side for today.
17:53
se6ast1an
great, many thanks, anyone else with topics/questions?
17:53
se6ast1an
xthenode: you just wrote us an email, would you like to discuss it here?
17:54
se6ast1an
you wrote "I'm interested in working with the camera sensor using the now totally cool raspberry pi for the purpose of ultra large image capture of fine art."
17:54
xthenode
sure
17:54
se6ast1an
I am not sure we can assist much on the raspberry pi front though
17:54
se6ast1an
you also wrote "I'm also interested in wide spectrum image capture for color analysis of images sensed by the camera."
17:54
se6ast1an
please elaborate
17:55
xthenode
I'v got a whole build env on the pi 4..
17:55
xthenode
work with the raw image data...
17:57
xthenode
ive done work with your raw samples and dng files
17:58
xthenode
the idea would be to hook into the sensor controller to get the raw data...
17:59
metaldent
joined the channel
18:00
xthenode
the pi would be used for the portable version, but the development would be one on a pc
18:00
xthenode
done
18:00
xthenode
done on pc
18:05
xthenode
left the channel
18:07
se6ast1an
right, meeting concluded
18:07
se6ast1an
we can continue with xthenode if he returns...
18:08
metaldent
hi, actually me and bluez also wanted to share some updates ':D
18:12
se6ast1an
ah great, please do
18:12
se6ast1an
has there been a daylight change btw?
18:13
metaldent
we had texted in the channel before but i think matrix is having some issues
18:13
se6ast1an
ah right
18:14
metaldent
small updates from me: i read up about some security methods to ensure proper authentication for the webUI and also discussed with BAndiT
18:14
Bertl
yeah, at the moment it's probably a good idea to stick to IRC
18:15
metaldent
i also tried to build the webUI but am having some trouble there as some dependencies are outdated and were showing errors while compiling
18:16
metaldent
that's it from me!
18:17
vup
metaldent: which webui are you talking about?
18:17
metaldent
bluez is having trouble with his computer so shall i share on his behalf?
18:17
BAndiT1983
changed nick to: BAndiT1983|away
18:17
metaldent
vup: the one you and anuejn had built
18:17
vup
I see
18:18
se6ast1an
sure, please share bluez report
18:18
metaldent
from bluez:
18:18
metaldent
"Spent some time with the ip integrator and also vivado in general. Its all quite new to me. But i couldn't give much time because of some delayed exams that were held last week... But i will be able to give full time from this week!"
18:18
vup
maybe we can talk about the compilation problems later, as we can build it in the CI
18:19
metaldent
vup: yes please! i had a doubt in the build instruction too
18:21
metaldent
that's it from both of us! thank you!
18:21
se6ast1an
many thanks for the updates!
18:21
se6ast1an
did everything with the university letters work out?
18:22
metaldent
yes yes, we have submitted them
18:23
se6ast1an
great
18:26
vup
ok if the meeting is concluded, metaldent what problems do you have with the webui?
18:28
se6ast1an
Meeting concluded!
18:30
metaldent
vup: the doubt i have is after doing `yarn watch` what's the meaning of the step "Then open a browser and see the webui :). " ?
18:30
vup
it opens a http server on port 3000 as mentioned in the paragraph before that
18:31
vup
so navigate to localhost:3000 in your browser and the webui should be visible
18:32
metaldent
ah okay, this was it then! there was one more web file generated and i inspected that but it was blank so i thought i'm doing something wrong ':D
18:33
vup
:)
18:33
vup
did you get nctrl running yet?
18:34
metaldent
wouldn't it require the IP (or some other info) of the camera?
18:35
vup
nctrl?
18:35
vup
or the webui?
18:35
vup
(the answer is no to both)
18:35
xthenode
joined the channel
18:36
metaldent
okay, i was under the impression that to control one's camera you need to have the IP of it
18:36
vup
no, the webui and nctrl will be running on the camera
18:37
vup
and just uses a nodejs backend to run stuff on the camera
18:38
Bertl
well, you kind of need to have the IP for that though :)
18:38
xthenode
so rest.json api...
18:38
metaldent
wait, the webui will be running "on" the camera?
18:38
vup
yes
18:39
xthenode
ssh daemon?
18:40
vup
well there is a ssh daemon running on the camera aswell
18:40
vup
but that doesn't have anything to do with the webui
18:40
vup
Bertl: well it implicitly knows the IP, as its the IP you are accessing the website under
18:40
xthenode
then to get the ip "ifconfig"...
18:41
vup
or mDNS / DNS
18:41
xthenode
usb 2 serial terminal?
18:41
vup
the camera also has a serial terminal yes
18:41
xthenode
then easy as pi...
18:41
vup
but usually you will plug in a wifi stick and just connect to the wifi the camera creates
18:42
vup
That one even automatically redirects you to the webui as it pretends to be a captive portal
18:42
xthenode
cool
18:42
metaldent
is the "Connect via SSH" feature mentioned in the Home working?
18:43
xthenode
so the camera is a hot-spot?
18:44
xthenode
is nfs supported?
18:44
vup
metaldent: what feature? its just information on how to connect
18:44
vup
xthenode: yes if you plug in a wifi stick it acts as a hot-spot by default
18:44
xthenode
nice...
18:45
xthenode
NFS is for nfsmount
18:45
vup
xthenode: NFS is enabled, but I don't think we have tested it
18:45
vup
but I don't see why it shouldn't work
18:45
xthenode
we were using that on set top boxes...
18:46
xthenode
it allows building code directly to the target device...
18:46
vup
sure
18:46
xthenode
and gdb remote debugging...
18:47
vup
it might not be as performant but sshfs would a a easy alternative that definitely works
18:47
metaldent
nctrl is running i think..
18:47
Bertl
off for now ... bbl
18:47
Bertl
changed nick to: Bertl_oO
18:47
vup
metaldent: if you set it up correctly you should be able to see stuff under register explorer then
18:47
xthenode
left the channel
18:48
xthenode
joined the channel
18:55
metaldent
okay, trying...
18:57
xthenode
gotta run so I'll respond about what I want do with email, and it can be cpoied here for others to see...
18:58
se6ast1an
sure
18:58
xthenode
left the channel
19:15
metaldent
left the channel
19:53
BAndiT1983|away
changed nick to: BAndiT1983
21:12
aombk2
left the channel
21:14
aombk2
joined the channel
21:16
EmilJ
I wonder if a FOSS webcam would appeal to the same type of people who buy Talos POWER9 workstations
21:16
EmilJ
those have open source firmware
21:21
vup
maybe, there is still the closed source bootrom of the zynq...
21:22
anuejn
and the closed hardware zynq dev board ;)
21:24
vup
yeah
21:25
vup
maybe we will change that at some point in the future
21:32
EmilJ
oh right, ew
21:33
EmilJ
what would we need to make that real? A Lattice part with DDR and HDMI-capable serdes right?
21:34
EmilJ
To what degree are the ARM cores crucial for what the Micro is?
21:35
vup
well depends, a lattice part + DDR would probably be a downgrade compared to what one can do now with the micro
21:35
vup
so maybe just a custom zynq board
21:36
vup
the ARM cores give a lot more performance than any softcore will give
21:36
vup
so you can do a lot more there (like comfortably boot linux and run a bunch of software there)
21:37
EmilJ
I'd also like to point out that the 2.2um pixels sound pretty nice - the RPi HQ camera has half the per-pixel surface area
21:37
EmilJ
hmmm, now I'm curious how usable would be Zephyr on a soft-core
21:41
aombk2
left the channel
21:42
aombk2
joined the channel
21:57
aombk2
left the channel
21:58
aombk2
joined the channel
22:41
lexano
left the channel
22:43
lexano
joined the channel
23:19
aombk2
left the channel
23:20
aombk2
joined the channel
23:27
aombk2
left the channel
23:29
aombk2
joined the channel
23:54
aombk2
left the channel
23:57
Spirit532
left the channel
23:57
Spirit532
joined the channel
23:58
aombk
joined the channel