shermp / Kobo-UNCaGED

UNCaGED, for Kobo devices
GNU Affero General Public License v3.0
95 stars 7 forks source link

WebUI, NickelMenu & NickelDBus #32

Closed shermp closed 3 years ago

shermp commented 4 years ago

As discussed in #30, this is a major overhaul of KU. Major changes are:

This hopefully solves #29 as well, as it lets Nickel handle the Wifi.

I think I'm ready for others to have a more in-depth look at the code now. I've marked the PR as a draft for now, in case there's any minute changes to make.

@NiLuJe @pgaskin would you be willing to have a look at this please? Note that I'm more interested in bugs and functionality issues, rather than appearance. I'm aware that the Web UI styling could still use some work, but that can wait for subsequent PR's.

PS: Apologies for no automated builds (yet), I really need to bring up some sort of KoboTC docker image, then extend that with Go.

NiLuJe commented 4 years ago

So far, so good ;).

Teeny tiny checkmarks in the settings, though:

ku_checkmark

NiLuJe commented 4 years ago

Ah. It's failing to discover my Calibre instance.

Sep 14 13:09:49 KoboUNCaGED[3535]: 2020/09/14 13:09:49 Getting Device Info
Sep 14 13:09:49 KoboUNCaGED[3535]: 2020/09/14 13:09:49 Reading Metadata
Sep 14 13:09:49 KoboUNCaGED[3535]: 2020/09/14 13:09:49 Reading metadata.calibre
Sep 14 13:09:50 KoboUNCaGED[3535]: 2020/09/14 13:09:50 Gathering metadata
Sep 14 13:09:55 KoboUNCaGED[3535]: 2020/09/14 13:09:55 Reading password cache
Sep 14 13:09:55 KoboUNCaGED[3535]: 2020/09/14 13:09:55 Preparing Kobo UNCaGED!
Sep 14 13:10:01 KoboUNCaGED[3535]: 2020/09/14 13:10:01 New: Could not find calibre instance: calibre server not found
Sep 14 13:10:01 KoboUNCaGED[3535]: 2020/09/14 13:10:01 New: Could not find calibre instance: calibre server not found
Sep 14 13:10:01 nickel: (   170.311 @ 0x15489f0 / packetdump.warning) "http://127.0.0.1:8181/messages" => "Connection closed" 
Sep 14 13:10:01 UNCaGED: Disabled loopback interface
Sep 14 13:10:01 UNCaGED: Kobo UNCaGED exiting
NiLuJe commented 4 years ago

Random comment: I vaguely feel like I've mentioned something about the duplicate timestamps in the syslog messages a while ago ^^.

NiLuJe commented 4 years ago

Ah, wait, I'm still an idiot. Content server != Wireless device service.

NiLuJe commented 4 years ago

Yep, works much better when I do have it enabled ;p.

So, nothing blew up on my end :).

No encoding issues w/ Latin 1 codepoints, the metadata made it, the thumbnails made it, etc.

It's alive! :tada: :)

shermp commented 4 years ago

Checkboxes are a known issue. I spent some time fighting them this afternoon, to not much success. I'm gonna have to beg some help from actual web developers...

In short, the default checkboxes are awful. My font base resizing trick probably isn't helping.

shermp commented 4 years ago

Just a quick update. I decided I wanted to try adding 'subtitle' support, so I'm slowly working on adding custom column handling to UNCaGED to facilitate this. The idea is that the user could select a column (default or custom) to use as the subtitle source.

Custom columns are not fun to work with...

pgaskin commented 4 years ago

For the checkboxes, it's an issue on Kobo's side. You'll just have to make custom checkboxes from scratch if you want to fix it. I'd suggest using a button element with custom styling and some js, as it'll behave more similarly to an actual checkbox than a link.

shermp commented 4 years ago

Checkboxes are a known issue. I spent some time fighting them this afternoon, to not much success. I'm gonna have to beg some help from actual web developers...

