[plasmashell] [Bug 356225] Panel moves to wrong screen when external monitor is connected

2016-10-11 Thread Michael Butash via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=356225

--- Comment #203 from Michael Butash  ---
Justin, try clearing your various kde and plasma config files in your home
directory under .kde*, .config/plasma*, and anything else your distro might
hide in other locations.  Moving to neon, I had many of the same issues until I
did so, where something seems to not be getting normalized/sterilized when
migrating between them.

While not recommended to migrate directly from kubuntu to neon, it would be
nice if KDE would clean up and normalize its configuration files to prevent
this as part of a first-time launch of a newer revision of plasma and like for
any such generational jumps.

-- 
You are receiving this mail because:
You are watching all bug changes.


[plasmashell] [Bug 356225] Panel moves to wrong screen when external monitor is connected

2016-08-20 Thread Michael Butash via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=356225

--- Comment #180 from Michael Butash  ---
I type this up, go to do some other things, and notice that my taskbar jumped
over to the wrong display again.  :(

Apparently not fixed.

-- 
You are receiving this mail because:
You are watching all bug changes.


[plasmashell] [Bug 340267] Plasma crashes when a DisplayPort monitor sleeps

2016-08-20 Thread Michael Butash via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=340267

--- Comment #74 from Michael Butash  ---
Relevant note - the middle display that acted weird mostly was set to be the
primary display as well.  Prior, it acted like the task bar was polarized to
pretty much anything *but* it, but really odd disconnecting that one caused the
most odd effect, possibly due to being set as the primary.

I get lots of really odd compositing issues, mostly due to being a gigantic
framebuffer some video cards seem to not handle well ala 11520x2160.  I suspect
at times gpu processing contributes to weirdness, but not sure the graphic
diversity of the folks developing the platforms on.  I'm using AMD.

-- 
You are receiving this mail because:
You are watching all bug changes.


[plasmashell] [Bug 340267] Plasma crashes when a DisplayPort monitor sleeps

2016-08-20 Thread Michael Butash via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=340267

--- Comment #73 from Michael Butash  ---
Running 5.7.2+p16.04+git* as of last night seems to be far better behaved,
putting windows back after shutting down my tv/displays, as well as
hard-disconnecting each.

Oddly though, I got weirdness when I was disconnecting each display in a test. 
Went sort of like this:

1) Disconnected far right display, port 0
  - display removed, migrated windows and desktop to adjacent displays
normally, worked as expected.
2) Disconnected middle display, port 1
  - Display removed, migrated windows, but wallpaper went blank on one of the
two remaining displays, and kwin seemed to fall out of compositing mode with
cairo-dock showing banded lines as a sign of compositing being off/broken. 
Plugged it back in, and it moved everything back with full wallpapers normally
as I would expect.
3) Disconnected Left display, port 2
  - Display removed, migrated windows and desktop to adjacent displays, behaved
normally.
4) Disconnected Left display, port 2 again, was going to test removing
multiples
  - Display removed and all screens went blank, none initializing and displays
showing no connected input sources.  Reconnected port 2, and all displays came
back.

Needless to say, it *sort of* works, but inconsistent.  Definitely an
improvement, but still seems to leave something to be desired.

-- 
You are receiving this mail because:
You are watching all bug changes.


[plasmashell] [Bug 356225] Panel moves to wrong screen when external monitor is connected

2016-08-20 Thread Michael Butash via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=356225

--- Comment #179 from Michael Butash  ---
Running 5.7.2+p16.04+git* in neon unstable ppa as of last night seems to be far
more behaved in use today, putting the task bar where I want it, and not
crashing oddly when I switch desktops with a mouse scrolls.  Disconnecting each
display at the video card mostly worked, putting the taskbar and other windows
back after, but with some anomalies with losing wallpaper and compositing. 
Fodder for another bug report.

Thanks for work on stabilizing this, very much appreciated!

-- 
You are receiving this mail because:
You are watching all bug changes.


