Tiddlyhost saving problems for Windows users

Over in this GitHub issue there are some Tiddlyhost users having trouble saving. The current theory is that it’s specific to Windows, so I thought I’d ask here and try to get some extra data points to support or refute that. Some questions:

  • Are there any Windows Tiddlyhost users out there?
  • If so, does saving on Tiddlyhost work for you?
  • If not, did it never work, or did it stop working recently?
  • Anyone have an idea what the problem could be?
1 Like

Seems to work for me…Windows 11 user…tiddlywiki 5.3.1 using Firefox 130.0 (64-bit). I only made a one line change however so if it is something to do with file sizes, upload speeds and bandwidth I wouldn’t imagine I’d run into problems.

Windower here.

Saving does work but there are irregular delays compared to when the discussions about it started. The other day I got a (single) time out but prior to that it was probably weeks ago. But before the discussions started I don’t think I ever got time outs. And I’ve been a user for… since you started it, I guess?

On a postive note: When just now checking to see how fast it is to load a TW from the Your sites page, it is possibly faster than ever!!!(???) Whoff, where did that come from?

Simon, feel free to email me privately if you want me to run test you come up with (…assuming I understand how to run them).

Some parameters to consider:

  • wikis of different sizes
  • which browser is used (I use Brave, a Chrome variant)
  • VPN (I typically use one)
  • TW version
  • hour of day

One idea for a coordinated test could be if people create a TH with a copy of tiddlywiki.‍com and save it at various times, and then report delay and their other data (OS, browser, etc).

Windows 11 user from Austria here
Using FF 130
Internet connection 300Mbit up / 300Mbit down

I did just upload: https://wip-toc-rewrite.tiddlyhost.com/
which is 9.6MB
It needed about 70 seconds to upload
First time load today about 10 seconds
Page refresh after save, to see if save worked: 2 seconds.

Hope that helps
-Mario

PS- Dev-tools say this: browser cache was disabled to get real values

1 Like

Saving again.

I will do a few vm tests on my machine at home just to see if it is reflected on my windows developer vm

1 Like

OS(s): Windows 11 LTSC, Windows 10 Enterprise
Browser(s): Ungoogled Chromium, Google Chrome, Microsoft Edge

Issues encountered so far:

  1. loonng save periods
  2. saving not going through, pause, prompted to reload because TW will override saved changes?
  3. odd behavior of logging in, navigating back to TW, still getting the 401 page and needing to log back in again?

So far these are the only things I’ve encountered when using Tiddlyhost, if any of that helps…

I might have some further data points to support the theory.

Most of the time I use TH on Windows, occasionally on Android, but then usually read-only.

A couple of days ago I struggled to save (or even manually upload a html file) from a Windows 10 device (various browsers: Brave, Vivaldi, Firefox) – the save times were a couple of minutes or longer, I did’t always have the patience to wait till the end. At the same time, saving or manual uploads worked smooth on a macOS and Android devices in the same network – save times of couple seconds.

Right now on the same wiki (3MB uncompressed external core) I see save times of about 3 minutes on Windows, and at the same time a couple of seconds on Android.

The problems on Windows started only recently, as the other discussion here on forum, it used to be smooth before.

I could perform some further tests if it could help you.

