OpenH264 plugin fails to update itself

RESOLVED WORKSFORME

Status

()

RESOLVED WORKSFORME
4 years ago
4 years ago

People

(Reporter: drno, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
I have a user profile with my Aurora browser which shows on OpenH264 plugin details page that the last update was done on July 25th.
If I use a fresh profile it the same page shows September 30th. Both show as version 1.0.
Having Aurora sit for 24 hours did not update the time stamp on the old profile. Restarting Aurora did not update the time stamp. Changing the "Automatic Updates" setting from "Default" to "On" did not update the time stamp.

Byron has a profile with the same problem.

So it looks like the automatic update checks are not executed at all, or at least the UI is not updated if they occur.
I *think* the date is the date the plugin changed on the local system, not the date of last check, and not the date the plugin was built.  (bbondy/georg - am I correct?)

If I'm right, this is exactly as I'd expect.
Flags: needinfo?(netzen)
Has there not been an update since mid/late July? Because the version on my stock Nightly does not work, but with a fresh profile and a fresh install, it does work.
There was a directory name-format change at some point; that may have older profiles or left them stuck; I'm not sure.
The bugs for updating the plugin are here:
Latest done in Sept:
https://bugzilla.mozilla.org/show_bug.cgi?id=1061808
One before in July:
https://bugzilla.mozilla.org/show_bug.cgi?id=1043416

You can find the CDN links there and compare with what you have on disk.

Also this patch landed in August that changed the path to include a version subdirectory:
https://bugzilla.mozilla.org/show_bug.cgi?id=1045209
OK, so it used to work such that if I copied over the .so/.dylib with my own version and started the browser it would update with the correct one after a min or so.  Now that no longer is the case and I can run with an old version of the plugin indefinitely, even after an Aurora update.  I'm not sure yet what has changed.
I suspect this was tied to the rename and change in how versioning was handled; the version is stored in a pref.  (manual updates are not a normal/supported path).  If you change the version number in the pref (and force it to check for an update by mucking with LastUpdate), does it do something?
(In reply to Randell Jesup [:jesup] from comment #1)
> I *think* the date is the date the plugin changed on the local system, not
> the date of last check, and not the date the plugin was built. 
> (bbondy/georg - am I correct?)

The date shown in the AddonManager is from when the last update was installed (media.gmp-gmpopenh264.lastUpdate).

(In reply to Ethan Hugg [:ehugg] from comment #5)
> OK, so it used to work such that if I copied over the .so/.dylib with my own
> version and started the browser it would update with the correct one after a
> min or so.  Now that no longer is the case and I can run with an old version
> of the plugin indefinitely, even after an Aurora update.  I'm not sure yet
> what has changed.

That is expected - as suggested, resetting "media.gmp-manager.lastCheck" & "media.gmp-gmpopenh264.version" should fix it.
Flags: needinfo?(netzen)
(Reporter)

Comment 8

4 years ago
So how can a user determine which version of the plugin he is running then?

Because right now about:addons shows 1.0. The date on the plugin pages show when it got installed, ok. But then media.gmp-gmpopenh264.version shows me 1.0 all the time as well.

Did we basically kept all the version numbers as 1.0 during our development in 34, even though we updated the code/plugin?! (Which is IMHO really bad.) And we all promise now that we won't ever do this again and start using version numbers properly for future updated?
The version shown in about:addons is the version that was last installed, that is what a user should look at.
The info files in the GMP install directory confirm that version number.
The current code no longer has this issue
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.