[dolphin] [Bug 358475] Single click to open option missing in Dolphin. This was reported as Bug 353645, but incorrectly closed.

2016-08-20 Thread Michael Butash via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=358475

--- Comment #5 from Michael Butash  ---
More grumbling, but the odd thing for me was installing the ppa for unstable
neon to fix my multi-monitor issues, and noticed dolphin just began annoyingly
resorting to single-click behaviour.  I couldn't influence this from where I
found it prior, so thought this a bug.  

Migrating to a global level configuration as a system setting might be ok, but
to me it is relevant only to Dolphin as my file manager of choice, and suddenly
changed/gone from what it was prior, created quite a bit of usability issues
for me.

Graceful changes would be appreciated.

-- 
You are receiving this mail because:
You are watching all bug changes.


[dolphin] [Bug 358475] Single click to open option missing in Dolphin. This was reported as Bug 353645, but incorrectly closed.

2016-08-20 Thread Michael Butash via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=358475

--- Comment #4 from Michael Butash  ---
Oh hell, it's been a while since I've had to look at input settings, I never
thought to look for it there.  I didn't realize it moved there, and apparently
not the only one.  Thank you, as I found the setting there and fixed this.

That single or double click behaviour being moved to a more global thing is a
bit odd, I didn't even think to look for it at an input level, rather poking
and prodding at dolphin directly.  UI Dev's for Dolphin this might want to
suggest/link to that in input settings at very least, and/or just influence the
setting directly from dolphin again, this has been really annoying me until now
under neon from 5.5 in ubuntu 16.04.

-- 
You are receiving this mail because:
You are watching all bug changes.


[dolphin] [Bug 358475] Single click to open option missing in Dolphin. This was reported as Bug 353645, but incorrectly closed.

2016-08-10 Thread Michael Butash via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=358475

Michael Butash  changed:

   What|Removed |Added

 CC||mich...@butash.net

--- Comment #2 from Michael Butash  ---
I've suddenly since upgrading to 5.7.2 Neon had to research this, as it seems
to only use the single click option, and as you stated, does not present an
option otherwise to change and have the double-click.  The option is nowhere I
can find in Dolphin navigation with v16.11.70.

I confirmed it is set to this in kdeglobals, but "SingleClick=false" seems
ignored.  

[KDE]
AutoSelectDelay=-1
ChangeCursor=true
DoubleClickInterval=400
ShowDeleteCommand=false
ShowIconsInMenuItems=true
ShowIconsOnPushButtons=true
SingleClick=false

-- 
You are receiving this mail because:
You are watching all bug changes.


[plasmashell] [Bug 361672] Plasma Ignores the KWin Setting of Disabling "Desktop navigation wraps around"

2016-08-09 Thread Michael Butash via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=361672

Michael Butash  changed:

   What|Removed |Added

 CC||mich...@butash.net

--- Comment #1 from Michael Butash  ---
I am having this same problem, further more I noticed as of 5.7 upgrade to
neon, it causes a kwin crash as well to break compositing.  If I untick
"Desktop navigation wraps around", and cause an infinite loop of the desktops,
kwin does not crash.

Same as above to reproduce, but Mouse scroll causes kwin to crash as well.

-- 
You are receiving this mail because:
You are watching all bug changes.


[kwin] [Bug 366081] kwin's windows stay translucent after moving, become invisible

2016-08-03 Thread Michael Butash via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=366081

--- Comment #13 from Michael Butash  ---
Side note too, Martin's example to reproduce does not work for me, not after a
fresh reboot last night and minimal activity until today.  I switch a lot of
windows back and forth, even between desktops, and doing so does not
immediately manifest itself after reboots.  It's only after some time (~1-2
days) that this starts occurring normally, and sometimes moving just on the
same screen triggers it.

I just had Okular get peculiar, where I'd minimize and leave an impression of
the translucent window stuck in the compositing I couldn't remove, where
un-minimizing it, behaved perfectly normal until minimizing again, resulting in
"ghost". 

