0x2620/pandora
2
1
Fork 1
Code Issues 1.3k Pull requests Releases Wiki Activity
5669 commits 2 branches 0 tags 34 MiB
Commit graph

5669 commits

This branch
This branch
All branches
Author SHA1 Message Date
rlx
be7b594524 typo 2016-08-09 14:23:46 +02:00
rlx
82cb4de1cc update import dialog layout 2016-08-09 14:22:46 +02:00
rlx
6050e5c702 Merge branch 'master' of git.0x2620.org:/pandora 2016-08-09 14:19:46 +02:00
rlx
b708452c3a update config 2016-08-09 14:17:58 +02:00
rlx
864e52acf6 update import dialog layout 2016-08-09 14:16:58 +02:00
j
9991767d01 no summary in default importMetadata keys 2016-08-09 13:03:21 +01:00
j
7f8b5448e6 set default config importMetadata 2016-08-09 12:57:43 +01:00
j
0430a0f236 cache getMediaUrlInfo 2016-08-09 12:57:43 +01:00
rlx
90486ec774 update menu and config 2016-08-09 13:35:47 +02:00
rlx
8a04bb9625 fix import media dialog 2016-08-09 13:30:31 +02:00
rlx
6f979c1f9d fix import media dialog 2016-08-09 13:28:51 +02:00
rlx
92fb9e3792 fix import media dialog 2016-08-09 13:26:51 +02:00
rlx
adfaa863c3 typo 2016-08-09 13:21:00 +02:00
rlx
5ef6062613 import media dialog 2016-08-09 13:17:48 +02:00
j
926d3f0f09 add video id 2016-08-09 11:50:24 +01:00
j
337cafcf76 don't add base keys to Item.data 2016-08-08 15:54:52 +02:00
j
9a86ddce01 include upload_date 2016-08-05 17:57:40 +02:00
j
dce51305ce update poster after extracting stream 2016-08-05 15:24:54 +02:00
j
c4a95bc320 update_poster should always update poster 2016-08-05 14:46:27 +02:00
j
2aef460225 do not set -ac if audiochannels is None 2016-08-05 14:46:27 +02:00
j
ff8dd16456 fix profile selection 2016-08-03 11:41:46 +02:00
j
5447aab0a1 more current values 2016-07-30 12:04:35 +02:00
j
dcf3acbd44 store facets in NFKD 2016-07-30 12:01:34 +02:00
j
dffb25e0e8 poster might still point to old id, after rename, delete and make new one. fixes #2944 2016-07-30 10:02:53 +02:00
j
5c90ff79a0 cleanup poster cache 2016-07-30 09:39:31 +02:00
j
893f2e5423 add importMediaDialog 2016-07-30 02:49:43 +02:00
j
383ad8a535 fix findMedia by item id 2016-07-24 17:52:33 +02:00
j
000d2c560c do not pass proxy header in example config (httpoxy) 2016-07-19 15:43:04 +02:00
j
ffe4b03a76 encode pdf url 2016-07-08 14:21:01 +05:30
j
6f4a0ba90a support vtt subtitles 2016-07-01 21:13:13 +02:00
j
f8f951c966 remove outdated fixmes 2016-07-01 17:53:59 +02:00
j
d780045306 flake8 2016-07-01 17:48:43 +02:00
j
3166bf5beb show timeline errors 2016-07-01 17:34:45 +02:00
j
5434ffbf53 make_poster no longer takes arguments 2016-07-01 12:44:07 +02:00
j
88c800a093 use data['positions'] 2016-06-30 16:42:56 +02:00
j
c7157d5001 only decode ids for found positions 
merge document.view.get_positions into item.utils.get_positions
add flag to decode id before looking up in ids

Followup to 09ebbc9cc6
 2016-06-30 16:18:07 +02:00
j
3d95d7013a Merge remote-tracking branch 'wjt/2935-findDocuments-performance' 2016-06-30 15:43:09 +02:00
j
e9863c238e always use get_operator, avoid case-insensitive match if possible 2016-06-30 11:28:09 +02:00
j
5b545e6e43 layer first 2016-06-30 02:42:24 +02:00
j
b6e4d33a43 add Annotation.findvalue index (used by findClips) 2016-06-30 02:42:24 +02:00
j
b63024df02 show source info if encode fails 2016-06-30 00:23:56 +02:00
j
b5bc17f925 make layer itemKeys with filter=true show up in searching for * 2016-06-30 00:17:23 +02:00
Will Thompson
09ebbc9cc6
findDocuments: improve performance of positions queries 
References #2935
 2016-06-28 16:36:55 +01:00
Will Thompson
8d25e3be78
findDocuments: improve entity query performance 
When I implemented this in 9a4c24c, there were not many rows in
entity_documentproperties in the database here. Now that there are,
computing the document_document -> entity_documentproperties ->
entity_entity join and then filtering is really, really slow. Postgres
seems to materialize the whole join and then scan it.

If we get a set of matching document IDs for the entity query in a
subquery, and then just filter with IN on that, things are much faster:
scan entity_entity; in a nested loop, get the document_ids via
entity_documentproperties; hash this set; and then scan
document_document.

Searching for a single character, this brings the query from ~1.1s to
~400ms. Searching for a full word, ~800ms to 120ms

This condition is getting really ugly -- I am sorry!

References #2935
 2016-06-28 16:33:01 +01:00
Will Thompson
92a4e77f9b
chunkupload: typo: uplaod -> upload 2016-06-28 16:14:04 +01:00
j
5aeffcfb6a check first audio track 2016-06-27 16:51:18 +02:00
j
adfcc1cb27 never set display aspect ratio to 0:0 2016-06-27 16:08:30 +02:00
j
8ac78f3bd6 remove unused force flag from make_poster, update_timeline 2016-06-26 23:24:11 +02:00
j
0f9e80e1e6 avoid saving item twice 2016-06-26 23:22:27 +02:00
j
de9b062d63 make sure existing index is using gin 2016-06-26 16:55:58 +02:00