Setting was previously preload="auto". While preload="auto" *does not* cause a
full upfront download on Firefox, Abrowser, IceCat or Chromium, a user reported
on the LibrePlanet mailing list that it was causing a full download on their
browser. The specifications leave it up to the browser do decide whether to
download, but it makes sense to do what we can to avoid surprising people on low
bandwidth/quota internet connections.
https://html.spec.whatwg.org/multipage/media.html#attr-media-preload
Further, media.libreplanet.org (one of MediaGoblin's biggest users) has
implement this change locally, so it makes sense for us to stay in sync.
Signed-off-by: Ben Sturmfels <ben@sturm.com.au>
This fixes a warning I have with packaging where this file would get
installed in the wrong place (/usr/mediagoblin/env.py).
Signed-off-by: Ben Sturmfels <ben@sturm.com.au>
MediaGoblin ignores this argument and creates a virtualenv with
--system-site-packages regardless. Appears it's been this way since the early
days.
Removing this make the installation instructions easier to read.
Prior to this change, the Celery logging did not include any of the logging
calls within MediaGoblin because `disable_existing_loggers` defaulted to True.
This was unhelpful and inconsistent with the logging behaviour of the web process.
The MediaGoblin web process sets logging output based on the configuration in
paste.ini. This is loaded by the `paster` program, rather than MediaGoblin
itself.
The MediaGoblin celery process manually loads its logging config from paste.ini,
but previously defaulted to `disable_existing_loggers=True`, meaning that none
of the application logging flowed through unless the logger was explicitly added
to paste.ini.
Following the video transcoding work included in v0.10.0, uploading an image and
restarting Celery resulted in the image being marked as failed, even after it
had been initially successfully processed.
The issue was that the initial processing task was not being acknowledged by the task queue following the introduction of the
`CELERY_ACKS_LATE` setting. It's not clear why this is the case, but reverting
the setting fixes this issue and doesn't negatively impact video processing.
Issue is that Werkzeug > 1.0.0 has removed werkzeug.contrib.atom.AtomFeed,
making it difficult to use a distribution-packaged version of werkzeug. To solve
this, I've replaced use of werkzeug.contrib.atom.AtomFeed with
feedgenerator.Atom1Feed.
After the change, the only major difference between the feeds before and after is
that they use <summary> instead of <content>. Minor differences include no longer
adding 'type="text/html"' on some <link> elements and no "xml:base" attribute on
<entry> elements. I don't think these differences will have any noticable
effect.
Tested on Liferea feed reader.