In short, the default checkboxes are awful. My font base resizing trick probably isn't helping.

For the checkboxes, it's an issue on Kobo's side. You'll just have to make custom checkboxes from scratch if you want to fix it. I'd suggest using a button element with custom styling and some js, as it'll behave more similarly to an actual checkbox than a link.

Did some more experimentation, and have come up with some CSS that seems to work fairly well. Maybe not the absolute perfect checkboxes, but MUCH better than before, and required no HTML or JS changes.

input[type=checkbox] {
    -webkit-appearance: none;
    appearance: none;
    border: 0.1em solid #000000;
    position: relative;
    width: 1em;
    height: 1em;
}
input[type="checkbox"]:checked:after {
    content: "\2713";
    font-size: 0.9em;
    color: #000000;
    position: absolute;
    left: 50%;
    top: 50%;
    -webkit-transform: translate(-50%,-50%) scaleX(1.3);
    transform: translate(-50%,-50%) scaleX(1.3);
}
shermp commented 4 years ago

Alright, preliminary subtitle support is in.

The config screen now allows entering in the lookup/search name of the column you wish to display as a subtitle. As well as any custom column (with a # prefix), I'm currently supporting the following standard fields:

For number columns (int, float), the custom 'display' formatting that you can set in Calibre is supported. The same goes for datetime columns. Rating columns show as stars.

I've done a small amount of testing myself, I've not been a user of this functionality in the past. @NiLuJe if you get a moment, could you give it a go please?

Note, the value to string logic is in the upstream UNCaGED project.

NiLuJe commented 4 years ago

I've never played with this either, FWIW, so what did you have in mind, in particular?

(I mean, I'm not even sure where the subtitle field actually ends up in Nickel? Is that the same place as the series name?)

shermp commented 4 years ago

(I mean, I'm not even sure where the subtitle field actually ends up in Nickel? is that the same place as the series name?)

I didn't know either. Turns out it appears between the title and series fields.

NiLuJe commented 4 years ago

Gave it a quick try, nothing blew up ;).

(And that was on Calibre 5, so, that's a check on not having extra Python 3 weirdness to deal with, either ;)).

shermp commented 4 years ago

Gave it a quick try, nothing blew up ;).

(And that was on Calibre 5, so, that's a check on not having extra Python 3 weirdness to deal with, either ;)).

Thanks. I'm still on Calibre 4. I'll probably upgrade in a few weeks when all the plugins I use are updated. I tend to wait a couple of weeks for a point release or two after a major upgrade anyway, because there is always issues that crop up in the first couple of releases.

shermp commented 4 years ago

Ok, CSV columns aren't working for some reason. Gonna have to try and figure that one out.

EDIT: figured it out. Note to self: you can't type assert an interface{} directly to a []string. The correct assertion is, of course, []interface{}

shermp commented 4 years ago

Added some actual basic tests upstream and caught a few bugs, so hopefully I'm good to go for an initial implementation of custom columns/subtitles.

Still not 100% sold on the current UI for it though. I've got a potential idea or two to investigate...

shermp commented 4 years ago

Alright, KU now gets a list of available columns to use for the 'Subtitle' field, and allows the user to select a column at the connected screen.

This means the user no longer has to type in the field they wish to use, making it much easier to select, and switch between different columns. As a bonus, the subtitle setting is now saved per calibre library.

I think this will be the last feature to go in.

shermp commented 4 years ago

Figured out one use for the subtitle field: showing page count generated by the 'count pages' plugin :)

shermp commented 4 years ago

Used this updated version on my Forma yesterday. With the larger number of books since I last used KU on it, I'm a little concerned about performance, especially when sending the booklist to Calibre. Will need to do some investigations to see if I can speed it up.

(I actually had to increase the TCP timeout as a temporary measure, because it was... timing out. Which is a little strange, as every TCP read and write in UNCaGED resets the deadline)

pgaskin commented 4 years ago

TCP timeout

Where did you set this? The one in the client transport is a connection timeout (there's also a first-packet timeout), not the TCP one.

timing out

What do dmesg and the packet loss counters in sysfs look like?

shermp commented 4 years ago

TCP timeout

Where did you set this? The one in the client transport is a connection timeout (there's also a first-packet timeout), not the TCP one.

Yeah, that's probably the one I mean. I need to do some actual investigation on what's happening, where. Will load my test device up with more books and see what I can discover.

The slow IO speed on my Forma doesn't help :{ (seriously, everyone says the eMMC on the Forma/Libra is better than the uSD cards on the older devices, but I've observed the opposite. It takes way longer for Calibre to transfer books on both my Forma and my mum's Libra compared to my older devices)

NiLuJe commented 4 years ago

@shermp: Yeah, we've discussed that before, it's weird.

Mine has much faster writes, and insignificantly slower reads than the H2O, and that makes it (the Forma) feel much snappier in general.

shermp commented 4 years ago

@shermp: Yeah, we've discussed that before, it's weird.

Mine has much faster writes, and insignificantly slower reads than the H2O, and that makes it feel much snappier in general.

Yeah, my Forma is an otherwise snappy performer. Content import is definitely faster than my Glo, despite the slower seeming IO. (I assume the faster CPU helps here)

shermp commented 4 years ago

Ok, pretty sure I know what's going on with the timeouts. Good news, not a Kobo UNCaGED performance issue. Bad news, poor Calibre performance, and a bit of a bad assumption in UNCaGED.

So, it turns out that when receiving a booklist with several hundred/thousand books (not the full metadata), Calibre takes it's sweet, sweet time to process the list.

Which leads into the bad assumption in UNCaGED. It assumes that a properly functioning connection to Calibre will always have some activity on the connection every few seconds (either by Calibre sending/receiving data, or a heartbeat), so it sets (or did) a relatively short connection timeout of 15 seconds, which is far longer than the standard Calibre heartbeat frequency.

Wee problem. When Calibre is processing the booklist, it is not sending a heartbeat. Thus, the connection times out, KU exits.

Simple fix is to increase the UNCaGED timeout across the board. More complicated fix is to set a timeout based on the number of books in the booklist. Or, I could drop the connection timeout completely.

shermp commented 4 years ago

Just a friendly update to tell you there is no update.

For more details, I finally purchased Nier Automata during a half-price sale. For some reason, it's taking up all my spare time. Can't think why... Who knows when I'll be done... 😁

NiLuJe commented 4 years ago

For the glory of mankind ;).

(Enjoy, it's a fairly unique experience!)

Fair warning: you'll be humming the various themes in the shower for... the foreseeable future :D.

NiLuJe commented 4 years ago

Who knows when I'll be done... 😁

It may be a while... :D NierA

shermp commented 4 years ago

Who knows when I'll be done... 😁

It may be a while... :D NierA

Haven't quite got that far yet 😁

Currently a fair way through [c] (I think)

shermp commented 4 years ago

Well. That was a thing. I'm gonna need some time to recover...

I shall hopefully return to your regularly scheduled service in a few days.

pgaskin commented 4 years ago

For the glory of mankind ;)

Ohh, I just realized that reference... 🤣

Anyways, take your time @shermp. I've been quite busy myself recently, so I won't really be around much for another week or two.

shermp commented 3 years ago

Right, I'm back. A bit later than planned. I had a deadline to finish some VHD stuff, so got that out the door first.

Let's get this finished. I've made more tweaks to upstream UNCaGED regarding the TCP connection deadline. Made a few appearance tweaks. Improved progress handling for receiving books. Added progress handling for deleting books.

shermp commented 3 years ago

Ok. I think I'm going to call this done, feature wise, at least for now. A new release is long overdue.

@NiLuJe @pgaskin would you be willing to test and review this PR please?

pgaskin commented 3 years ago

Yes, either tomorrow or the next day.

NiLuJe commented 3 years ago

First connection (starting with WiFi off) weirdly failed:

Nov 16 18:07:32 KoboUNCaGED[5806]: 2020/11/16 18:07:32 Start: establishing connection failed: establishTCP: dialling calibre failed: dial tcp: address tcp/hello: unknown port
Nov 16 18:07:32 KoboUNCaGED[5806]: 2020/11/16 18:07:32 Start: establishing connection failed: establishTCP: dialling calibre failed: dial tcp: address tcp/hello: unknown port
Nov 16 18:07:32 UNCaGED: Running precautionary library rescan
Nov 16 18:07:32 nickel: (  1249.513 @ 0x154adf0 / packetdump.warning) "http://127.0.0.1:8181/messages" => "Connection closed" 
Nov 16 18:07:34 nickel: (  1251.235 @ 0x154adf0) QObject::disconnect: Unexpected null parameter
Nov 16 18:07:34 nickel: (  1251.237 @ 0x154adf0 / ui.warning) cancelled before full sync has started 
Nov 16 18:07:36 nickel: (NickelMenu) MainNavView::MainNavView(0x19720b8, (nil)) (src/nickelmenu.cc:233)
Nov 16 18:07:36 nickel: (NickelMenu) Adding main menu button in tab bar for firmware 4.23.15505+. (src/nickelmenu.cc:236)
Nov 16 18:07:36 nickel: (NickelMenu) Added button. (src/nickelmenu.cc:364)
Nov 16 18:07:38 nickel: (  1255.387 @ 0x154adf0 / packetdump.warning) "http://127.0.0.1:8181/messages" => "Operation canceled" 

Second attempt was successful, on the other hand ;).

Random comment: most debug log messages appear to be truncated, is that expected?

NiLuJe commented 3 years ago

Calibre also appears to be sending the thumbnail metadata and storing it in metadata.calibre. That's mostly unnecessary here (it's only used by Calibre's Device view), and just clogs it up.

(The Kobo driver doesn't, FWIW, it's set to null).

Same thing for the cover entry, actually: it's set to the host Calibre's temporary conversion path, e.g., "cover": "/tmp/calibre_5.5.0_tmp_ombgspm2/ryamowqy_dbcover.jpg",, whereas it's null via the Kobo driver.

c.f., jq '.[] | select(.thumbnail)' < /mnt/onboard/metadata.calibre to pull titles with a thumbnail set out of there.

shermp commented 3 years ago

1

First connection (starting with WiFi off) weirdly failed:

Not quite sure what happened there.

Random comment: most debug log messages appear to be truncated, is that expected?

Yeah, I'm tuncating the TCP payload data to avoid spamming the log too much.

Calibre also appears to be sending the thumbnail metadata and storing it in metadata.calibre. That's mostly unnecessary here (it's only used by Calibre's Device view), and just clogs it up.

Oof, I used to strip that out. Must have got missed in the refactors. Thanks for the heads up!

Same thing for the cover entry, actually: it's set to the host Calibre's temporary conversion path, e.g., "cover":

Yeah, should be able to null that as well.

shermp commented 3 years ago

@NiLuJe I've refactored the Calibre discovery process in UNCaGED, and updated this PR to use it. On my end, finding calibre seems to be more reliable now. Would you mind trying it a few times on your end?

I wasn't happy with the previous code. I've ran into discovery issues more than once with the old code. I'm hoping the new code will be better.

NiLuJe commented 3 years ago

@shermp: No issues so far ;).

Random comment about mDNS: I have no idea how this stuff works, but avahi-browse sees it, FWIW:

+ enp0s31f6 IPv4 Books in calibre (on illyria port 8080)       _calibre._tcp        local
+     lo IPv4 Books in calibre (on illyria port 8080)       _calibre._tcp        local
+ enp0s31f6 IPv4 calibre smart device client (on illyria port 9090) _calibresmartdeviceapp._tcp local
+     lo IPv4 calibre smart device client (on illyria port 9090) _calibresmartdeviceapp._tcp local
shermp commented 3 years ago

@shermp: No issues so far ;).

