"Cannot get catalog info from nil" when accessing from koreader

[Mossop]

When using koreader to access the OPDS feed the initial list of categories appears but selecting any of them shows the error "Cannot get catalog info from nil". This worked fine with the original COPS.

[mikespub]

Couple of questions:

• what is the setup of your COPS server, and what URLs are you using to access it?
  • Is it on a server, NAS, docker, ...?
  • Is it directly under the web root folder, in a subfolder, behind a reverse proxy, ...?
• do you have access to the web server logs to show which URL koreader is actually trying to retrieve?
• does the web interface have similar issues when navigating to a particular book for you?

I'd like to understand whether the issue is linked to your server setup with the new release, or whether it's something specific about the generated OPDS feed that koreader doesn't get...

[Mossop]

I have COPS (both versions) running under docker with traefik as a reverse proxy. It's at an internal address https://books.mossop.local/feed.php. The web interface works fine.

The logs show that koreader submits a HEAD request to /feed.php and then a GET request to /feed.php to retrieve the front list. When attempting to select one which generates the error it doesn't appear to submit any request at all. That suggests to me that the initial feed is different in some way. This is what I see different in the feed for one of the entries:

  <entry>
   <title>Series</title>
-  <updated>2023-09-02T11:58:16+02:00</updated>
+  <updated>2023-09-02T11:00:15+01:00</updated>
   <id>cops:series</id>
   <content type="text">Alphabetical index of the 107 series</content>
-  <link href="feed.php?page=6" type="application/atom+xml;profile=opds-catalog;kind=navigation"/>
-  <link href="images/serie.png?v=1.1.3" type="image/png" rel="http://opds-spec.org/image/thumbnail"/>
+  <link href="feed.php?page=6" type="application/atom+xml;profile=opds-catalog;kind=navigation" rel="section" thr:count="107"/>
+  <link href="images/serie.png?v=1.4.3" type="image/png" rel="http://opds-spec.org/image/thumbnail"/>
  </entry>

I've tried toggling cops_generate_invalid_opds_stream but it did not help.

This is my config: https://gist.github.com/Mossop/63b11ecba493ee913c87ed2b99e45f1a.

[mikespub]

Hmm - thanks for the detailed analysis. Maybe koreader doesn't like or understand the extra section or thr:count in the feed link?

Does the HEAD request include the ?page=6 parameter or not, with the original and/or new COPS feed? And does the GET request after that include it for the original but not the new feed, is that what you see?

As this is still generating a valid OPDS feed, perhaps the problem is that koreader doesn't quite get it, so we might need to disable the extra info for it :-(

[Mossop]

Ok I did a quick hack and commented out this line and it fixes the problem so koreader must not like the rel="section" attribute.

I looked over the 1.2 version of the OPDS spec and didn't spot anything mentioning the use of rel="section". What I did find was the recommendation to use rel="subsection" for navigation feeds when no other relation is more appropriate and this appears to be something that koreader specifically looks for so I tried adjusting my hack to output that and that also worked.

[mikespub]

Good catch :-) Indeed, OPDS 1.2 is a bit vague on the use of relations other than self, start, subsection and the specific OPDS ones, but in https://specs.opds.io/opds-1.2.html#6-additional-link-relations it does refer to RFC5988:

When creating an OPDS Catalog with Navigation and Acquisition Feeds, OPDS Catalog providers are encouraged to use the relations defined in this specification and [[RFC5988](https://tools.ietf.org/html/rfc5988)]. If no appropriate relation is found, the Feeds should use a descriptive atom:title element and the atom:link elements should use a descriptive title attribute.

And besides self and start, RFC5988 defines:

• section: Refers to a section in a collection of resources
• subsection: Refers to a resource serving as a subsection in a collection of resources

So it seemed like a logical way to use "section" for the top-level navigation per Author/Publisher/Rating/Series/Tag/..., and "subsection" for the levels below it, as that's how it was meant to work.

But I guess I can change it to "subsection" if koreader chokes on it - instead of simply ignoring what it doesn't know... I'm guessing other OPDS feeds who try to do the right thing and specify some other relation will also cause koreader the same problem?

[Mossop]

I don't know the OPDS spec well enough to know how what other clients do. I would guess that subsection is going to be safer than section since it is called out explicitly in the spec text but I don't really know the difference between them. The other option of course is trying to patch koreader to support section. I haven't tested any other OPDS servers with koreader so I don't know what the level of support is.

[mikespub]

No worries, I'll change it to "subsection" in COPS for now, and leave the issue with koreader for anything else :-)

[mikespub]

Included in release 1.4.4