Such as:
1. Open url to download PDF, default to Okular reader.
2. Navigate document paging through.
3. Minimize document, leaves resulting translucent ghost image on screen,
cannot remove/manipulate.
4. Un-Minimize Okular, window reappears in focus, can move window normally.
5. Leave Okular on desktop, work with other applications, come back to read pdf
10 minutes later on screen, minimize works normally again.

More odd "coming and going" of these issues with compositing and general
destabilization over time.

-- 
You are receiving this mail because:
You are watching all bug changes.


[kwin] [Bug 366081] kwin's windows stay translucent after moving, become invisible

2016-08-03 Thread Michael Butash via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=366081

--- Comment #12 from Michael Butash  ---
Not sure how related, but I had a weird echo in the dimming module as well as
translucency, as I use both to make non-focus apps somewhat
ghosted/backgrounded.  I've observed when I get the ghosting, clicking between
two ghosted windows repeatedly causes them to continually dim further with the
translucency and never returning to full focus, thus the "echo" comment.  It
just keeps dimming until it's unviewable, or I restart compositing.

This seems to be present in more modules than just translucency potentially?

-- 
You are receiving this mail because:
You are watching all bug changes.


[plasmashell] [Bug 340267] Plasma crashes when a DisplayPort monitor sleeps

2016-08-03 Thread Michael Butash via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=340267

--- Comment #70 from Michael Butash  ---
It is really confusing where to begin to troubleshoot it, as I can't tell how
much is related to kwin, plasmashell, or libqt underneath.  Especially the
first time having to dig into KDE behind the scenes, but I've really loved the
5.x generation enough to want to try to fix this.

The only thing I will still add, that seems loosely related is that when I do
get kwin to crash, which is now happening more, it still seems to lose its
sense of identity among applications bound to which display.  When triggered,
things like the wall papers shuffle every time monitors come and go, or when
kwin crashes in particular.  

Also my taskbar can never figure out what display to end up on despite what I
set the primary display to.  It does at first, but then, doesn't after time,
really almost randomly lands, but never where it's supposed to - very odd. 
Almost like a non-obvious display index is getting broken, but at qt, plasma,
or kwin, not sure as they all seem to use/contribute in some way.  Plasmoids as
well acted oddly, crashing, ghosting between displays, etc.  

All seem related to core multi-monitor function, as unplugging just one,
reshuffles things, fixing some, breaking/shuffling others.  Finding the root of
that "shuffling" or random landing of apps on display among identities seems
key.

-- 
You are receiving this mail because:
You are watching all bug changes.


[kwin] [Bug 366081] kwin's windows stay translucent after moving, become invisible

2016-07-30 Thread Michael Butash via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=366081

Michael Butash  changed:

   What|Removed |Added

 CC||mich...@butash.net

--- Comment #8 from Michael Butash  ---
like Sebastian, I see this and the ghost windowing as well.  I hadn't seen this
in Neon until almost 3-4 days later, now today after a reboot due to plasma
consuming 200% of my cpu cores, the windows staying translucent/dimmed is
happening immediately.  I posted my support info from kwin in Bug 342716, happy
to provide whatever else helps you fix these.

-- 
You are receiving this mail because:
You are watching all bug changes.


[plasmashell] [Bug 366227] System Settings under Display and Monitor does not scale viewport

2016-07-28 Thread Michael Butash via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=366227

--- Comment #1 from Michael Butash  ---
Created attachment 100367
  --> https://bugs.kde.org/attachment.cgi?id=100367&action=edit
Screen shot of System Settings with monitors extending past viewport

Here's an image of my settings with the mega default display.  I can't zoom in
or out to manage this without extending the window to be gigantically wide.

-- 
You are receiving this mail because:
You are watching all bug changes.


[plasmashell] [Bug 366227] New: System Settings under Display and Monitor does not scale viewport