on a Macintosh (old MacBook Air, running Firefox browser 129.0.2 under MacOS 14.6.1) the intermittent TiddlyHost slowness (5-20 second delay) occurs ~5% of the time (when opening Tiddlyhost and when loading or saving https://zhurnaly.tiddlyhost.com/ ) – latest instance a few minutes ago this morning …

TiddlyHost is GREAT otherwise! :innocent:

Thanks everyone, much appreciated.

1 Like

This is happening to me again. 1.5 MB external core wiki. Saves from Android phone in a couple of seconds. Saves from Windows PC in the same home network in around 1–2 minutes.

1 Like

I have only got to test this now @simon see below in speculation for a possible clue

FireFox GA Bookmarks

  • Browser F12, Network tab
  • Open / Get / Reload less than 4 seconds
  • Save / Put around 1 min

Edge Bookmarks

  • Browser F12, Network tab (Wifi icon)
  • Open / Get / Reload less than 2 seconds
  • Save / Put around 1 min
  • It also took 1min to return a 403 when I was not logged in which may be a clue?

Chrome Bookmarks

  • Browser F12, Network tab
  • Open / Get / Reload less than 4 seconds (3.4seconds)
  • Save / Put around 1.1 min
  • It also took 1.1min to return a 403 when I was not logged in which may be a clue?

Speculation

Someone testing this on another platform such as IOS or Unix/linus is needed.

In recent versions a number of changes have being made to the http Put and Get functionality I wonder if a problem has suck in here?

Chrome namespaces site

  • Browser F12, Network tab
  • Open / Get / Reload less than 1.1 minutes
    • External core?
  • Save / Put around 1 min 12 seconds, PUT 1min, HEAD 12secs
    • Subsequently only 10 seconds and less
  • One Save / Put test failed with

504 Gateway Time-out


nginx/1.27.1

Hi Simon, I am on Windows 10 and use Chrome v128.0. Most of the time I am not able to reach my tiddlywiki on tiddlyhost, it gives me Bad gateway error multiple times and then loads very slowly. I am not able to save either. The problems with saving started smth like 2 weeks ago, before it was ok and I had to use it everyday since there are my PhD notes there (nothing heavy, only text). Otherwise tiddlyhost is always a great experience, thank you for keeping it alive.

Thanks @dmikh, @TW_Tones . This is concerning. I’m still puzzling about what the root cause might be. I’ll share any details or clues here and in GitHub.

@simon I just thought I would describe in words what I learned in my above research.

  • Use or dismiss and do your own analysis as you wish
  • I am providing this because its all in my head and its may not be helpful keeping it there, although I am not an expert it may help.

I used the network tab of the developer tools to monitor open and save actions against the bookmarklets tiddlyhost site which is Tw V5.3.5 and 3.6MB in size\ in multiple browsers.

  • I did this in FireFox, Chrome and Edge browsers all with similar results

I also observed the same for my namspaces site Tw V5.2.7 which is less than 1MB.

Conclusions

It does not seem to be related to a specific Browser (I only Tested on windows) or the size of the wiki as it takes similar times, even before a 403 (not logged in) and 305 error (gateway).

Given one case of my last test returned a “305 Gateway Time-out nginx/1.27.1” and it took a similar time to return 403 errors when not logged in the problem is possibly before even interacting with the site and suggests its occurring in the nginx.

  • I have never set up nginx which I understand to be a proxy/firewall, so cant suggest how to debug this.
  • I do not think this related to tiddlywiki versions

Possible further diagnostics

Since in many cases it works but still takes a lot of time it may be worth doing a network packet sniff against the PUT action to save. Similarly on another operating system if it is or is not occurring there.

  • You may see multiple attempts or only one attempt that takes a long time
  • You may see error messages that are returned which cause the delay

If there is any way to get log or messages from nginx you may find more information there.

Speculation

Perhaps a change in Windows networking or security combined with something in the proxy process ngnix is causing this?

  • Ensure nginx at latest version, or if at latest version return to previous
  • Test an old version of windows if available see @dmikh reply
  • Certainly test another OS
  • Test windows with the Firewall turned off (I will do this and report)
1 Like

I just tested this and get similar results, with or without the firewall turn on.

1 Like

Adding another (not very informative) response.
I’m a linux + windows user (relatively new to TW).
I ran into problems when saving from my windows machine (only started using TW recently, so cannot say if this is a new issue), from linux, it always works.
As of today, I was able to save from windows, but saving times were extremely slow (minutes).
My Windows machine uses Windows 11 Business, and I’m browsing using Firefox.
Hope it helps and thanks for keeping this project alive and kicking,
Uri

Saving via Firefox (115.15.0esr) on windows is especially slow in Mainland China (Shanghai). It took about 16 minutes to save a 4.7MB wiki. Looks like most of the time is spent on sending (according the developer tool in Firefox). While on android and iOS saving is very quick which is acceptable.

If so, does saving on Tiddlyhost work for you?

It worked when I started using Tiddlyhost, but it stopped working some time ago - sorry that I can’t remember the exact date. Now it isn’t saving anymore.

Anyone have an idea what the problem could be?

My best bet is that it looks like something related to network or network configuration, maybe proxy servers.
Why?
When I’m working over a VPN connection, it saves to Tiddlyhost reliable and fast.

[Edit]
Running on Windows 10, using Mozilla Firefox browser.
[/Edit]

Windows user running vivaldi. Was using tiddlyhost for quite a while with no problem, but in the last handful of months or so saving has taken unreasonably long.

After seeing this ticketed on GitHub I decided to test and realized that it will eventually save – but we are talking on the course of hours. I have been using it as a backup for my wiki, uploading the single-file to replace the existing one, and leaving it in the background.

But it’s not functional for daily use, only backup and reference.

Same issue on Android, for what it’s worth.

Have additionally tried to run with VPNs on and off windows firewall on and off, all different browser settings, and multiple browsers (all chromium based however). No change.