Random comment about mDNS: I have no idea how this stuff works, but avahi-browse sees it, FWIW:

+ enp0s31f6 IPv4 Books in calibre (on illyria port 8080)       _calibre._tcp        local
+     lo IPv4 Books in calibre (on illyria port 8080)       _calibre._tcp        local
+ enp0s31f6 IPv4 calibre smart device client (on illyria port 9090) _calibresmartdeviceapp._tcp local
+     lo IPv4 calibre smart device client (on illyria port 9090) _calibresmartdeviceapp._tcp local

Yeah, I had mixed results. My Windows install of Calibre just wasn't showing, but a Linux install did. I don't know why. Also couldn't get a Go library to show anything.

NiLuJe commented 3 years ago

My previous home network was notoriously hostile towards Bonjour, FWIW, half of the devices on the network failed to discover a wireless printer. Things have been much better since I swapped modem & Wi-Fi AP with the switch to FTTH.

But, yeah, this stuff feels like minor black magic to me ^^.

shermp commented 3 years ago

The calibre broadcast system is certainly simpler and pretty bullet-proof, but is limited to the broadcast domain of the local network.

NiLuJe commented 3 years ago

On the off-chance someone will ask later: is it currently possible to feed an IP:port manually, for these corner-cases where it'd need to cross a subnet (or, god forbid, access it over WAN o_O)?