2016-07-28 Thread Michael Butash via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=366227

Bug ID: 366227
   Summary: System Settings under Display and Monitor does not
scale viewport
   Product: plasmashell
   Version: 5.7.2
  Platform: Ubuntu Packages
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: Multi-screen support
  Assignee: aleix...@kde.org
  Reporter: mich...@butash.net
CC: plasma-b...@kde.org

When I access Display and Monitor from System Settings with 3x 48" 4k TV's, a
generally small window, the monitor representation is far too huge for the
viewport used to rearrange the displays.  They need to scale with the dpi to
represent a usable configuration.  I'll attach an image of what I mean, it's
just a UI bug for abnormal sized displays vs. dpi, but makes reordering the
displays a gigantic pain, requiring me to open the settings window to like
3500x1200 to reorder things comfortably.

Reproducible: Always

Steps to Reproduce:
1. Install multiple 4k tv (3x used in test bed)
2. Open "System Settings", navigating to "Display and Monitors"
3. Observe abnormally giant representation of monitors taking up 90% of the
viewport, making it impossible to reorder displays without expanding the
settings window to gigantic proportions.

Actual Results:  
It requires resizing of the window to almost a full display width of 3500
pixels + to manage moving displays comfortably vs. the display scaling itself
according to the viewport and dpi.

Expected Results:  
Smaller representations of 3x monitors scaled into the viewport to reorder them
comfortably within the given pixel space available.  Monitors x Quantity Wide
should always equal less than the viewport, scaled to the space available, or
resize itself appropriately for the user to manage this.

This is more dpi optimization needed with changing usages.  I am using 3x 48"
hdtv's as my monitors now, something of a corner case, but I'd imagine this
exacerbated with current generation 4k displays in 24-34" desktop displays
shipping @ 4k too.

-- 
You are receiving this mail because:
You are watching all bug changes.


[kwin] [Bug 342716] translucency effect causes zombie when closing a window (likely due to multiple and uncancelled "set" calls)

2016-07-28 Thread Michael Butash via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=342716

--- Comment #22 from Michael Butash  ---
Created attachment 100362
  --> https://bugs.kde.org/attachment.cgi?id=100362&action=edit
qdbus kwin supportInformaton

-- 
You are receiving this mail because:
You are watching all bug changes.


[kwin] [Bug 342716] translucency effect causes zombie when closing a window (likely due to multiple and uncancelled "set" calls)

2016-07-28 Thread Michael Butash via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=342716

Michael Butash  changed:

   What|Removed |Added

 CC||mich...@butash.net

--- Comment #21 from Michael Butash  ---
I began noticing this after upgrading to unstable neon this weekend from ubuntu
16.04 stock, where I'm getting ghost windows when removing them.  I am also
seeing translucency not restoring to non-translucent on active windows at
times.  Both cases, I usually hot-key restart compositing, and it behaves again
for a few hours.  I use this as well with dimming, going to try without dimming
to see if some combination of both.

Posting support info as well if it helps.

-- 
You are receiving this mail because:
You are watching all bug changes.


[plasmashell] [Bug 356225] Panel moves to wrong screen when external monitor is connected

2016-07-28 Thread Michael Butash via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=356225

--- Comment #166 from Michael Butash  ---
@Simone Gaiarin, I deleted anything ^plasma in .config and .cache, that seemed
mostly sufficient to reboot into neon after the ppa upgrade.  I wanted to start
it clean as possible here, seemed mostly to do that.  I had to re-setup the
displays, desktop stuff in general in settings again.  Color themes persisted
oddly, but that might be more symlinked elsewhere.

My issues are same as @Frans Leerink desktop image and others, task bar won't
follow what it is set to.  This seems a more nested problem as windows have a
hard time figuring out where to go back to at times, so other features can't
figure out which display is which either..

-- 
You are receiving this mail because:
You are watching all bug changes.


