Hmm looks like the app/commands are not registered properly.
Did you successfully activate the app in the web interface? Also I would recommend to use the app store to install the app, which can be found in the āMultimediaā category.
Hmm looks like the app/commands are not registered properly.
Did you successfully activate the app in the web interface? Also I would recommend to use the app store to install the app, which can be found in the āMultimediaā category.
Ahh, that was my mistake. I didnĀ“t aktivate it in the app-store.
Thanks for you tip.
Well, well, well, after let it run all the night, i got now a folder /data/appdata_xxxxxxxx/preview/ (3,2 Gb) with 60224 files under 4280 directoriesā¦
BUT, when i (or one of my user) launch the Gallery app. thumbnails are still again generated in the /data/user/thumbnails/ directory for each userā¦
I really donāt understand the purpose of this preview generator if the behaviour is not changed. Gallery app should read directly the new /data/appdata_xxxxxxxx/preview/ directory and not generate again & again thumbnails in a specific directory for each userā¦
Must we symlink all these folders ? Things are really not clearā¦
Itās about the previews that you see, when you just browse your files with the standard nc files app. The gallery app uses way bigger thumbnails ;).
But I would also love to see this features combined. Maybe use the preview generator to also create bigger thumbs that can be used by the gallery app and also for the large preview the files app gives on the right bar, when you see ādetailsā of an image file.
So it seems I also need to update the Gallery App. Iāll look into that soonish. Basically the GalleryApp kind of did its own preview handling. But there is no reason why we canāt change this to use the new stuff.
Fixed that for you
Ok so I fixed the gallery app see pr. But Iām afraid youāll have to wait till NC12 before you can use it.
Thank you very much. I canāt wait either and will edit the files manually .
ā¬: Ahahahah this is sooo nice. Suddenly the previews jump up as popcorn. This is sooo a huge benefit for slow systems (e.g. my little Pi2), unbelievable !! Thank you very much for this and the preview generator @rullzer
Did I understand right that /data/user/thumbnails/
can be deleted now?
How did you update your server? I figured if I tried to pull in the files itād flag up as failing the mdhash
I manually changed the lines of the files according to the pull request: https://github.com/nextcloud/gallery/pull/187/files
Deleted the red lines and added the green ones ;).
I didnāt found a possibility to download the files with the pull request already merged, so leafpad or nano has to do the job .
The files in /tests/
do not exist in the end user app, I was confused first little bit.
No warnings in admin? Feels like if I breathe at the server too hard itāll fail an integrity check sometimes
Ah yes of course you will get integrity check errors to ignore. Might be little annoying cause there will be some message about it at the top all the time. But everything will still working, nothing to fear there.
wget https://github.com/nextcloud/gallery/archive/master.zip
with pull request about iPreviews merged
By the way: integrity check is removed now!?
nothing more to do than loading the app, renameing and enableing?
or run pre-gen.
could you please give a quick summary like:
I did:
@hourly php -f /var/www/nextcloud/occ preview:pre-generate > /home/NextcloudUser/preview.log
does it fit?
thx in advance, carsten
Hi there,
1st of all, thanks for your work.
Iām using the occ preview generator command.
Iāve also āupdagreā the gallery app directly from github, so Iām actually using the new shared preview infrasctructure (folder owncloud/data/appdata_<identificator>/preview
).
BUT Iām seeing that when I get a big preview of a photo the gallery app STILL generate a new file.
I think the problem that te āocc preview:(generate-all|pre-generate)ā command is generating the thumbnails with the following names:
/home/owncloud/data/appdata_<appid>/preview/5382
[root@ciberterminal 5382]# ll
total 812
-rw-r--r-- 1 apache apache 136172 Jan 4 21:05 1024-1365.png
-rw-r--r-- 1 apache apache 3630 Jan 4 21:05 128-171.png
-rw-r--r-- 1 apache apache 241146 Jan 4 21:05 1440-1920-max.png
-rw-r--r-- 1 apache apache 241152 Jan 13 10:02 1440-1920.png <= this is a new one generated by gallery.app
-rw-r--r-- 1 apache apache 6639 Jan 4 21:05 192-256.png
-rw-r--r-- 1 apache apache 879 Jan 4 21:05 24-32.png
-rw-r--r-- 1 apache apache 11225 Jan 4 21:05 256-341.png
-rw-r--r-- 1 apache apache 906 Jan 4 21:05 32-32-crop.png
-rw-r--r-- 1 apache apache 1002 Jan 4 21:05 32-43.png
-rw-r--r-- 1 apache apache 24524 Jan 4 21:05 384-512.png
-rw-r--r-- 1 apache apache 1272 Jan 4 21:05 48-64.png
-rw-r--r-- 1 apache apache 42710 Jan 4 21:05 512-683.png
-rw-r--r-- 1 apache apache 1391 Jan 4 21:05 64-64-crop.png
-rw-r--r-- 1 apache apache 1620 Jan 4 21:05 64-85.png
-rw-r--r-- 1 apache apache 85482 Jan 4 21:05 768-1024.png
-rw-r--r-- 1 apache apache 2504 Jan 4 21:05 96-128.png
So is gallery.app is not using ā1440-1920-max.pngā pre-generated file, it generates a new ā1440-1920.pngā which is the same as the pre-generated.
My config.php settings include:
'preview_max_x' => 1920,
'preview_max_y' => 1920,
Iāll try to make a trick (symlink) to see if it works and gallery doesnāt generate new thumbs.
Cheers
Iāve symlinkāed all the āmaxā files to the name gallery app uses and it works:
cd /owncloud/data/appdata_<instanceid>/preview
for i in $(find . -name "*-max.png") ; do [[ ! -f $(dirname $i)/$(basename ${i} -max.png).png ]] && ln -s $(dirname `readlink -e ${i}`)/$(basename $i) $(dirname `readlink -e $i`)/$(basename ${i} -max.png).png ; done
That would be a bad idea until the bugs are not fixed @rullzer!
That could freeze your box
The app does not log the filename in case of error, cannot generate a preview of mp3 without cover and stucks on certain PDF files.
Bug list (for the moment, iām still debugging)