shermp commented 3 years ago

I haven't implemented it, but the new code will allow for it.

Need to figure out how best to implement it in the GUI.

NiLuJe commented 3 years ago

One failed attempt (cold caches, with Wi-Fi off)

Nov 22 05:30:59 KoboUNCaGED[1825]: 2020/11/22 05:30:59 Preparing Kobo UNCaGED!
Nov 22 05:31:04 KoboUNCaGED[1825]: 2020/11/22 05:31:04 New: Could not find calibre instance: calibre server not found
Nov 22 05:31:04 KoboUNCaGED[1825]: 2020/11/22 05:31:04 New: Could not find calibre instance: calibre server not found
Nov 22 05:31:04 nickel: (   869.457 @ 0x154adf0 / packetdump.warning) "http://127.0.0.1:8181/messages" => "Connection closed" 
shermp commented 3 years ago

Sigh... I was hoping the new way might be a bit more reliable 😢

Unfortunately, it's all UDP, so absolutely no guarantees about packets arriving in any direction. For each port that Calibre could potentially listen on, I send a message thrice at approximately 250ms apart. It gives up if no reply is received after 1 second from sending out the first 'hello' packet.

shermp commented 3 years ago

More error checking and logging were added to UNCaGED to see if we can narrow down the discovery issues noted by @NiLuJe