[plasmashell] [Bug 340267] Plasma crashes when a DisplayPort monitor sleeps

2016-07-27 Thread Michael Butash via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=340267

--- Comment #64 from Michael Butash  ---
Mine has been surprisingly stable since upgrading to 5.7.2 and qt 5.7.0.  No
crashes, all 3 being shut on and off in various orders, left off, and back on
the next day.  It'd always be toast by morning and broken while off.

Not sure if related to the multi-monitors in some way, but still seems unstable
with longer use sessions over time.  I used window dimming + transparency, and
after 2 days of monitors on and off, was still functional, but windows wouldn't
un-dim and un-transparent when focused on.  Restarting kwin with shift-alt-f12
fixed it, but seems to start doing it again later.

-- 
You are receiving this mail because:
You are watching all bug changes.


[plasmashell] [Bug 356225] Panel moves to wrong screen when external monitor is connected

2016-07-24 Thread Michael Butash via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=356225

--- Comment #160 from Michael Butash  ---
I did the same thing yesterday upgrading to neon 5.7.2 with libqt 5.7.0, and
shutting off the displays for a while, then coming back didn't cause it to
freak out as it normally did.  This was only once though so far.  I'm going to
shut down displays when going to bed, almost always by morning it's be wacky
and requiring a reboot to normalize.

Seems like once the displays were detached, a quick on and off wouldn't cause
symptoms always, but more like if displays were gone, and some event occurred,
it began spiraling downhill fast.

Sadly my taskbar still can't seem to stay in the proper display still, and
attempting to move it just jumbled all my wallpaper orders, but here's hoping
multi-monitor is less infuriating soon in kde!

-- 
You are receiving this mail because:
You are watching all bug changes.


[plasmashell] [Bug 356225] Panel moves to wrong screen when external monitor is connected

2016-07-22 Thread Michael Butash via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=356225

--- Comment #158 from Michael Butash  ---
I've been noticing this too, testing between 5.5 and 5.6 of libqt and plasma
itself, it never seems to go where I tell it to.  The other multi-monitor
issues are compounding it, when they disappear, and kwin shuffles everything
around, the taskbar will do so as well.

Even more odd, do this enough, and it'll start spazzing, flickering between
both screens until I force some event.  Very buggy how and where this panel
lands.  

Glad at least it is noticed and confirmed, one more thing perpetually broken
with multi-monitor to watch.

-- 
You are receiving this mail because:
You are watching all bug changes.


[plasmashell] [Bug 356225] Panel moves to wrong screen when external monitor is connected

2016-07-22 Thread Michael Butash via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=356225

Michael Butash  changed:

   What|Removed |Added

 CC||mich...@butash.net

-- 
You are receiving this mail because:
You are watching all bug changes.


[plasmashell] [Bug 340267] Plasma crashes when a DisplayPort monitor sleeps

2016-07-09 Thread Michael Butash via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=340267

--- Comment #57 from Michael Butash  ---
Are there any repo's about with 5.6.x components for testing?  I found ubuntu's
landing-11 overlay with 5.6.0, but it seems more broken than 5.5 default with
kubuntu 16.04.

Otherwise, is there a recommended method of rebuilding the packages to test
someone can point me at?  Has there been any progress from the other reports
that have identified the problem yet?

I'm at the point I just leave the monitors on most nights, but they create a
lot of heat and power usage that i'd love to just flip them off without having
to reboot daily as a result to stabilize things.

-- 
You are receiving this mail because:
You are watching all bug changes.


[plasmashell] [Bug 340267] Plasma crashes when a DisplayPort monitor sleeps

2016-06-19 Thread Michael Butash via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=340267

--- Comment #54 from Michael Butash  ---
Interestingly enough I installed kde-backports and dist-upgraded to pull down
plasma 5.6.5, but that kept qt at 5.5.1.  I gave it a stress test flipping my
3x displays on and off in various orders, and it's behaving a far sight better
than it had, and hasn't crashed.  

