On 30/8/22 10:39, Eyal Lebedinsky wrote:
On 28/08/2022 18.25, Eyal Lebedinsky wrote:
> f36, just updated and received
> thunderbird-librnp-rnp-102.2.0-1.fc36.x86_64
> from thunderbird-91.12.0-1.fc36.x86_64
>
> tb brings up the expected display but no input is accepted. The
> process is shown as running with 100% CPU
> PID USER PR NI VIRT RES SHR S %CPU %MEM
> TIME+ COMMAND
> 72149 eyal 20 0 4075036 772700 223612 R 100.3 2.4
> 5:26.57 thunderbird
> It will not refresh(*) the panel and will start responding after
> about 1h.
> [later] I see the panel was refreshed after 50m
> but input was still not accepted and the display will not
> refresh. It resolved after 70m.
> After this is seems to be OK, I can read mail etc.
>
> To be sure, I made a copy of the profile where I deleted all the .msf
> files and observed the same thing.
> I tried this a few times.
>
> It is not just a one-off post-upgrade process. After it recovers and
> works, if I shut tb down and launch it
> then it repeats the problem.
>
> There are not too many emails here, maybe a few tens of thousand
> totaling just over 1GB (a few mailing lists).
>
> My main mail client is on another machine, still running tb 91, and
> not showing this problem.
>
> Searching the 'net I did not find a relevant report, where should I
> look?
>
> BTW, after reading the release notes, seeing the structural changes,
> I wonder if it is at all possible
> to downgrade to v91?
>
> TIA
>
> (*) "not refreshed" means the panel is not painted after
> minimize/restore, showing only a border.
A progress update.
After trying a few solutions (unsuccessfully) I compared an empty
profile (working, created as a test)
to the bad one (hanging) and started moving some control files (file
in the root of the profile) across.
The last thing I did was replace the calendar-data with the one from
the empty profile and this solved
the problem. I was not using the calendar for a few years so
completely forgot it is there. It had
drwxr-xr-x 2 eyal eyal 4096 Sep 18 2021 backup
-rw-r--r-- 1 eyal eyal 2359296 Jan 27 2020 cache.sqlite
-rw-r--r-- 1 eyal eyal 524288 May 30 2020 deleted.sqlite
-rw-r--r-- 1 eyal eyal 66256896 Jul 7 10:56 local.sqlite
Notice the largish (66MB) database. It is now (copied from the empty
profile)
-rwx------ 1 eyal eyal 819200 Aug 29 09:33 local.sqlite
I wonder if it is only the cache file that was the cause or the whole
directory.
[later] No, copying in a fresh cache file did not help, I needed to
copy in a fresh
local.sqlite
I checked my V106 folders and I have the same backup folder and
contents
that you do, I also have the deleted.sqlite and local.sqlite, but
because I hardly ever, if at all, use the calendar my local.sqlite is
only 800K in size. I don't have the cache.sqlite file so I'm not sure
where that is coming from, but I also haven't paid much attention to the
configuration since I originally set TB up on the fresh install I did
some time ago. Also being on the daily version of TB it gets updated
every day which may have some impact on keeping it clean.
I'm not sure about emptying the junk folder automatically, my
interpretation of the junk process was the mails have to remain in that
folder for the junk processing to determine a new mail is junk according
to your rules, so if you manually delete the files from the junk folder,
as you have said, you will potentially have to retrain TB, but I would
expect that retraining to start filling up that folder again.
regards,
Steve
As I see it, there is an issue with the upgrade process where the
(v91) calendar is somehow incompatible
with the new version. I can understand a once-off long conversion of
the database but not a permanent
(every startup) process. Luckily I did not need to keep the calendar
data.
BTW, I do not know if the calendar-data/backup is something I created
or tb created during an update,
but the last file there is named
local.v22.sqlite
with a date matching the update to v91. There is no backup file from
the recent v102 update.
Next I need to update my main mail machine which has much more data,
and I am still hesitant...