Super Cache caches index page but not post for anonymous user

Here’s an example url (but you could take any):

https://www.travelsignposts.com/Germany/ : a blog index page showing

<!-- Dynamic page generated in 1.370 seconds. -->
<!-- Cached page generated by WP-Super-Cache on 2011-06-16 10:40:12 -->
<!-- super cache -->

https://www.travelsignposts.com/Germany/food/steckerlfisch-oktoberfest-food : a post showing the changing time stamp

<!-- Dynamic page generated in 0.968 seconds. -->
<!-- Cached page generated by WP-Super-Cache on 2011-06-16 19:42:48 -->

It’s probably because you have a capital G in Germany. Unfortunately a change to protect international characters in URLs made the url lowercase. I think I need to make that an optional feature in the next version.

But Donncha, there’s a capital G in both pages, so why would the super cache file be served in one and not in the other? I do note that the super-cache files have a lower case germany in them (and all my other pages use capitalised countries).
I’ve been striving to discover any differences between the two types of pages that would explain the failure to serve, but with my limited coding knowledge (I still struggle with the GET query effect on caching!) so far I’ve drawn a blank…

Does the fact that I’m using mod_rewrite but the debug shows the index page as being “:Served page from supercache file using PHP” give any indication as to what is going wrong?

Yeah, the file is stored in the supercache directory with a small “g” for Germany. The .htaccess rules can’t find it but the PHP might be able to.

I have removed the htaccess rules in the web root and switched to PHP but unfortunately nothing appears to have changed. It’s still a puzzle to me that the index pages are served from the super cache but the post pages are not, you would have thought if it was the cap letter both would have failed!
I’m sure this was working a short time ago (at least on some posts), and I’m wracking my brains to think of what I changed, but failing miserably. If you’ve any more ideas, I’d sure like to avoid the awful prospect of trying another caching plugin!

I have a prototype blog on the same network that does not have a capital letter. It has a single Hello World post. The behaviour is similar to the Germany blog! Here are the two URLs:
https://www.travelsignposts.com/prototype/
https://www.travelsignposts.com/prototype/country/hello-world

Oh dear, the mystery deepens…

Zamba, please post your error log on pastebin and provide a link. What you posted is tripping the spam filter in a big way.

Oops, sorry about that, I was unfamiliar with using pastebin, but I have now sorted it and so here is the debug log for 2x loads of an index page and post showing the problem (Super Cache issue):
https://pastebin.com/iD97iysp

Does [PATH] in your debug output have a capital letter in it?

No, all lower case and pretty normal, /home/xxxxxx/public_html/
One thing happened: yesterday out of the blue supercached files were served. I did check the urls I have been checking and they DID serve the supercache files, as evidenced by the <!– super cache –>. Unfortunately, today the situation has regressed to the prior situation. I have altered nothing in the various blogs I checked, only a couple of entries have been made in different blogs.
I really appreciate your help with this, I’m determined to get things working.

I’ve been quiet because I thought I’d solved this, but apparently not.
Here is the current state of the play:

SERVER: Centos+Litespeed VPS, WordPress 3.1.3

DOMAIN: https://www.travelsignposts.com

WordPress multisite network of 26 blogs (1 main site, 25 sub-blogs in sub-folders, including one prototype blog).
There is a separate WordPress blog on the same server under the same domain in a sub-folder using a different database.
The Super Cache plugin is network activated on multisite, and each sub-blog configured. Htaccess method is used, but an earlier trial of using php made no apparent difference to the non-serving of supercached files.

Garbage collection is set at 172800 secs.
Preload is set at 43200 minutes

sample URL of sub-blog: https://www.travelsignposts.com/Germany

sample RL of sub-blog post: https://www.travelsignposts.com/Germany/food/steckerlfisch-oktoberfest-food

sample URL of sub-blog page: https://www.travelsignposts.com/Germany/map

URL of separate blog: https://www.travelsignposts.com/wordpress

Sample URL of separate blog post: https://www.travelsignposts.com/wordpress/classical-music-and-operas/passau-music-festival

CURRENT POSITION:

This position is the same as that prior to my pre-load activities listed under “Recently”.

All posts and pages are supercached.
All blog index pages are served from supercache.
The multisite blog network Super Cache uses .htaccess to serve its files

Main blog: Index page and pages supercached (posts pulled from sub-blogs redirect to respective sub-blog posts as designed: SiteWideTags plugin).

Sub-blogs: Index page served from supercache. Posts and Pages not served from supercache (supercached file not found so new one created).

Separate blog: Supercache functions as normal, all posts and pages served from supercache. Supercache uses php to serve its files.

RECENTLY:

The position was the same as outlined above, when I tried pre-loading all sites in the main network one by one. This resulted in the supercached files suddenly being served as they should be.

However, a few hours after all the sites had been pre-loaded (around 12,000 files, three days later), Supercache stopped serving files from the supercache and the position regressed to the current position. This resulte in an approximately threefold increase in CPU load.

COMMENTS:

It has been noted that the url used in the supercache directory uses a lower case as opposed to the upper case in the WordPress file, i.e.
Actual URL: https://www.travelsignposts.com/Germany/food/steckerlfisch-oktoberfest-food
Supercache URL: /home/MYACCOUNT/public_html/wp-content/cache/supercache/www.travelsignposts.com/germany/food/steckerlfisch-oktoberfest-food/index.html

The argument against this is that the blog index pages (which are served from the supercache) also have the upper case country name in them, and a corresponding lowercase URL. Similarly, prototype blog has a lower case folder name and exhibits exactly the same behaviour as those with an upper case name.

So, that’s where I am at the moment. If anyone’s got any ideas I’d be pleased to hear them, as I’m struggling a bit. Having had an albeit brief experience of the promised land when supercaching worked, I’m determined to get it running…