The only anomalies now so far currently is it still doesn't put the displays
back in the right places and offsets, which results in me having to move them
about to realign after the third on/off and it doesn't always move the kde
panel to the primary display, sometimes even flickering back and forth.

I'm going to see if I can find where to get libqt5 in 5.6.1 or higher too, but
this seems to indicate it isn't entirely a Qt problem.

-- 
You are receiving this mail because:
You are watching all bug changes.


[plasmashell] [Bug 340267] Plasma crashes when a DisplayPort monitor sleeps

2016-06-13 Thread Michael Butash via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=340267

Michael Butash  changed:

   What|Removed |Added

 CC||mich...@butash.net

--- Comment #51 from Michael Butash  ---
Nastiness, stuck with older qt in ubuntu 16.04, had to stop using kde since it
forced all sorts of oddities around qt-based anything with 3x 4k hdmi tv's that
would come and go when I'd power them off for the night (no dpms-ish features
for hdmi it seems).  Plasma guys blame qt, but they thrash and die in many ugly
ways as a result that seem unnatural despite inadequacies in qt like this.  

Really liked plasma otherwise, but had to go back to something that worked. 
I'm finding cinnamon doesn't suck with modern mesa/radeon drivers vs
proprietary fglrx+compositing hell.  We need this fix asap in older kde distros
for mobility and big-4k-tv love again.

-- 
You are receiving this mail because:
You are watching all bug changes.


[kwin] [Bug 341497] Segfault in Qt since the (at least) the xcb screen backend cannot deal with "no screen" conditions

2016-05-05 Thread Michael Butash via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=341497

Michael Butash  changed:

   What|Removed |Added

 CC||mich...@butash.net

--- Comment #59 from Michael Butash  ---
Is a backport possible for 16.04 ubuntu users not likely to see this in lts
until 18.04?

Sadly, kde4 was terrible with unfixed bugs for setting up xrandr geometry as
well that made it unusable when relying on radeon modules, upgraded to 5 (and
16.04 to do so), was massively better, but affected by this now as well it
seems.  Going back to 4 really isn't an option being left unresolved too.

I'm using 3x displays, 48" 4k samsung tv's as my desk monitors, which don't do
dpms keepalive over hdmi cables it seems.  Rather they shut off/down, and "go
away" on the wire to the video card and xrandr, leaving it without a native
display, or your "dummy display" concept it seem to keep it sane when it has
none.  Waking up the displays, and thus xrand + kde figuring out where to put
things back to, is an entire crapshoot now whether it 1) lives perfect, 2)
lives broken needing xrandr fixing, 3) needs sddm restart from different tty,
or 4) needs rebooted as nothing wakes it up.  Feels windoze-y now.

Oddly, it doesn't always crash kwin, and sometimes recovers perfectly.  Other
times not so much, but its very random sadly.  

I've created xrandr scripts myself and with arandr to deal with it when kde5 as
a whole decides to go weird, but it's also seeming to have identity issues with
what is the "primary" display as well, as it seems to change upon these events
which is really primary, or which primary is really linked to which monitor
index.  Sometimes I just have to try setting the primary monitor randomly to
figure out which it thinks is currently actually display 2 for example.

