Synology-Forum.nl
Tweaks / Addons A.K.A. The Underground => Photo Station mods => Topic gestart door: Matr1x op 26 oktober 2023, 16:13:54
-
Wie kan mij helpen om dit werkend te krijgen?
https://github.com/Gulivertx/synology-photos-auto-sort/blob/master/README.md
A script to rename, move and sort images and videos files from a source folder to a target folder.
Volgens mij doet het precies wat ik nodig heb. Ik gebruik nu DS Files die automatisch een backup maakt van foto's en video's op mijn telefoon. Ideaal, maar ze staan allemaal ongesorteerd in de backup map. Niet zo handig.
Ik ben er een beetje uit en weet niet meer hoe ik dit vroeger allemaal deed. Moest ik nog met een telnet sessie met de Diskstation verbinden om Linux commando's uit te voeren? Deed ik dat ooit met WinSCP? Of kan ik tegenwoordig alles vanaf de Diskstation zelf doen? Wie zwengelt mij weer even aan? :o
-
Of kan ik tegenwoordig alles vanaf de Diskstation zelf doen?
Het script aanpassen op je PC (mappen en zo).
Sleep het script naar File Station in een (Gedeelde) map (misschien nog te maken ?)
Maak een Taak in de Taakplanner met de commando's, run als root.
Dan zou het kunnen inplannen of zelf eens opstarten vanuit de Taakplanner.
-
Ik wilde zelf ff testen...gewoon leuk....maar....http://www.cphub.net toegevoegd in het Package Center maar exiftool wordt niet gezien.
Ook hier is exiftool niet te downloaden (https://www.cphub.net/?id=40&pid=948).
-
Volgens mij moet je exiftool ook handmatig installeren: https://community.synology.com/enu/forum/68/post/144720
De taakplanner gebruiken voor installatie is misschien wel een goed idee :-)
-
Dit (https://qrys.ch/using-the-exiftool-on-a-synology-nas/) werkt ook niet.
Maar, hier (https://fossies.org/linux/misc/Image-ExifTool-12.68.tar.gz/) wel te downloaden.
Heb nu ff geen tijd meer maar, als je wilt wil ik wel morgen verder gaan en kijken of ik het aan de praat krijg....
-
Het heeft geen haast @Birdy maar je hulp wordt wel enorm gewaardeerd :thumbup:
-
Ik ga binnkort dit maar eens proberen:
https://www.synology-forum.de/threads/automatisches-umbenennen-img_jjjjmmtt_hhmmss-der-bild-dateien-beim-upload-vom-pc-sd-karte.127265/#post-1083106
-
Gelukt :) :clap:
Exiftool geinstalleerd volgens instructies hier (https://www.synology-forum.de/threads/automatisches-umbenennen-img_jjjjmmtt_hhmmss-der-bild-dateien-beim-upload-vom-pc-sd-karte.127265/#post-1083106)
Alleen niet dat script daar gebruikt, want die doet alleen jpg. Dus dit script (https://github.com/Gulivertx/synology-photos-auto-sort/blob/master/synology-photos-auto-sort.sh) gebruikt en dat werkt perfect.
Taak toegevoegd in de Task Scheduler en gaan met die banaan!
Bedankt @Birdy voor je hulp!
-
Het script werkt niet als bestanden spaties in de naam hebben. Met dit commando vervang je de spaties door een underscore (_):
for file in *; do mv "$file" $(echo $file | tr ' ' '_') ; done
En het script vergelijkt ook alleen bestanden met dezelfde extensies. Dus als je zowel .jpg als jpeg hebt, kun je hiermee de bestanden dezelde extensie geven (verander .jpeg in .jpg):
find . -depth -name "*.jpeg" -exec sh -c 'f="{}"; mv -- "$f" "${f%.jpeg}.jpg"' \;
-
Ik heb toch weer advies / hulp nodig, want ik heb dit schell script draaien via de Task Scheduler en soms eindigt deze met een error:
/volume1/tmp/synology-photos-auto-sort.sh: fork: Cannot allocate memory
Resource monitor geeft nauwelijks actieve processen. CPU en memory minimaal in gebruik. Geen idee dus wat het is. Maar het grootste probleem is dat als ik de taak weer opnieuw start ik de volgende melding krijg:
Error: an other process of the script is still running
Ik kan het proces niet vinden helaas, anders kon ik deze wel stoppen. Het enige wat ik kan doen is een Restart. Heeft iemand een betere oplossing om het proces te beindigen als er een error is? Ik heb bash -e script.sh al geprobeerd, maar dat hielp niet.
-
fork: Cannot allocate memory
Er is kennelijk niet genoeg memory en ook geen swap space, anders zou het systeem gaan swappen.
Resource monitor geeft nauwelijks actieve processen.
De Resource monitor laat niet alles zien maar, top of htop in CLI wel.
Misschien is het synology-photos-auto-sort script wel een beetje bagger ;)
-
Script draait alweer. Het gaat fout als er corrupte bestanden (0 bytes) in de source map staan.
Commando's top en htop zijn wel handig maar interactief. Geeft mij geen mogelijkheid om het script te vinden in ieder geval.
-
Misschien is het synology-photos-auto-sort script wel een beetje bagger ;)
Ach het kan vast beter, maar ik ben er heel blij mee. Vooral de optie dat hij dubbele foto's herkent en apart zet. Ik moet nu alleen nog iets verzinnen om foto bestanden te hernoemen als de EXIF informatie ontbreekt. Dan moet moet het gewoon de aanmaak datum gebruiken.
Als ik zo eens kijk op https://exiftool.org/exiftool_pod.html
kan ik misschien het script wel aanpassen en EXIF:CreateDate gebruiken.
-
Ik ga nog even door met mijn monoloog :)
Het script heeft dus moeite met grote videobestanden die dubbel (duplicate) zijn. Wel logisch want deze worden bijna bit voor bit vergeleken en dat heeft behoorlijk wat intern/swap geheugen nodig.
-
Je kunt ook eerst de dubbele laten opzoeken en dan verwijderen:
[attach=1]
-
Je kunt ook eerst de dubbele laten opzoeken en dan verwijderen:
Maar die kijkt vast alleen naar bestandsnamen... Waar vind ik dat rapport eigenlijk?
-
Staat in de printscreen: Opslag-analyser
Maar die kijkt vast alleen naar bestandsname
Ja, dubbele opzoeken.
-
Dit krijg je dus bij grote dubbele (duplicate) videobestanden, of als er teveel bestanden in de bronmap (source) staan:
/volume1/tmp/synology-photos-auto-sort.sh: fork: Cannot allocate memory
En dit kun je oplossen, door het PID bestand te verwijderen. Dat blijft namelijk achter indien het script abnormaal beëindigd wordt:
Error: an other process of the script is still running
-
Maar die kijkt vast alleen naar bestandsnamen...
Bij mijn weten niet. Volgens mij kijkt hij naar de MD5 hash. Als die gelijk zijn, zijn de bestanden vrij zeker identiek, ook al is de naam verschillend.
Edit:
Je laatste script vergelijkt twee files door beide files via base64 te encoden tot een tekstfile en dan beide tekstfiles te vergelijken. Dat zijn bij plaatjes dan twee heel grote files die je steeds vergelijkt, wand de base64 file zal groter worden dan de oorspronkelijke foto. Klinkt heel inefficiënt. In snap niet waarom hij niet twee MD5 hashes berekend en die vergelijkt.
-
Maar die kijkt vast alleen naar bestandsnamen...
Bij mijn weten niet. Volgens mij kijkt hij naar de MD5 hash. Als die gelijk zijn, zijn de bestanden vrij zeker identiek, ook al is de naam verschillend.
Alleen zoeken op bestandsnamen kan.
Maar zoeken op MD5 hash ook alleen, die optie is heel erg verborgen EN je moet de zoektocht 2x uitvoeren:
[attachimg=1]
[attachimg=2]
[attachimg=3]
[attachimg=4]
[attachimg=5]
[attachimg=6]
[attachimg=7]
-
Alleen zoeken op bestandsnamen kan.
Het is al weer heel wat jaren geleden dat ik daar naar gekeken heb. In elk geval is het onlogisch om duplicaten op grond van bestandsnaam te vinden. b.v. omdat er heel veel folders kunnen zijn waar het bestand "foto1" in staat, om maar een voorbeeld te noemen.
Maar wel leuk dat die optie er is. Dan kun je daarna nog handmatig uitvogelen of ze gelijk zijn. ;)
Edit: Ik zag dat ik ook ingesteld heb om bestandsnamen te negeren. De dubbele files hebben ook lang niet altijd dezelfde naam. En soms staat de file dubbel bij twee verschillende gebruikers. Dan kun je natuurlijk ook niet de file bij één gebruiker wissen. ;)
-
Het script dat ik gebruik loopt vaak vast bij grote bestanden als ze vergeleken worden of ze dubbel zijn. Dat gaat dus via base64 en wel als volgt:
# Test if existing file is the same
# Get base64 encoded image
SOURCE_FILE_BASE64="$(cat ${FILE} | base64)"
TARGET_FILE_BASE64="$(cat ${TARGET_FILEPATH} | base64)"
#See if files are the same
if [[ ${SOURCE_FILE_BASE64} == ${TARGET_FILE_BASE64} ]]; then
Kan ik dit aanpassen naar MD5? Want dat gaat vast veel sneller...
# Test if existing file is the same
# Get base64 encoded image
SOURCE_FILE_MD5="$(cat ${FILE} | md5)"
TARGET_FILE_MD5="$(cat ${TARGET_FILEPATH} | md5)"
#See if files are the same
if [[ ${SOURCE_FILE_MD5} == ${TARGET_FILE_MD5} ]]; then
-
Ik heb het even getest en die MD5 syntax is correct. Dat zou dus moeten werken.
FILE="/Users/briolet/Desktop/cushion.numbers"
SOURCE_FILE_MD5="$(cat ${FILE} | md5)"
echo ${SOURCE_FILE_MD5}
f57978d797dfc2e2f1a3373fd168b477
De hash is zo lang dat het nagenoeg uitgesloten is dat twee verschillende files dezelfde MD5 hash opleveren. Alleen als je paranoia bent kun je bij twee gelijke hashes nog een extra check via de base64 test toen.
Alleen stoort me de constructie: ""$(cat ${FILE} | md5)"". Dat moet efficiënter kunnen
-
Ik krijg er in het script ook een foutmelding op:
/volume1/tmp/synology-photos-auto-sort-md5.sh: line 223: md5: command not found
/volume1/tmp/synology-photos-auto-sort-md5.sh: line 224: md5: command not found
en dit staat er op 223 en 224:
223: SOURCE_FILE_MD5="$(cat ${FILE} | md5)"
224: TARGET_FILE_MD5="$(cat ${TARGET_FILEPATH} | md5)"
-
md5 command bestaat niet.
-
Oeps. Ik had het alleen op mijn mac getest. Ik had eigenlijk verwacht dat dit ook in linux zat. Zeker omdat MD5 ook binnen dsm gebruikt wordt.
Edit:
Ik zie wel in /bin:
/bin/md5sum --help
Usage: /bin/md5sum [OPTION]... [FILE]...
Print or check MD5 (128-bit) checksums.
With no FILE, or when FILE is -, read standard input.
-b, --binary read in binary mode
-c, --check read MD5 sums from the FILEs and check them
--tag create a BSD-style checksum
-t, --text read in text mode (default)
The following four options are useful only when verifying checksums:
--quiet don't print OK for each successfully verified file
--status don't output anything, status code shows success
--strict exit non-zero for improperly formatted checksum lines
-w, --warn warn about improperly formatted checksum lines
--help display this help and exit
--version output version information and exit
The sums are computed as described in RFC 1321. When checking, the input
should be a former output of this program. The default mode is to print a
line with checksum, a space, a character indicating input mode ('*' for binary,
' ' for text or where binary is insignificant), and name for each FILE.
GNU coreutils online help: <http://www.gnu.org/software/coreutils/>
Full documentation at: <http://www.gnu.org/software/coreutils/md5sum>
or available locally via: info '(coreutils) md5sum invocation'
-
Dit commando zet alleen de filename er ook bij. En dat kan ik dus niet vergelijken.
FILE="IMG_5850.JPEG"
SOURCE_FILE_MD5="$(/bin/md5sum ${FILE})
echo ${SOURCE_FILE_MD5
06e08afff504ff5b7105c66d0279872e IMG_5850.JPEG
Hoe kan ik de filename weglaten? een substring misschien?
Dit werkt bijvoorbeeld, maar kan vast makkelijker. Is is een MD5 hash altijd 32 lang?
FILE="IMG_5850.JPEG"
SOURCE_FILE_MD5="$(/bin/md5sum ${FILE})
SOURCE_FILE_MD5=$(echo "${SOURCE_FILE_MD5:0:32}")
echo ${SOURCE_FILE_MD5
06e08afff504ff5b7105c66d0279872e
-
Is is een MD5 hash altijd 32 lang?
Yep
-
Het aangepaste script met MD5 controle werkt en is een stuk sneller dan een base64 controle. Script loopt ook niet meer stuk nu op grote (video) bestanden.
Volgende uitdaging is het uitzoeken van foto's. Ze zijn nu netjes gesorteerd op datum/tijd, maar een groot deel kan weg. Voordeel van digitale foto's is dat je er vaak meerdere tegelijk maakt en er altijd wel een geschikte tussen zit. Nadeel is weer dat je even moet opschonen. Iemand nog tips, want met Synology Photos gaat dat veel te langzaam.
En ik kom er net achter dat Synology Photo van elke HEIC een JPG maakt. Alles dubbel dus :o
-
Maak nu maar eens een nieuw Topic, dit Topic gaat immers over Synology photos auto sort script en je hebt al een afslag gemaakt naar het zoek naar dubbelen..... ;)
-
Ik kom er net dus achter dat ik een aantal exact dezelde foto's heb met verschillende MD5 hashes. Die zag ik niet aankomen (:
En helaas de bas64 check is ook anders. Dat is vreemd, want het zijn het exact dezelfde foto's.
Ik heb even van 2 dezelfde foto's met de EXIF data vergeleken en de ene heeft meer information dan de andere. Dat zal het verschil zijn.
-
Zeer waarschijnlijk omdat de EXIF data volgens mij in de file zelf staan.
-
Ik heb het oorspronkelijke script inmiddels aardig verbeterd. Het is nu een stuk sneller en gebruikt versienummers als een foto dezelfde foto exact hetzelfde datum/tijd moment heeft. Het namelijk komt wel eens voor dat er een paar foto's in dezelfde seconde gemaakt worden. En als je de foto bewerkt en het origineel niet vervangt. Nu is dat dus foto YYMMDD_HHMMSSv1.jpg en YYMMDD_HHMMSSv2.jpg. Het oorspronkelijk script gaf een random naam aan de foto (of video) als bestandsnaam al bestond. En dan staan de bijna dubbele foto's dus niet bij elkaar en kun je ze ook niet eenvoudig vergelijken en opschonen. Verder zijn er nog meer verbeteringen:
- vervang spaties in bestanden met underscore (_), anders loopt het script stuk
- scan alleen in huidige map en niet ook de submappen, want het script kan alleen bestanden in de bronmap verwerken
- scan alleen voor files en sla mappen en verborgen bestanden over
- gebruik MD5 voor controle op dubbele foto of video
- gebruik versienummers indien bestand met dezelfde naam al bestaat