Commit graph

5547 commits

Author SHA1 Message Date
j
542fe8a860 update symlinks too, follow up to ed21517 2016-06-13 10:30:22 +01:00
j
437c19f64c ignore share 2016-06-09 12:57:38 +02:00
j
cb6203ff82 use same folder structure in etc/systemd as used once installed 2016-06-09 12:50:51 +02:00
j
d7a9ca28cb also create /var/log/pandora 2016-06-09 12:48:42 +02:00
j
5e3b4b9c2b change port in gunicorn_config.py 2016-06-09 12:42:00 +02:00
j
ed215174f8 install systemd services in /etc/systemd/system, /lib/systemd could be mounted read only in the future 2016-06-09 12:38:13 +02:00
j
05c4cfcbc8 add space and other flake8 cleanups 2016-05-28 11:30:43 +02:00
j
5e149a5cb8 add space and other flake8 cleanups 2016-05-28 11:26:46 +02:00
j
225259e521 add space and other flake8 cleanups 2016-05-28 11:18:51 +02:00
j
f21e8413fb use get_random_string 2016-05-28 11:18:51 +02:00
j
7fdaf6d1ce include Access-Control-Allow-Origin in 404 not found response 2016-05-27 11:51:47 +02:00
j
d20620a716 name can contain &, decode html first. fixes #2917 2016-05-17 15:25:18 +00:00
05e6118a88
findAnnotations: include duration alongside result count
fixes #2921
2016-05-05 15:54:25 +01:00
j
41cc8e3573 expose encoding status via api 2016-05-05 10:49:34 +02:00
j
be163826ef Merge remote-tracking branch 'wjt/fix-migrations' 2016-05-05 10:48:24 +02:00
39b9b48be2
archive: fix migrations for upload_to function renamings
9c75526 renamed these functions. The function doesn't affect the DB
schema so it should be safe to just modify the migraiton.
2016-05-04 17:01:44 +01:00
e29ea230fb
Add migration for Document.documentproperties ref
This should have been included with a8dcbbb, which changed the
related_name to access DocumentProperties from Document. (There's no
actual change to the database.)
2016-05-04 16:55:11 +01:00
j
0f28a2b7d5 fix queue status 2016-04-30 14:15:13 +02:00
j
9c7552699f fix upload_to callbacks 2016-04-29 13:46:55 +02:00
2812834ce3
findAnnotations: don't lowercase ids (fixes #2916)
Without this fix, a condition like:

     {key: 'id', operator: '==', value: 'A/B'}

gets mapped to:

     public_id__exact=('A/B'.lower())

which is wrong.