Could just be network issues I can't do anything about, but the logging should hopefully give a bit more info on the process.

NiLuJe commented 3 years ago

As luck would have it, I was just typing "haven't managed to break it today", while running a final test... and that one failed ;p.

Nov 23 17:45:03 KoboUNCaGED[3327]: 2020/11/23 17:45:03 [DEBUG] discoverSmartBCast: wrote 'hello' packet to port 54982
Nov 23 17:45:03 KoboUNCaGED[3327]: 2020/11/23 17:45:03 [DEBUG] discoverSmartBCast: wrote 'hello' packet to port 48123
Nov 23 17:45:03 KoboUNCaGED[3327]: 2020/11/23 17:45:03 [DEBUG] discoverSmartBCast: wrote 'hello' packet to port 39001
Nov 23 17:45:03 KoboUNCaGED[3327]: 2020/11/23 17:45:03 [DEBUG] discoverSmartBCast: wrote 'hello' packet to port 44044
Nov 23 17:45:03 KoboUNCaGED[3327]: 2020/11/23 17:45:03 [DEBUG] discoverSmartBCast: wrote 'hello' packet to port 59678
Nov 23 17:45:03 KoboUNCaGED[3327]: 2020/11/23 17:45:03 [DEBUG] discoverSmartBCast: wrote 'hello' packet to port 54982
Nov 23 17:45:03 KoboUNCaGED[3327]: 2020/11/23 17:45:03 [DEBUG] discoverSmartBCast: wrote 'hello' packet to port 48123
Nov 23 17:45:03 KoboUNCaGED[3327]: 2020/11/23 17:45:03 [DEBUG] discoverSmartBCast: wrote 'hello' packet to port 39001
Nov 23 17:45:03 KoboUNCaGED[3327]: 2020/11/23 17:45:03 [DEBUG] discoverSmartBCast: wrote 'hello' packet to port 44044
Nov 23 17:45:04 KoboUNCaGED[3327]: 2020/11/23 17:45:04 [DEBUG] discoverSmartBCast: wrote 'hello' packet to port 59678
Nov 23 17:45:04 KoboUNCaGED[3327]: 2020/11/23 17:45:04 [DEBUG] discoverSmartBCast: wrote 'hello' packet to port 54982
Nov 23 17:45:04 KoboUNCaGED[3327]: 2020/11/23 17:45:04 [DEBUG] discoverSmartBCast: wrote 'hello' packet to port 48123
Nov 23 17:45:04 KoboUNCaGED[3327]: 2020/11/23 17:45:04 [DEBUG] discoverSmartBCast: wrote 'hello' packet to port 39001
Nov 23 17:45:04 KoboUNCaGED[3327]: 2020/11/23 17:45:04 [DEBUG] discoverSmartBCast: wrote 'hello' packet to port 44044
Nov 23 17:45:04 KoboUNCaGED[3327]: 2020/11/23 17:45:04 [DEBUG] discoverSmartBCast: wrote 'hello' packet to port 59678
Nov 23 17:45:04 KoboUNCaGED[3327]: 2020/11/23 17:45:04 [DEBUG] discoverSmartBCast: read timed out

