This seems to happen occasionally. One album will have the correct slug but there will be no images in it. The other will have the same slug with “-1” appended to it, and it will contain the images.
If I remember correctly, Lightroom will show only the album with the “-1” appended.
You should be able to delete the empty album using Backlight Publisher.
After deleting it, you should be able to change the slug in Lightroom Publisher.
I’m not not quite sure if I understand you correctly. You mean to just delete the Album that does not Contain any picture via the webfrontend, right?
For sure I can do this but this is pain in the *** to be honest.
In my workflow I am creating hundreds of new Albums and if I always have to delete the duplicated one this would slow me down tremendously.
Or did I missunderstand you?
For clarification… I have one AlbumeSet where I created a bunch of Albums in it. Every time I create now an album I get a duplicated one. I think there is something wrong in the publisher or in der DB?
But that’s only practical if duplication happens only occasionally, which is my experience.
If this is happening in only one album set, I’d first try deleting that set and starting over. But if you already have lots of albums in that set, then that too would be a pain.
my guess is that there may be a database problem and @Ben will need to take a look.
on the chance that Lightroom is creating the duplicate albums, you can try resetting the Lightroom Preferences file. That can often fix Lightroom oddities.
It may be that your server is redirecting your requests, causing duplicate requests from the Publisher. Can you check that your API URL set in you Lr Publisher starts with https and includes the exact URL that your site uses? One way of verifying this is to paste that URL into the browser and seeing if it is redirected to another URL. If that happens then use that final URL in your Publisher settings.
Thanks for checking. I’m not sure what’s going on. The log files created in Lightroom show the details of requests and responses from between the Publisher plugin and your server, so will hopefully shed some light on it.
Can you email me the TTG log file for Lightroom? It’s called ttg.log and should reside under a directory called LrClassicLogs in your Documents directory. On my Mac it’s under /Users/ben/Documents/LrClassicLogs/ttg.log. It should be in an equivalent location on Windows PCs.
The file is likely to be very large, so can you zip it before sending? Alternatively, if you rename that file to something like ttg.log.old and then replicate the issue again from Lightroom then there should be a fresh and much smaller ttg.log that just captures that interaction with the server.
I’ve sent you a Message here with my email address. You should be able to see it by clicking on your profile picture followed by the mail icon.
It would also be helpful if you could provide me with a Backlight admin login so that I can see what’s happening in the database. The best way to do that is by replying to my direct message, or by clicking on my name followed by ‘Message’.
Hi @elmex04, thanks for the log file. This is quite a mystery. What looks to be happening is this:
Publisher creates the album on the server. Publisher is then meant to register the returned id from the server.
Publisher then tries to publish the photos. It can not find that registered id, so attempts again to create the album.
What I need to work out is why step 2. can’t see the id. One theory is that the publishing step is happening too quickly after creating the album (though this shouldn’t be a problem, it may be what’s causing it).
In your tests, had you clicked ‘Publish’ within seconds of clicking ‘Create’? If so, can you try another test where you create an album and wait a minute before publishing only photos?
Can you try one more thing:
Visit File > Plug-in Extras > Output Publisher Structure in LR. Then select the name of the Publisher instance you’re currently using followed by clicking ‘OK’. This will list the album structure that LR has for the instance. If you’re able to see a complete structure complete with ‘OK’ button like below, then select the structure and copy-and-paste it into an email.
If there is too much content there, then can you please re-send the updated ttg.log file (viewing the structure with the steps above also logs it to that file).
So to have things clearly… I protocol my steps and resend you the log file
Delete all AlbumSets in Publisher
OK - when refreshing Publisher-side there is no AlbumSet what’s or ever, so we are “clean” now.
create a new publisher connection in lr called FOTOS
I can now see a new publishing link in LR called FOTOS
There is already a Default Album
Checking result in Publisher in BL. There is not yet a Album created
Created Album within FOTOS called “test1”
Publishing the newly created Album “test1”. No I can see the AlbumSet FOTOS as well as the Album “test1” in BL
Album not created double. I can only see one single Album called “test1”
Waiting…
Hardly 2 Minutes later I add a photo to the Album
I choose publish the album.
Image was transferred
Now I see 2 Albums called “test1”. One with the photo and one without the photo.
So, does not seems like a race condition problem to me. Any further ides?
Hi @elmex04, I’m keen to see what the structure looks like A) after creating an album but before publishing, and then B) after publishing (when the duplicate album is then there).
What’s the exact version of LR you are running? I am wondering whether there’s some compatibility issue with Backlight returning the id as an integer and LR expecting a string.