I introduced this bug in b3df5b8. I didn't catch it because I was
mostly interested in the 'layer' key -- but layer names are
conventionally lowercase anyway so lowercasing them had no effect.
2016-04-29 11:03:45 +01:00
j
34747c0fd7 Merge remote-tracking branch 'wjt/get-layers-only-entity-name'
(fixes #2913)
2016-04-29 00:12:38 +02:00
aa40a40595
Annotation.json: only include entity id & name
Fetching documents for each entity in turn is expensive. (I have tried
using ArrayAgg to fetch them in the same query as the Entity — no
improvement. It's possible that being able to join to entity_entity,
and then use ArrayAgg, would be better.)

Even once you've fetched them all, if the same entity appears many
times in an item, then get(..., keys=['layers']) duplicates the whole
JSON for the entity many times: expensive to serialize, expensive to
send over the wire.

Pandora's own web interface only depends on the 'id' key of 'entity' in
each annotation, and refetches the rest of the entity to show the pop-up
dialog when you press E. So by just not bothering to fetch and send any
other keys, get(..., keys=['layers']) on an item with many entity
annotations is substantially faster.

(I experimented with splitting the full entities off to one side, so,
you'd have:

    {
        "layers": {
            somelayer: [...,
              {..., "entity": {"id": ABC}},
            ], ...
        },
        "entities": {
            ABC: {...},
            ...
        }
    }

This is quicker than the status quo, but obviously not as fast as not
fetching & sending the rest at all!)
2016-04-28 14:15:23 +01:00
aa0fbc9d4a
Entity.json: get document ids from join table
This is a bit quicker because it's just a lookup in a single table, not
a join.
2016-04-28 14:15:12 +01:00
j
c149c5c42e use xenial repository if installing on 16.04 2016-04-28 13:27:46 +02:00
400b6650a2
Annotation.json: document empty-subtitle special case 2016-04-19 13:52:52 +01:00
af0d87b569
Annotation.json: reduce repeated layer lookups
It's actually quite costly to look up keys in CONFIG, particularly
inside a loop: this trims ~5% off get(keys=['layers']) for
annotation-heavy items.
2016-04-19 13:52:47 +01:00
3f5be0bd27
findClips: look up entity names (fixes #2804) 2016-04-19 12:28:58 +01:00
d0129a4416
findClips: avoid O(n²) lookup of clip from annotation
This doesn't make much difference for small ranges, of course.
2016-04-19 11:25:12 +01:00
ba00bcbf7b
findClips: select_related('item') / ('item__sort')
Clip.public_id uses self.item.public_id.

Clip.json() uses self.item.sort, so we should select_related on that
rather than the clip's own sort field. (They are identical objects. Is
Clip.sort ever used directly?)

With this change, findClips() issues one query to fetch clips plus one
query per flavour of annotation; before, it issued two extra queries per
clip.
2016-04-19 11:25:06 +01:00
6dbb7f921a
findClips: only scan layers once 2016-04-19 11:14:25 +01:00
j
27830d7c58 use markdown in readme 2016-04-15 14:21:24 +02:00
b3df5b8d56 findAnnotations: match some fields case-sensitively
Requiring layer to have the right case is consistent with
addAnnotation(), and means the _layer[_like] index can be used. In my
testing, if itemsQuery specifies a single item, then postgres doesn't
bother with the layer index anyway; but if not, it makes a pretty big
(~3×) difference.

Matching public_id and item__public_id case-sensitively also seems
reasonable (it's consistent with get() and getAnnotation()).

(Is lower() redundant for the case-insensitive comparisons? ie. is
UPPER(x.lower()) == UPPER(x)? I'm not sure, it's cheap, let's leave it.)
2016-04-05 12:19:32 +01:00
8d1b4de337 findAnnotations(): make 'findvalue' the default key
Annotations have no 'name' field, so

     findAnnotations({query: {conditions: [{value: 'foo'}]}})

would previously raise an exception.
2016-04-05 12:19:31 +01:00
284caf03c3 get_by_key: short-circuit
This is about 30% faster, presumably because it avoids allocation and/or
closing over variables is slow(?). It's not hugely significant (I
misread a line_profile report) but why not.
2016-04-05 12:19:31 +01:00
j
7ac68697d4 update pdf.js 2016-04-04 15:50:07 +02:00
j
e1967e96bc fix pdf zoom 2016-04-04 15:50:07 +02:00
j
652df88342 return 404 2016-04-04 15:50:07 +02:00
j
1bff4aa0e9 avoid storing invalid poster frames, only show videos with video 2016-04-01 16:40:20 +02:00
j
b8beb51480 fix multipart audio only timelines 2016-03-31 14:54:38 +02:00
j
30ce422452 disable apt translations 2016-03-26 22:56:09 +01:00
j
94b940436f fix timelines for items with many parts
- use durations from streams not from timelines
 - don't accumulate timeline drift
2016-03-19 18:58:48 +01:00
j
f0b8b2b81e check that range is [int, int] 2016-03-17 16:06:08 +01:00
j
e536dcb3b0 <= 2016-03-17 10:47:08 +01:00
j
7761cf9ec2 update celery package and promt to install new init files for workers 2016-03-17 10:38:15 +01:00
7554b0c105 init: restart celery workers on 'reload' (fixes #2904)
Sending HUP to the parent of a family of celery workers causes the
parent to re-exec itself, spawning a new set of child workers without
terminating the old ones.

So instead we send TERM to the parent on 'reload', which cleans up the
children, and rely on systemd/upstart to respawn the whole family.
2016-03-17 10:32:58 +01:00
j
e16310062b fix vm build on Ubuntu 16.04 2016-03-15 23:04:53 +01:00
eeaeda3970 Support WebVTT subtitle export 2016-03-11 14:16:23 +01:00
j
36463a8120 fix typo in README 2016-03-11 10:33:48 +01:00
j
697e501a4f only update item timeline once all parts are done 2016-03-11 10:33:48 +01:00
j
f6cebcaec9 fix user/group api 2016-03-08 20:14:05 +05:30