As opposed to the earlier results, which often looked like:

Nov 23 17:34:22 KoboUNCaGED[3137]: 2020/11/23 17:34:22 [DEBUG] discoverSmartBCast: wrote 'hello' packet to port 54982
Nov 23 17:34:22 KoboUNCaGED[3137]: 2020/11/23 17:34:22 [DEBUG] discoverSmartBCast: wrote 'hello' packet to port 48123
Nov 23 17:34:22 KoboUNCaGED[3137]: 2020/11/23 17:34:22 [DEBUG] discoverSmartBCast: wrote 'hello' packet to port 39001
Nov 23 17:34:22 KoboUNCaGED[3137]: 2020/11/23 17:34:22 [DEBUG] discoverSmartBCast: wrote 'hello' packet to port 44044
Nov 23 17:34:22 KoboUNCaGED[3137]: 2020/11/23 17:34:22 [DEBUG] discoverSmartBCast: wrote 'hello' packet to port 59678
Nov 23 17:34:22 KoboUNCaGED[3137]: 2020/11/23 17:34:22 [DEBUG] discoverSmartBCast: wrote 'hello' packet to port 54982
Nov 23 17:34:22 KoboUNCaGED[3137]: 2020/11/23 17:34:22 [DEBUG] discoverSmartBCast: wrote 'hello' packet to port 48123
Nov 23 17:34:22 KoboUNCaGED[3137]: 2020/11/23 17:34:22 [DEBUG] discoverSmartBCast: wrote 'hello' packet to port 39001
Nov 23 17:34:22 KoboUNCaGED[3137]: 2020/11/23 17:34:22 [DEBUG] discoverSmartBCast: wrote 'hello' packet to port 44044
Nov 23 17:34:22 KoboUNCaGED[3137]: 2020/11/23 17:34:22 [DEBUG] discoverSmartBCast: wrote 'hello' packet to port 59678
Nov 23 17:34:22 KoboUNCaGED[3137]: 2020/11/23 17:34:22 [DEBUG] discoverSmartBCast: wrote 'hello' packet to port 54982
Nov 23 17:34:22 KoboUNCaGED[3137]: 2020/11/23 17:34:22 [DEBUG] discoverSmartBCast: wrote 'hello' packet to port 48123
Nov 23 17:34:22 KoboUNCaGED[3137]: 2020/11/23 17:34:22 [DEBUG] discoverSmartBCast: wrote 'hello' packet to port 39001
Nov 23 17:34:22 KoboUNCaGED[3137]: 2020/11/23 17:34:22 [DEBUG] discoverSmartBCast: wrote 'hello' packet to port 44044
Nov 23 17:34:22 KoboUNCaGED[3137]: 2020/11/23 17:34:22 [DEBUG] discoverSmartBCast: wrote 'hello' packet to port 59678
Nov 23 17:34:23 KoboUNCaGED[3137]: 2020/11/23 17:34:23 [DEBUG] discoverSmartBCast: received reply from 192.168.1.42
Nov 23 17:34:23 KoboUNCaGED[3137]: 2020/11/23 17:34:23 [DEBUG] discoverSmartBCast: name: illyria port: 9090
Nov 23 17:34:23 KoboUNCaGED[3137]: 2020/11/23 17:34:23 [DEBUG] discoverSmartBCast: received reply from 192.168.1.42
Nov 23 17:34:23 KoboUNCaGED[3137]: 2020/11/23 17:34:23 [DEBUG] discoverSmartBCast: name: illyria port: 9090
Nov 23 17:34:23 KoboUNCaGED[3137]: 2020/11/23 17:34:23 [DEBUG] discoverSmartBCast: received reply from 192.168.1.42
Nov 23 17:34:23 KoboUNCaGED[3137]: 2020/11/23 17:34:23 [DEBUG] discoverSmartBCast: name: illyria port: 9090
Nov 23 17:34:23 KoboUNCaGED[3137]: 2020/11/23 17:34:23 [DEBUG] discoverSmartBCast: read timed out

