Hi
Have found the Dynamic Album feature to be great value.
Have however found an issue that may be know already but could not find when I searched.

I have dynamic albums called 2010.alb 2011.alb etc in multiple directories locations.
Each has a different in albums= set.

However when you view the library via a browser it starts to get confused and shows the contents of the most recent one viewed for all instances of the particular dynamic album.

To test
I have renamed the .alb files to a unique name but issue continues.
I have changed the display name for the dynamic album and it seems to fix the problem.

So is it not possible to have multiple Dynamic Albums with the same display name e.g. 2011

Craig

Update:
To Test
I have renamed the .alb files to a unique name but issue continues.
I have changed the display name for the dynamic album and does not fix the problem.

I clear caches and start again and all is good till i access another dynamic album that uses same search term. 2011.

I now have unique names and on disk file names

zen/dir1/subdir1/2011a.alb
zen/dir2/subdir2/2011b.alb

Not sure is this is relevant but the .alb files were copies between each location the edited for relevant inalbums=

Update:
Disabled cash and problem still present.
However with unique on disk name and unique Dynamic Album name it does settle down after I have added some new dynamic albums.
Behaviour seems to be if I add a few new ones then edit the alb files to limit it to a certain directory it can get confused.
leave it for a while and it settles down and delivered correct images in each album.

To test I went in via admin and created a new dynamic album and set it to filter on year 2012
then edited alb file to limit scope to a single directory.
then copied files to 3 new files and edited filter year to 2013, 14, and 15
shortly after all my dynamic albums are displaying incorrect files.
Lets see what it its like in 60 minutes

The name of the dynamic album (the file) actually does not matter naturally. The unique name only is important if on the same level naturally as there can only be one. If subalbums it does not matter actually as with real physical albums.

What matters are the settings within (it also does not matter if you make the dynamic album a subalbum of anohter, just to be clear…) As mentioned elsewhere to get really reliable exact results is to use specific tags.

I am not sure which cache you cleared as we have several. The image cache has nothing to do with this. As it is a saved search it only could be the search cache involved. Or if using the static html cache plugin that but only if you are not logged in.

Also if you use physical albums and dynamic albums side by side be sure to enable the html meta tags plugin and its canonical url options.

So the structure I have is a few levels deep but at the lowest level of each branch where the images sit there is a folder called "xxx by date"
In that folder are the alb files that relate to the folder aboves images.
they all have just one search criteria, a year
WORDS="2014"
THUMB=0
FIELDS=exifdatetimeoriginal
CONSTRAINTS=inalbums=Events/Foose&inimages=1&unpublished=0

So I have lots of directories with images and each has a folder containing alb's with various years.

The only difference between them is the inalbums= statement.

However i am getting images showing in one dynamic album from another random one with the same year selected.

I turned off the caching plugin to ensure it was not contributing

Not sure exactly what you mean by side by side here " Also if you use physical albums and dynamic albums side by side be sure to enable the html meta tags plugin and its canonical url options."

Thanks

I cannot answer to your problem itself. I would have to try and lack the time at the moment.

Not sure exactly what you mean by side by side here " Also if you use physical albums and dynamic albums side by side be sure to enable the html meta tags plugin and its canonical url options."

Well, dynamic albums use images and/or albums from real physical albums. So an image for exmaple is available via two or more – depending on in how many dyn albums it appears – different urls which is very bad for SEO. To lower that issue a bit you need to enable that canonical url telling search engines the "real url" of the items so you don't run into "duplicate content" issues. Unless you don't care about such SEO issue at all of course.

There is a bug in search caching given your criteria. You can work around this by setting the search cache expiry time to zero. Alternatively you can try out the fix at my (sbillard) github ZenPhoto20-DEV repository.

Thanks for that tip re search cache timeout. Worked to fix the issue.
Renamed all alb files back to years and now no issues with wrong search results.
Will have a look at your fix on GitHub on weekend.
Will it roll up into the public release ?
Craig

FYI:
@sbilliard is not part of this project anymore.
ZenPhoto20 is a separate fork based on Zenphoto.
It is also NOT the next Zenphoto version.

@sbillard: please stop promoting your fork on this forum since you don’t even contribute.
It is confusing our users.
Also the attitude "I know the fix but I won't tell" is unpolite and not really following the spirit of Open Source.
Useful posts that actually contribute are always welcome of course.

@fritzl: I am sorry you feel threatened by my posts. I did post the work-around which did solve your user's problem.

I also posted that there is a correct fix. It is not "secret", it is in a github repository with appropriate source control so that anyone can view the fix. As you well know, zenphoto and its derivatives is GPL, so if you choose you can apply the fix. That is your choice.

I would think that it is in your best interests to have anyone provide help for zenphoto users, but maybe I am wrong and you want only to have support when your "team" can come up with the answer themselves.

@sbillard: It's not about feeling threatened.
It's about users getting confused, something we like to avoid.
Of course contributions are welcome through GitHub Pull requests or on the forum but please stop referring to your fork, which is basically another project.

I am not sure how users are getting confused. Perhaps you credit them with too little cognitive skills.

I posted a work-a-round (which the @craig acknowledged worked against your zenphoto) and a place where there is a fix (which needs to be verified as working for the original issue.)

@craig did ask if this fix would roll up into a public release. [Note that the development build I mentioned is not an "official" release of any version of the software, so this was a reasonable question.] I did not answer that question as I presumed he really was interested in when/if the fix would roll up into the official zenphoto release. You have not answered that question either.

I also did not promote ZenPhoto20. I merely mentioned the github repository where the fix exists. The repository bears the ZenPhoto20 reference since it is an offshoot of that repository. It really could have been named anything, but why should I do that? If I were to promote ZenPhoto20 I would have answered @craigs question as to the fix rolling up into an official ZenPhoto20 release. [For the record, once verified it will.]

You really need to become less paranoid.

Wow this is a touchy subject.

I have to say I have appreciated help over the last few weeks from a number of people here (@acrylian and others).

Everyone has been very helpful and I found @sbillard exactly the same. Got a work around for my situation and he did not confuse me but answered my question re roll up to this build.

I would hope that those developing this build would incorporate fixes from wherever they can to better the product. As said the fix is posted on gitHub and anyone can see it, evaluate it and incorporate or enhance.

This sound s a little like the Librelec vs Openelec issues on some of the Kodi forums :-)

Anyway guys, thanks to all of you for your help. I am sure I will have more questions but have to say ZenPhoto is excellent.

Would imagine with the changes of PhotoBucket etc there will be a lot more people out there hosting their own images going forward and will be looking for the best options.