· Lightroom Exchange
· Photographer's Toolbox
· alloy photo
· Rob Cole
· John Beardsworth
folder-publisher-20130513.27.zip
· FAQ
· Version History
· Update Log via RSS
· Installation instructions
· “Donationware” Registration Info
· More Lightroom Goodies
· All-Plugin Update Log via RSS
· My Photo-Tech Posts
· My Blog
This Lightroom “Publish” plugin allows you to export copies of your Lightroom photos to local disk in a folder hierarchy that mimics the folder hierarchy in your Lightroom catalog. I've found it very useful in mirroring my Lightroom catalog as small JPGs on my wife's computer.
This plugin works in Lightroom 5, Lightroom 4 and Lightroom 3.
The same download works for both Windows and Mac. See the box to the upper right for the download link link (in orange) and installation instructions.
This is a sister plugin to my Collection Publisher plugin (which is similar to this plugin, except that plugin mirrors a collection hierarchy instead of a folder hierarchy).
Unlike a normal export, this Publish service allows you to create an ongoing relationship between the photo in Lightroom and the copy on disk. The tree on disk is refreshed for any changes (new images, removed images, and image changes) each time you “Publish”.
The plugin is normally used in the following pattern:
- Initial setup of the publish service.
- Populate the default collection with image you want to mirror, or create a smart collection that identifies the images you want to mirrors.
- “Publish” them, causing copies of the images to be reflected into a hierarchy on disk matching the folder hierarchy in Lightroom.
- Going forward, any time changes are made (images updated, added, or removed), “Publish” causes those changes to be reflected on disk.
Publish-Service Setup
When setting up a new publish service, you first assign a name, though you can leave it blank if you'll only have one...
You indicate where published copies are to be placed by specifying the root of the publish tree. When first setting up a new publisher, you'll likely want to pick an empty folder as the root.
The next sections are all part of the standard Lightroom export. In them you decide the size and quality of the published copies...
The next two sections shown in the example aren't included unless you specifically add them:
They're from my crop for iPad and Metadata Wrangler plugins; I use them in my exports to allow me extra control of what metadata is included in each exported copy, and in the case of my iPad portfolio, special iPad-specific crops so that some images better fill the screen.
The next section controls what changes in Lightroom should cause published images to be slated for republish.
Then we have a plugin-specific seciton on file renaming that gives much more flexability than Lightroom's standard “File Naming” section, should you need it:
The next section provides a way to do an FTP sync of the published copies, should you need it. Photo-viewing iPad apps tend to allow updates via FTP sync, so this section is convenient for that.
It's here as a convenient tool rather than an actual part of the configuration; the FTP sync is never automatic... it happens only when you launch it manually from the Publishing Manager.
The plugin also provides a way to import and export settings, making it easier to set up comperable publish services on multiple catalogs (such as when part of your library is on your desktop, and part on your laptop, as is my case).
When first setting up a service, you'll have the ability to import settings...
... but once it's been set up the first time, after that the section allows for export:
Collection Setup
Once you've got the publish service created, you can drag images into the default collection, or you can create your own collections, including “smart collections” that identify images to include via rules (e.g. “all five-star images”).
The default publish location for any image in any collection is that its folder structure in Lightroom is replicated and placed starting at the root folder chosen when you set up the publish service. However, you can modify aspects of how image locations are mapped when you create/edit a collection:
Availability
This plugin is distributed as “donationware”. I have chosen to make it available for free — everyone can use it forever, without cost of any kind — but unless registered, its functionality is somewhat reduced after six weeks.
Registration is done via PayPal, and if you choose to register, it costs the minimum 1-cent PayPal fee; any amount you'd like to add beyond PayPal's sliding fees as a gift to me is completely optional, and completely appreciated.
Note: a Lightroom major upgrade, such as from Lr3 to Lr4, de-registers the plugin in the upgraded version, thus requiring (if you want to maintain registration) a new (1-cent if you like) registration code in the upgraded version. It makes for a hassle every couple of years, I know. Sorry. See this note for details.
For details on plugin registration and on how I came into this hobby of Lightroom plugin development, see my Plugin Registration page.
Version History
(
Update Log via RSS
)
| 20130513.27 | More changes for the root-selection problem... really seems to be a bug in Lightroom, but it's hard to tell because I can't replicate the bug myself. |
| 20130501.26 | Update for Lr5 |
| 20130412.25 | Build system update. |
| 20130329.24 |
More with with the code that handles changing the root of the publish tree. |
| 20130220.23 |
Added support for some new template tokens: FlagStatus (requires Lr4.1 or later), and for Lr3 and later, a bunch of IPTC extended metadata: AdditionalModelInfo, CodeOfOrgShown, DigImageGUID, Event, ImageSupplierImageId, MinorModelAge, ModelAge, ModelReleaseID, ModelReleaseStatus, NameOfOrgShown, PersonShown, PlusVersion, PropertyReleaseID, PropertyReleaseStatus, and SourceType. |
| 20130209.22 | More build-system maintenance |
| 20130206.21 | Tweak for my registration system |
| 20121210.19 | Added some extra debug logging. |
| 20121024.18 | Allow Video to be FTP'd as well. |
| 20121009.17 |
Workaround for an "attempt to call field 'getProgressScope'" bug introduced in Lr4.2. Disallow DPX video export because it breaks things. Enhance the {EMPTY} template token so that it interrupts the squelching of superfluous joining characters. |
| 20121004.16 | Oops, the file-extension thing got worse, not better... reverting that change. |
| 20121003.15 |
Work around a "situation" (likely Lr bug) where exported video loses its file extension. More debug logging for the elusive "no root folder" problem. |
| 20120821.14 |
Updates to the environment in the {LUA} token (in the template tokens in my plugins) to include photoTime() and currentTime(), and other changes to match the updated docs at that link. . |
| 20120810.13 | Added some debug logging to try to track down an error |
| 20120722.12 | More debugging for the "choose a root folder" bug that seems to still affect a few folks. |
| 20120531.11 | Oops, I was moving the original XMP file (when the Publish format was "Original" instead of copying it. Fixed. |
| 20120529.10 |
Finally tracked down why the plugin had problem with Windows network shares. Ended up filing three separate bug reports with Adobe, but in the end was able to work around the bugs, so hopefully it's working now. Update to handle the Mac App Store version of Lightroom. |
| 20120510.9 |
Tweak for Lr4.1RC2. Added the ability to move/reset the root folder. As a byproduct, this should allow the "choose a root folder" situation to be repaired. In some crazy file-renaming situations, the plugin could get confused about the file extension. Enhanced the send-log dialog to hopefully make reports more meaningful to me, yielding, I hope, the ability to respond more sensibly to more reports. Added to the template tokens supported by the plugin: {FullMasterFile}, {FullMasterFolder}, {FullExportedFile}, and {FullExportedFolder} |
| 20120330.8 | Update to handle 4.1RC |
| 20120315.7 | Add some extra debug logging to try to track down some network-folder errors. |
| 20120309.6 |
Update to the debug logging to better track down timing issues that might arise. |
| 20120228.5 |
Wasn't handling some kind of file-rename templates properly. Now handles things much more gracefully when some files are offline when the publish is started. Better support for video in Lr4. |
| 20120224.4 | A few bug and Lr4 fixes, and some extra debug logging. |
| 20120217.3 | Didn't handle XMP sidecars correctly when publishing original raw files. |
| 20120217.2 | Discovered why "metadata that triggers a republish" wasn't reliable, and fixed it. |
| 20120213.1 | Initial release, evolving from my earlier tree-publisher plugin, which dated back to the summer of 2010. |
Thank you Jeffrey!
Hi Jeffrey,
I just switched over to this plugin from tree published and I was wondering if there is some way to “mark as published” so that I don’t have to republish many thousands of files which have not technically changed.
No, sorry, there’s no easy way to back in old stuff. I’m facing the same thing with 100k photos, but I’ll just let it run overnight. —Jeffrey
Hi Jeffrey,
can you relocate the root folder? There’s only a visit button now while the old plugin let you change it.
Not at the moment, but it will… that’s the last big thing to add. I wanted to get the plugin out for a bit, though, before I tackle root relocation. I’ve moved back over to updating plugins for Lr4 for the time being, but I’ll probably get to the relocation thing within a month. —Jeffrey
Hi Jeffrey,
last week I found your new FolderPubisher Plugin. It would be very helpfull for me.
I just tried it the but hadn’t sucess.
I get the the warning window ” TreePublisher_FolderLocal:161: ‘for’ limit must be a number” and the plugin stopped working.
Woul’d you pleas help me
Thank’s Herbert
Sorry ’bout that… I’ve pushed a new version of the plugin that should fix it. —Jeffrey
I’m using Lightroom for many years and it serves my purpose perfectly! On the other hand I use the iPad more and more for presentations. The main problem I am facing is about the order/sequence of pictures within a folder. Whenever I synchronize a new “picture folder” with my iPad, the Apple software copies the photos in a “ramdom order” on the iPad, which sometimes makes to presentation “useless” (I have tried with renaming; changing the dates in the exif data, etc.). Is your plugin able to make sure that the sequence of pictures stays the same on the iPad (as in Lightroom)? That would be a great help!!
Thanks for your answer
Markus
You’re running into a problem that I talked about and tried to solve on this post, but in the end iTunes is just too unpredictable. The workflow becomes predictable and smoother when you abandon Apple’s “Photos” app for a third-party app. I talk about that and this plugin in this post. —Jeffrey
Hi Jeffery,
I would love to use your plugin but it does not work for me. All my images are placed in the root folder of the export. Exmple:
\\DISKSTATION\photo\image\test\test.nef
is exported to
\\DISKSTATION\photo\
(both leading and trailing path to ‘None’)
I’m using Windows and Lr4. Am I doing something wrong or is the network share I use a problem?
Hi Jeffery,
I did some testing and it seems that filenames on network shares are not handled correctly (see last message). E.g. for “D:\Images\a\b\c\img.jpg” everything works fine but for “\\MYSHARE\Images\a\b\c\img.jpg all” exports are transferred to the output root without any subfolders. The output root is also set to a network share. (Windows, LR4)
With kind regards
Tobias
I can’t reproduce this bug on my side, but I’ve just pushed a new version of the plugin that has more debug logging, so if you could try it, then if it doesn’t work, send the log with a description of what went wrong, I’ll take a look. —Jeffrey
Jeffrey,
I just registered this plug-in and while doing the initial setup I realized I can’t save the changes because the save button is disabled. On the bottom of the plug-in dialog there’s a message saying “Can’t save changes: Choose a root folder for the publish tree”. The publish tree root is filled in, in my case with E:\Dropbox\iPad, but no matter what I put there the error stays the same. I believe it’s an error related only to Windows, which is my platform.
Any advice of how to go around this issue?
Thanks,
Gabriel
After getting into that situation, could you visit the plugin manager and send the log, along with a short recap of the problem? Thanks. —Jeffrey
Hi,
I had the same problem as Gabriel, “Save” button inactive, I just restarted Lightroom and the button became active and worked ever since. Hope it helps.
Hi, I don’t know if it’s a bug or made on purpose but if I have folder with pictures with no ratings at all is published with no problems. Then, if I put some ratings, 4,5 stars to some pictures, in “Folder Publisher” those pictures will show in “deleted photos to remove” category and of course will be deleted from the “root of publish tree”.
Thanks,
Ion
It sounds as if you’ve got them in a smart collection where a rule excludes ratings of 4+ stars. —Jeffrey
Spot on. It was a smart collection with the rule of any with no stars, when I created it I thought was a good idea to include all photos but when I started to give stars I forgot about the rule in collection.
Thanks for the quick reply
Ion
Thanks to your folder publisher and your pointer to photomgr pro, i no longer need to maintain a publish collection for every collection i have in a flat hierarchy to get photos onto my ipad nicely ( i organized by -> year > month -> photos and itunes doesn’t like that but photomgr deals very nicely with it.
I have found one problem but i’m not certain it’s specific to this plugin. When I rename the source files in lightroom, the plugin doesn’t by default move them to be republished. I can’t find anything in the plugin config to tell it to republish based on file name change. Is this the expected behavior? If so, any idea why and anything I can do to change it?
It’s an oversight (or inexplicable decision) on Adobe’s part. I submitted a bug about it, asking for folder/filename to be included in the list of things that can trigger republish. We’ll see. —Jeffrey
Hi,
I have tried with the plug-in on WIN7 but cannot manage to let it create the folder structure as the photos are structured on the server. It constantly saves the output under the choicen root.
What is wrong in my procedure?
Kr
Kim
It turns out to have been a problem with Lightroom on Windows for certain kinds of file paths. I finally pushed a version with a workaround, as of 20120529.10. —Jeffrey
Is the plugin supposed to be “Processing Updated Publish Criteria” on every LR4 restart? This seems to have started a few updates ago.
It’s fairly annoying because it takes about a minute on my largest catalog. Even on my smallest catalog, it’s about 10 seconds.
This is something on Lightroom’s side, and I don’t understand it. I saw it in the Lr4 trial, but thought it was fixed in the real Lr4, so didn’t peruse it further. If you’re getting it in the real Lr4, I’d be interested in a copy of your catalog (sans photos) to test with and to send to Adobe. But before that, perhaps give the Lr4.1RC a try? —Jeffrey
Hi, the download link http://regex.info/LightroomPlugins2/releases/folder-publisher-20120330.8.zip doesn’t work. Can you please check that?
It seems to be working when I test it, though you must try to download it via the link on the plugin page, or via the plugin itself. If it’s not working for you in those situations, I’d appreciate it if you could follow up with more details… —Jeffrey
Thanks for your reply Jeffrey. I’m using Firefox with RefControl which blocks referrers. After disabling this for your site it does work.
Ah, that makes sense. Unless the referrer is from my site, it forwards you to the plugin’s home page, so that folks following a hard link will always be presented with the latest version. —Jeffrey
Jeffrey,
Have now found a corrupt file and a few missing links so have managed to babysit all the files through now.
Great plugin, thank you.
Peter
I also have the “Processing Updated Publish Criteria” on startup. I´m using 4.1RC. Where can I send a copy of the catalogue?
Adobe has already been sent a way to reproduce the problem, so there’s no benefit to sending additional catalogs…. just send hope.
—Jeffrey
For me the “Processing Updated Publish Criteria” has stopped with 4.1RC2
Thanks!
Folder publisher plugin 20120529.10 in LR4.1 (upgraded from 4 to 4.1 yesterday)
When I use the folder publisher to… well… publish photos to a folder with your plugin, the XMP files for the picture are lost after the publish. The XMP files *are* present in the folder I publish to. The XMP files are for NEF files. The publisher is set to publish the original files. The Lightroom catalog is set to write changes to XMP files automatically.
I also tried this with your flickr publish plugin. When that plugin is used to publish pictures, the XMP files remain where they should be, so no problem with that plugin.
For me this is a very serious issue. At the moment I have to remember to write the XMP files again, with the Write Metadata to Files function in Lightroom, after every export with your folder publisher plugin.
Yikes, sorry about that… minor little boo-boo with the plugin there. I just pushed a fixed version. Thanks for the report! —Jeffrey
Phew!
Now it works correctly again.
Thanks for that very quick update!
Hi Jeffrey,
very very nice Plugin, I use it for the same purpose that you developed it for
One issue I have – Pressing “publish now” it will publish some photos but sooner or later will stop with the error
“Warning: Collection can not be updated. An internal error has occured: bad argument #1 to ‘gsub’ (string expected, got function) ”
Restarting the process it will publish some more pics but again, sooner or later will stop with the same error. For some photos, it will always interrupt with this error and I have to deselect them for publishing in order to continue with publishing the other photos.
I use Win7x64 and LR4.1×64 publishing to a network share on a Win7x32 server, which is assigned a drive letter and using the “make available offline” feature – the error, however, occurs in work offline mode, as well as working online. I’d like to submit a log but have no clue how to aquire it
Best regards,
Martin
If you get this, please send a log, but I don’t have much hope it’ll help because I did get one long where the comment mentioned this bug, but the log had nothing, which means that the error is not from the plugin but from Lightroom proper, so that makes it much more difficult to debug. —Jeffrey
Hi Jeffrey
I just upgraded to LR4 (4.1) and installed this plugin (I used to work with “Tree Publisher”)
When trying to create a new publishing service (Following your instructions)
I get this message “Choose a root folder for the publish tree” and “Save” button is grayed.
Choosing “Publish tree root” directory doesn’t change it and I cannot save
Thanks, Love your work
If you’re sure you’re using the latest version of the plugin, please send a log after encountering this situation. —Jeffrey
Hi,
I have a series of folders an they all export fine, but later, if I rename one folder or move one of them, let’s say inside another folder as a sub-folder, the move is not picked by the plugin and mirror it onto the export folder. Any change (metadata,crop…) to those pictures is processed without problems inside the original folder. I ticked all the “triggers”.
Thanks,
Ion
Yeah, Lightroom doesn’t account for that (though I wish they would). It’s a minor hassle, but the best I can suggest is to select all the images in the affected folder and “mark to republish”. —Jeffrey
Sometimes when I publish pictures the jpg file name ends with -2 like _DSC0956-2.jpg instead of _DSC0956.jpg. In the plug in log file I can read something about duplicate file and then create a copy instead of overwrite.
I can’t figure it out when the plug in decide to create a new file or overwrite. I don’t get any confirmation dialog or anything.
It does not matter if I actually delete the jpg-file and publish again. If the plugin think It need to create a copy instead of overwrite it always add -2 to the file name even if there is no file from the beginning. If I publish a whole folder, this only happens random to some of the files, not all of them.
I do add metadata and change develop settings to try different looks at my pictures but it is really a problem with not having the file names correct and a lot of duplicates.
My only solution right now is to publish to a empty temporary folder and then manually move my files to my real album folder. It actually does this by itself because of the “leading path components strip” settings I have. Before I published directly to my album folders but I can’t do that until the rename/overwrite issue is taken care of.
I’m still a happy paying customer =)
If your file-naming (and/or file-renaming) rules would give multiple images the same filename, the plugin adds a sequence number, and once it’s been added, it maintains it so that the filename of an image doesn’t randomly fluctuate each time you happen to publish. This was a really difficult nut to crack and the plugin goes to extensive lengths to make sure that images don’t overwrite each other and filenames don’t change willy-nilly. If you don’t care for it, look to a different way to name the files so that they’re unique (and, also, take note of the comment that follows this one). —Jeffrey
Hi Jeffrey,
LR 4.1 & Folder Publisher 20120531.11 here.
I’m trying to make use of your Advanced Renaming feature to accomplish what I figured was a simple output format. I want to end up with this:
Filename-CopyName.jpg (or with underscore instead of dash) (or with underscore instead of dash)
But I’m ending-up with:
Filename-Seq#-CopyName.jpg
At least I surmise it’s sequence number, I’m really not sure where the value is coming from, but I get a 1-based sequence applied to the virtual copies if I’ve got multiple virtual copies of the same DNG in LR.
For example:
Master file: 20111203124523_0027.DNG (Copy name field is blank for the master copies)
Virtual copy 1 Copy Name: crop1
Virtual copy 2 Copy Name: bw
Advanced renaming template: {Filename}-{CopyName}
When I run these through advanced renaming I get:
20111203124523_0027.jpg
20111203124523_0027-2-crop1.jpg
20111203124523_0027-3-bw.jpg
So I’m a little puzzled where the -2-, and -3- are coming from. I tried enabling the standard renaming (set to just Filename), and disabling it, but get the same results either way. It’s acting as if it thinks there’s going to be a filename conflict, so is automatically appending the “-#” your routine has a chance to append the copyname.
Am I missing something here?
p.s. Please consider adding the “_” underscore to your list of standard joining characters, as that would be my usual preference.
Cheers,
-pete
Those are indeed sequence numbers, and Lightroom is applying them before ever letting the plugin have a look at the filename. Whether you rename with Lightroom or not, Lightroom will apply the sequence numbers if it thinks there will be a conflict, so to avoid that, you could use Lightroom’s renaming to include the filename and the copy name…. if that combination is unique, it won’t add the sequence numbers. The problem is that it won’t get rid of a trailing minus. So the real solution here is to leave Lightroom’s renaming turned off, and build the final filename in the plugin without regard to whatever the exported copy’s filename is, e.g. with “{LibraryFilename}-{CopyName}”. I’m really hesitant to add underscore to the list of joining characters because it’s so common in camera-produced filenames. —Jeffrey
Great plugin!
But I can’t change root directory once chosen?
Yes, since version .9. —Jeffrey
Thanks! Again another great plugin! The republish feature on the change of a source file/directory rename would indeed be very helpful!
Kind regards from Berlin, Michael
Indeed it would, but Lightroom doesn’t allow for it )-: —Jeffrey
Hi Jeffrey,
the Folder publisher plug-in is just what I was looking for, unfortunately while I was trying to configure it, I stumbled upon an issue that does not allow me to save the new publisher.
Regardless of what I enter into the “Publish Tree Root” TextBox, the publishing manager states that It “Can’t save changes: Choose a root folder for the publish tree”.
The save button is also disabled.
I am currently using Lightroom 4 with wondows 7.
Regards from München,
Marcus
Hi Jeffrey,
your plugin is verry cool and I would like to request a new feature for smart collections in jf Folder Publisher:
It would be a nice feature, to export all photos of folder where at lease one photo within that folder hits the defined criterias.
Regards,
XaronX
hi jeff, just updated to the latest version — folder-publisher-20121003.15.zip — something seems to be wrong with the file format: i have selected JPG as format, but end up getting all pictures exported as NEF. any idea what i might be doing wrong?
It was a mistake in that version, sorry… a fixed version is now out. —Jeffrey
Hi Jeffrey,
For a short while I am using “Folder Publisher” now, and I quite like it! I wonder about two things: when I hit delete on an image, “Folder Publisher” instantly removes it from the target directory, even when I decide to hit “cancel” (to not delete the image). It is then marked for re-publishing. I guess this is “works as designed”…? The other thing: when I move an image (within Lightroom) to another folder, this is not recognised by the plugin and therefore will not be reflected in the target directory. Is this an intended behaviour, and if yes, do you have a workaround for this scenario?
Kind regards from Switzerland
Christian
Both issues are Lightroom limitations. Neither are desirable, but there’s nothing I can do until Adobe gives the plugin infrastructure some TLC. —Jeffrey
Last update for tonight.
On 2nd thought, my junction workaround may do more harm than good. Since the path is actually valid, the plugin appears to try to migrate the images from a to b, not just update the root pointer. What I may try next is, rather than a junction, just create a dummy full path to the old root location to see if that alone will enable the save button.
Am I misunderstanding the logic behind the change button? I definitely don’t want to physically move any images, just update the root pointer.
Thanks,
Pete
When you change the root folder, it moves all the files that had been under its control, from the old root to the new root. At least it should. It may take a while, which is perhaps why the save button doesn’t enable right away. You might want to look at the log to see whether there’s any activity… —Jeffrey
Thanks!
This is an EXCELLENT plugin. Works great.
FYI I had the “Publish Tree root” as well in the beginning.
But as I saw some Swedish (standard translations from Adobe I guess) beeing mixed up in your english text inside the plugin, I took a longshot and changed my Lightroom language to English. This removed the bug for me.
Thanks again!
/Jonas
Jeffrey, thank you for this plugin, but even after donation and entering registering info I can’t export more than 15 photos.
In plugin page i see: plugin is unrestricted and registered to Stanislav Ploschansky….
But in export I have the same error: This version of LR/TreeExporter can only export up to 15 files. Please consider offering a donation in order to download the unrestricted version.
Any comments?
LR/TreeExporter is not my plugin… I think you’ve confused it for my Folder Publisher. —Jeffrey
Is there a way to publish the photos but have them placed into a subfolder of each original folder?
For example:
-ORIGINAL FOLDER STRUCTURE
\directory\project\originals\
-DESTINATION FOLDER STRUCTURE
\directory\project\print size\
If this is possible, I will definitely use this for most of my exporting needs.
Yes, you can do that. Give it a try; my plugins are free. —Jeffrey
I have a severe problem with my Folder Publisher setup: after using a dedicated Smart Collection for some months (publishing approx 10.000 photos during that time onto my photo server) I opened LR today and found that the collection below that service had gone completely.
I tried to restate the collection by redefining it and – alas – I now have all my 10.000 photos back but on the “to be published” side of the “coin”.
I have all the photos on my server and do not want to republish them another time! What can I do to re-establish the state: photos transferred and marked as published without tzransferring all the files again?
Klaus
The service shouldn’t have just disappeared, so I’d worry about a corrupt catalog, perhaps going back to a backup and checking its integrity. There’s no way, unfortunately, to recreate the thing and have it recognize the already-published photos, sorry. —Jeffrey
That is ther answer I feared. I do a weekly backup of my catalogs so the choice was losing one week of MY work or re-transferring and re-indexing 10.000 photos to my internal Synology server (which will take approx. one week of SERVER time). So the decision is really to re-transfer!
What worries me is that during backup LR will always check integrity and optimize the catalog. Hopefully no hard disk problem.
Anyway: I still have one question. Is the smart collection that you are using for the publishing module something that can be seen as a seperate file or description? Or is it integral part of the catalog and there is no way to handle a rescue separately?
Klaus
Publish stuff is all in the catalog… only your encrypted temporary login information is kept elsewhere (Lightroom’s preferences file). —Jeffrey
It would great to have the same PlugIn as a “Symlink Publisher” which create the same structure from a Collection and/or Folder hierarchy.
Within Windows (Mac?) it should just create a symlink/hardlink (possible to do with mkling) to the Picture-/Video-File/Folder instead of a copy.
Advantage: Save space and creating is fast. usefull e.g. for an slideshowplayer which plays the content from (symlink) folder(s)/files and with this it is possible to play slideshows which playing videos too (what lightroom cannot this time).
It would be nice if we can edit the paths more advanced
for example my directory structure is like this
DRIVE:/Events/Year/Month/Day-Event_Name/Approved/Getting_Ready
DRIVE:/Events/Year/Month/Day-Event_Name/Approved/Bride_Groom
…
…
I want to export my files in a sub-directory named Export placed in Day-Event_Name
DRIVE:/Events/Year/Month/Day-Event_Name/Export/Getting_Ready
DRIVE:/Events/Year/Month/Day-Event_Name/Export/Bride_Groom
…
…
So I want to strip the second last directory name not the last one.
I think a more advanced path options like the ones in Collection Publisher will be welcomed.
Thank you.
You can do that with the Collection Publisher, where you use a {LUA=…} template token to craft whatever target folder you want. If one rule hands all the kinds of photos you might put into it, you’ll only need one collection. —Jeffrey
Brilliant!
Writing from New Zealand. I love the plugin, works very well. I’m using a Mac.
My question: My catalogue sits on USB drive X, I publish to another USB drive Y. During the publishinh I notice that the process consumes disk space on the volume MaIntish Hd (main drive).
Why is this and how can I clean it up?
Cheers
I don’t know, but it could be that Lightroom is writing to a temporary file? Also, check the settings for the size/location of the Camera Raw cache. —Jeffrey
I’m very happy with your plug-in, but now I would like to have a second publishing to another drive.
How to do this – or is it impossibel ?
Greetings from Vienna/Austria
Franz
Right click on the publish-service header and in the context menu that pops up select “Create Another Publish Service…”. —Jeffrey
Hi Jeffrey,
Thanks a lot for changes in 20130329.24 build. The changing of the root of the publish tree now without problems.
Thank you!
I have a nested structure of folders within folders within folders. Folder Publisher doesn’t seem to understand the nesting. The export/publish results in all of the individual folders being saved in the root tree, but the nesting is gone. Am I missing something?
It should work as you expect, preserving the folder structure, unless you’ve told it to strip X levels of leading path. If you haven’t done that, publish a few photos that go to the wrong spot and send a log with details about what should have happened vs. what did happen. —Jeffrey
About the post by Henk on March 3rd, 2013 at 1:51pm JST above: it witnessed the same behaviour and observing the file creation pattern, this is what seems to happen: it looks like LR is rendering the files asynchronously ahead of the plug-in (i.e. as if LR uses the hard drive as an unbound queue of the files to send to the plug-in). In my case, the destination directory for the files is on a network drive and therefore it is slow to write the files. Therefore, lightroom produces the files much faster than the plug-in can write them (after renaming and some other processing i guess), which causes my hard drive to fill up (backlog) because I have thousands of photos to publish and a small main HD (SSD).
The moment I cancel the publication, all these files go away but the number of published files is not affected.
Just my $2 cents about a behaviour that is annoying. Can something be done about that?
Thanks and best regards.
Unfortunately, Lightroom does all the rendering in the background, and just passes off the rendered copies to the plugin when the plugin is ready. There’s now way for the plugin to say “go slower”. If the plugin processing is slow (e.g. uploading somewhere, or writing to a slow network drive), this creates a backlog on the computer and turns the CPU into a space heater for a while. My requests for some control over this have not been fulfilled. )-: —Jeffrey