Christopher, your test packages do indeed fix this, excellent! As I mentioned in the report, this was 100% reproducible with the packages from -proposed, and now with the packages from your PPA I could no longer reproduce it at all, during the multiple test logins I did.

Definitely not a showstopper for me Christopher, just a minor annoyance, so it’s a go-ahead from me. Thanks for asking!

Yep, that’s exactly the issue as it occurs here too. Thanks for looking into this Christopher! If you do get this narrowed down and need testing for potentially fixed builds, I’ll be happy to try them out.

Hi Christopher, sure. For the test user, I just go to the top right cog menu, select ”Startup Applications…” and ”Add” Firefox (/usr/bin/firefox). Firefox remembers the window size, so I start it once (manually), maximize the window and then close it. On the next login, it should start maximized.

Verifying that for both test cases the issue is no longer reproducible with the proposed packages. In other words, results with packages from -proposed are as described in ”Expected:” for each test case. (For both cases the issue was reproducible here with 1:0.9.7.0~bzr19-0ubuntu10.)

jani@saegusa:~$ LC_ALL=C apt-cache policy compiz-plugins-main compiz-plugins-main-default
compiz-plugins-main:
Installed: 1:0.9.7.0~bzr19-0ubuntu10.1
Candidate: 1:0.9.7.0~bzr19-0ubuntu10.1
Version table:
*** 1:0.9.7.0~bzr19-0ubuntu10.1 0
500 http://archive.ubuntu.com/ubuntu/ precise-proposed/main amd64 Packages
100 /var/lib/dpkg/status
1:0.9.7.0~bzr19-0ubuntu10 0
500 http://archive.ubuntu.com/ubuntu/ precise/main amd64 Packages
compiz-plugins-main-default:
Installed: 1:0.9.7.0~bzr19-0ubuntu10.1
Candidate: 1:0.9.7.0~bzr19-0ubuntu10.1
Version table:
*** 1:0.9.7.0~bzr19-0ubuntu10.1 0
500 http://archive.ubuntu.com/ubuntu/ precise-proposed/main amd64 Packages
100 /var/lib/dpkg/status
1:0.9.7.0~bzr19-0ubuntu10 0
500 http://archive.ubuntu.com/ubuntu/ precise/main amd64 Packages

I tested 5.20 from Shuduo’s PPA and for me it reproduces the issue just the same as -proposed. To be sure, I then went back down to release versions in all the other packages (so that the only change wrt. released is again just Unity being 5.20, just now from the PPA), and the issue remained. Downgrade Unity to 5.18 and it again goes away.

But this looks like a speed issue, so Unity may not be directly at fault: any apps started once the desktop is fully loaded open as truly maximized, so a workaround is setting autostarted apps to start after a delay. Perhaps Unity going from 5.18 to 5.20 here causes just enough delay for those apps to start before whatever the component is that should fuse the menus with appindicator. The autostarting facility should wait for that component, or the component should be also able to fuse menus for existing windows once it gets up and running.

Incidentally, any appindicator-related packages’ versions also don’t seem to matter for this once Unity is 5.20. I think I’ll try upgrading just those to their -proposed versions next (so that Unity remains at 5.18) just to cover all angles.

With Unity 5.20.0-0ubuntu1 from -proposed, maximized windows opened during login by autostarting apps have their top bar visible underneath the desktop top bar (indicator-appmenu) as if unmaximized, but with the window ’maximize’ button indicating a maximized window – i.e. first click on it results in the window getting smaller. The second click on it then actually maximizes the window so that the top bar merges into the desktop top bar (indicator-appmenu).

This problem appears consistently on every login, after I’ve enabled -proposed and installed Unity 5.20 from there. It never appears when I have 5.18 from -updates. Annoyingly, I am unable to reproduce it in a VM (for a nice demonstration video), but I am able to reproduce it with a newly created user account on the host (i.e. without the configuration from my main user account).

I could’ve taken a screenshot of how it looks right after login. I’ll do that in a minute.

Edit: autostarting apps.

Hi Daniel. As I commented above, this is still reproducible in Saucy (I’m attaching a screenshot). Does this mean it’s a bug in avconv and not in libvpx, or did I misunderstand you?

Just reproduced this in Raring and Saucy. The latter currently has libvpx 1.2.0-2 which supposedly contains the fix I linked to above, so I’m not so sure about it anymore.

With some input video (such as LQ MP4 from [1]), the second pass fails when a preset enabling automatic placement of alternate reference frames with ”auto-alt-ref=1” (such as all of those provided by libav-tools) is used. (Example of non-problematic input is MP4 from [2].) This is apparently an upstream issue, already fixed in v1.1.0-184-g429743c [3].

Steps to reproduce:
1. wget ’http://archive.org/download/Mario2_919/Mario2_919_LQ.avi’
2. avconv -y -i Mario2_919_LQ.avi -c:v libvpx -pre libvpx-360p -pass 1 -an -sn -t 1 out.webm
3. avconv -y -i Mario2_919_LQ.avi -c:v libvpx -pre libvpx-360p -pass 2 -an -sn -t 1 out.webm

What happens:
The second pass ends with:
[webm @ 0x7ab6c0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 100 >= 100
av_interleaved_write_frame(): Invalid argument

What I expect to happen:
The second pass to finish successfully.

Workaround:
Copy preset file to ˝/.avconv/, comment out (#) auto-alt-ref=1.

*[1] http://archive.org/details/Mario2_919
*[2] http://archive.org/details/014674
*[3] http://code.google.com/p/webm/issues/detail?id=468#issueheader