~dr|z3d
@RN
@T3s|4
@eyedeekay
@orignal
@postman
@zzz
%Liorar
%cumlord
+DirtyHarry
+FreefallHeavens
+Xeha
+ardu
+bak83_
+mareki2p
+onon_
+profetikla
+r00tobo
+uop23ip
AHOH
Arch2
Danny
DeltaOreo
FreeB
Irc2PGuest59581
Irc2PGuest70083
Irc2PGuest70134
Irc2PGuest96449
Irc2PGuest97049
Meow
Onn4l7h
Onn4|7h
acetone_
altonen
boonst
carried6590
duck
evasiveStillness
maylay
not_bob_afk
phobos_
pisslord
poriori_
qend-irc2p
radakayot_
shiver_1
simprelay
solidx66
thetia
u5657
weko_
zer0bitz
dr|z3d
zzz: can confirm the b32/64 search in susidns appears to be working, though it doesn't do a partial match right now, you need to provide the full address, presumably intentionally.
dr|z3d
cumlord: I may have accidentally the snark update. I built from the wrong branch, so there may be some regressions in that standalone build.
cumlord
oh the one you send yesterday?
dr|z3d
yeah, that one. give me a moment or 3, I'll build a new one.
cumlord
nice I’ll give it another go :)
dr|z3d
not sure how much regression you would have seen, I was building 2.5.0-17+, so maybe some. I've redone the changes, and added a 1s delay before attempting to update the UI after a deletion, hopefully that helps, let me know.
dr|z3d
there are also a couple of zzz specials in the latest build.
zzz
thanks for catching up and testing dr|z3d
zzz
re: partial reverse lookups, yes on purpose not supported
zzz
1) I don't see the use case; 2) it's a lot harder both to code and computationally
zzz
as you can see the full reverse lookup was just a few lines of code, very simple
dr|z3d
yeah, good work, zzz, useful feature.
dr|z3d
the download speed indicator for snark on the info page.
zzz
whataboutit?
dr|z3d
I think you might be missing a trick there.. assuming we didn't create the torrent locally.. why not display the avg download speed when the torrent has completed?
zzz
I think that's what it does?
zzz
the time used in the calc is now - added if not complete, or completed - added if complete
dr|z3d
oh, then maybe my manual merge and then branch merge went a bit wrong, let me have another look at my code.
zzz
so it should show for both cases, as long as you didn't create it, or the download was either so fast or so slow that there's no use showing it
zzz
so it does get hidden sometimes
zzz
like if you started it, stopped, and restarted it a year later
dr|z3d
ok, probably an issue with the metadata or absence thereof for my torrents. code looks fine.
zzz
because we don't track total torrent running time
dr|z3d
sure, torrent started, torrent finished. probably no value in logging the total running time.
zzz
I don't remember when we put in the added/completed metadata, but for very old torrents it might not be there
dr|z3d
I think this may be a local issue, every time I reboot, metadata goes *poof"
zzz
I was just after a simple use case, 'yay, that torrent just finished, I wonder what the overall download speed was?'
dr|z3d
yup, good idea, nice datapoint.
zzz
hmm that sounds worth chasing down...
zzz
metadata poof means all torrents get rechecked at startup, right? that will get your users complaining pretty quick
dr|z3d
yeah, it's not an issue with snark, it's an issue with my setup.
dr|z3d
probably something to do with mount permissions.
zzz
ok, local footgun only
dr|z3d
while we're on the subject of snark, the metadata folders.. I know we've been here before.. :)
dr|z3d
I think it might be worth reconsidering how we create the container folder.. you pulled in the same code for creating the RI folders iirc.
dr|z3d
*container folders
zzz
whats yer beef?
dr|z3d
well, it's messy, and it's hard to find the meta data for a given torrent.
zzz
yeah because there's 64 dirs based on the base64 char, like for ri and profiles, but infohashes are in hex
dr|z3d
it would be nicer to have the container folders a-z etc, so if you're looking for the metadata for foo.torrent, you know it's in the f folder.
zzz
with hex, 16 dirs seems too few and 256 seems too much
dr|z3d
and/or maybe we could do something with the naming of the config file as well.
zzz
dont think we want to do it based on torrent name
dr|z3d
no?
zzz
dunno, maybe dups or something. by infohash seems more sensible
zzz
not really meant for ppl to be digging in there, if you really want to find something, just grep */*
dr|z3d
could use hybrid naming to avoid dups, but I hear you.
zzz
guess if I had to do it over I'd do 256 dirs based on 2-char hex, since we do have cleanup of empty dirs (unlike with ris and profiles)
zzz
which would be super-easy to switch to, except now you'd have to write a migration tool that automatically checks for old layout and moves everything
dr|z3d
not convinced we'd need 256 dirs, but ok. the migration tool is probably already mostly written.. flat / directory swapover for RIs.
zzz
well if you want to know how to find what dir a torrent is in, the dir needs to start with either the first infohash char or the first two
zzz
can't do 1 1/2
zzz
and can't do torrent name because not everything starts with a-z, could be chinese, who knows
dr|z3d
yeah, i was thinking a-z, 0-9, and everything else (misc, whatever), but sure, not optimal.
zzz
so I'll agree with you I could have done better but I'm not going to change it
zzz
as an easy workaround you could list the full path to the config file on the torrent details page
dr|z3d
ok, no worries, figured it would be more hassle than its worth.
dr|z3d
hmm, yeah, that's a possible I guess.
zzz
it's more clutter, but seems like your users are mostly power-users, maybe they'd like it
dr|z3d
clutter is just optimizations waiting to happen :)
cumlord
seems like when deleting things the post request keeps getting longer
cumlord
ends up looking like this convos.simp.i2p/file/1/SjU8P80CR4rLARbN
dr|z3d
thanks, cumlord, that's handy. looks like it's not resetting the query parameters.
dr|z3d
unless you're attempting to delete a folder with a chunk of files in it? not entirely sure how that works.
zzz
looks like I need <style blocking="render" for my @import? developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/style
zzz
hmm still getting FOUCed
zzz
any ideas?
zzz
oh, chart at bottom, not supported by firefox
dr|z3d
not working? you're doing a straight css import in a <style> tag?
dr|z3d
I thought @import was always blocking, which is why various sites recommend you don't use it.
zzz
it works in the css file, as far as css loading, but not from <link or <style
zzz
chart at bottom. everybody supports it except firefox
dr|z3d
<style type="text/css">.header { background: url('/headers/vf425-USS-Callister.webp'); }</style>
dr|z3d
<style type="text/css">@import url('/themes/red2.css');</style>
zzz
it works in that it loads, but it doesn't respect blocking="render"
dr|z3d
that's strange, shouldn't need blocking=render, but maybe something changed in the spec.
zzz
-<link href="http://proxy.i2p/themes/console/default/proxy.css" rel="stylesheet" type="text/css">
zzz
+<link blocking="render" href="http://proxy.i2p/themes/console/default/proxy.css" rel="stylesheet" type="text/css">^M
zzz
** what I checked in
zzz
well, it was still broken, so I tried blocking=render, still didnt
zzz
didn't test if it had any effect on chrome, but figured can't hurt
zzz
the FOUC is really heinous on dark theme, I see why you go to some trouble to get the background right
dr|z3d
yeah, if you style the html tag, at least that's instant.
dr|z3d
hang on, blocking render is for link, not style.
dr|z3d
you don't need a link in there at all, just <style>@import url(foo.css);</style>
dr|z3d
*** nudges zzz ***
zzz
<link is one way to do it, verified on mozilla site, link above
dr|z3d
you remember earlier in the conversation where I mentioned zzz.i2p ?
zzz
yes, I did it that way first
zzz
then switched to <link
dr|z3d
and it didn't work as expected?
zzz
nope, but maybe in desperation I'll retry it
dr|z3d
ok
dr|z3d
all else fails, you've got a workable solution in + :)
zzz
yup
dr|z3d
I still find it odd that it works fine on zzz.i2p, but you can't make it work on the proxy errors. maybe it's a timing issue, dunno.
zzz
clearly it's the different origin for the css
zzz
still FOUC with your fix. But maybe its just FOUblankscreen, it goes so fast, cant tell
zzz
do I have to set the background early based on theme?
dr|z3d
I'm not doing that here, but I'm not seeing a fouc on the dark theme errors.
zzz
gonna have to retest everything on light theme
dr|z3d
no need for the light theme, since the background transition from white to whatever it is in the css is minimal. but you could set the background color on the html tag for dark.
zzz
note that you have to be on a new tab or shift-reload to get the FOUC, at least some times
dr|z3d
yeah, I've been aggressively shift+ctrl+r'ing to attempt to see your issue. can't make it happen here.
zzz
switched to light, easier to see, definitely getting content flash, not just background flash
zzz
I don't need this do I? <style>body::before{animation:linear loader 15s forwards}</style>
dr|z3d
no
dr|z3d
that's there in + to provide a timer bar for the meta refresh.