SDDM also has recovery issues with are likely to be related but their own
beast, yet systemic of the fact no one seems to actually test kde with multiple
monitors extensively.  I was using kde4 happily with amd blob drivers and 6x
1080p montiors that did the setup itself for years, but using radeon now (with
4.x kernels that amd doesn't support yet for blob), which now works 2000x
better, breaks this with xrandr quirks like this.

-- 
You are receiving this mail because:
You are watching all bug changes.


[Akonadi] [Bug 362715] New: Imap constant refresh of IMAP directory

2016-05-05 Thread Michael Butash via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=362715

Bug ID: 362715
   Summary: Imap constant refresh of IMAP directory
   Product: Akonadi
   Version: 15.12
  Platform: Ubuntu Packages
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: IMAP resource
  Assignee: chrig...@fastmail.fm
  Reporter: mich...@butash.net
CC: kdepim-b...@kde.org, vkra...@kde.org

I'd upgraded from 14.04 ubuntu to 16.04, and with it kde5.  I've been
attempting to migrate from thunderbird to kmail, but tying in my primary
account, began noticing it having problems with constantly synching,
particularly one directory.  I get a count mismatch every time, and it just
starts over, which happens to be some 26k messages from some perpetual customer
spam in the past year.

Starting and stopping akonadi from cli, I see it hitting the same directory
constantly that the local count mismatch doesn't match, tries again, over and
over:

log_imapresource: Detected inconsistency in local cache, we're missing some
messages. Server:  26320  Local:  25004
log_imapresource: Refetching complete mailbox.

It begins its fetch, gets to the end:

...
Received:  11 In total:  24989  Wanted:  25098
Received:  11 In total:  25000  Wanted:  25098
Wrote 4357 bytes to 
"/home/$dir/.local/share/akonadi/file_db_data/26/1088326_r813"
finished
localListDone:  false  deliveryDone:  true
localListDone:  true  deliveryDone:  true
Nothing to do
Received:  0 Removed:  0 In total:  0  Wanted:  -1
finished
...
Received:  0 Removed:  0 In total:  0  Wanted:  -1
finished
log_imapresource: Detected inconsistency in local cache, we're missing some
messages. Server:  25098  Local:  25004
log_imapresource: Refetching complete mailbox.
25098
Received:  4 In total:  4  Wanted:  25098

... and starts over, again and again, collecting tons of email headers in a
steady 15mbps suck.

Watching my bandwidth, it generates a good 14mbps or so of traffic, and this
has been going on for a week or so, so amazed someone hasn't shut me down yet.

Thunderbird handles this directory just fine, not sure why kmail has this
issue, or obscurely related to some other component I'm not finding.

I'd even moved the items at a webmail level into another directory, and the
problem persisted. I suspect the imap server (godaddy, go figure) really is
doing something bad like not indexing them properly, or missing indices
perhaps, but akonadi:imap is misbehaving epically like a thrashing child
hogging a good clip of bandwidth someone is paying for (yay for unlimited
bandwidth on cable still here).

I'm going to largely purge that directory, but wanted to see if I could offer
anything to help fix this before doing so, but mostly it seems behavioral with
akonadi imap collector not knowing when to stop after x failed attempts at the
same intensive collection routine.

This also seems to cause email not to be actually commited, as I seem to not
always get all mail, and not always send all mail.  It's very spotty, but I'll
notice usually mail will stop and start collecting at odd intervals, presumably
as a result of this folder constantly refreshing as a priority.

Reproducible: Always

Steps to Reproduce:
1. Create an imap account with bad indices in its imap folder email counts
(pulls 25k emails, server reports 26k).
2. Start Akonadi from command line with akonadictl, watching the imap
collection on the errant folder as it pulls headers, finds mismatch, tries
again.
3. Watch Akonadi incessantly try to get the proper count in futility, using all
of your bandwidth constantly.

Actual Results:  
Akonadi never completes polling the folder, just trying over and over, using a
very large amount of bandwidth constantly and perpetually until akonadi is
force shutdown.

Expected Results:  
* Recover from a bad index automatically (if possible)
* Offer to correct bad index on server (if possible)
* Exit and give error condition of unstable directory structure, server problem
* Simply ignore the index being bad, grab what it can grab, and poll emails
normally around the bad index (seems to be thunderbird behaviour)

I've left this to be somewhat broken, but the fact that kde5 is a bit unstable
with multi-monitor support still means I restart often, which respawns akonadi
until I notice bandwidth usage being excessive and kill it again.  I can
provide better debug, but again, seems more just methodical fixes needed to be
agreed upon.

-- 
You are receiving this mail because:
You are watching all bug changes.