(I've seen multiple types of results, from a single to three replies. To, well, none when it fails ;p. But very rarely do I get a reply in the timeframe of the first salve of packets).

This is in direct correlation with how busy the Wi-Fi is at the time, FWIW (apartment complex, and we're stuck on 2.4GHz on Kobos, so, it's a bit of a free-for-all, despite a fairly good showing from my AP, since I'm like two sheetrocks and one concrete wall away from it. Not really far, because that's technically the next room, but there's a small corridor and a bunch of stuff in the way ;)).

NiLuJe commented 3 years ago

iwconfig output, FWIW (on a H2O; the format tends to be driver-specific to a certain extent, from my experience with it compared to the Forma):

eth0      IEEE 802.11-DS  ESSID:"Serenity"  Nickname:""
          Mode:Managed  Frequency:2.472 GHz  Access Point: AA:BB:CC:DD:EE:FF   
          Bit Rate=65 Mb/s   Tx-Power:32 dBm   
          Retry min limit:7   RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality=4/5  Signal level=-62 dBm  Noise level=-92 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:23  Invalid misc:0   Missed beacon:0

The Forma usually manages to sync at higher bitrates (usually around twice that), not that it matters much in practice ^^.

(That's a 2.4GHz only ESSID/BSSID combo, the 5GHz one is on a separate pair.)

shermp commented 3 years ago

% Yeah, congested networks and UDP don't really play nice together unfortunately.

The only thing I can really think of doing is to brute force things by maybe looping the discover function a couple of times if no results were found the first time.

Or, I could concentrate on the one port, as 99% of the time Calibre will be listening on port 54982 (it only binds to one of the others if 54982 is unavailable, which in most cases will never happen).

pgaskin commented 3 years ago

@NiLuJe, it might not necessarily be your network.

I've tested my Kobos in a relatively clean environment, and I sometimes get large bursts of packet loss and jitter. As in, telnet freezes for 2-3 seconds, then shows the input with ~100ms between each character. I suspect it's something to do with the wireless card in the Kobo.