old thread, but see my workaround to get streaming fixed in this thread: https://ubooquity.userecho.com/communities/1/topics/1061-ubooquity-310#comment-5868

Hi Tom, thanks for 3.x! I moved from 2.1.5 to 3.1.0 this week (I know I know). I have Ubooquity running on macOS arm64, Temurin Java 21,accessing it via Chunky 2.5 on iPad. The web side works well. OPDS had three problems, that Claude and I worked-around, I figured I'd share the details in case they help.

1. Folder feeds stop after X entries

Folder lists are paged by the pagination setting (30 in my case), and ?index= works on the server, but tpl-opds-navigation.xml has no rel="next"/"previous" links. OPDS readers only ever see the first page, so in Chunky my publishers stopped at the letter "B". No bueno. Adding these to the feed fixed it, using variables the template already receives:

{{#displayPrevious}}{{/displayPrevious}}

{{#displayNext}}{{/displayNext}}

2. The page-streaming link points to a route that no longer exists

tpl-opds-acquisition.xml and tpl-opds-acquisition-search.xml still point the pse:stream link at /opds/comicreader/, which 3.x doesn't serve. Chunky shows "Error loading page '0000'". Pointing it at the page reader works:

href="{{rootPath}}/pagereader/{{entryId}}?page={pageNumber}&width={maxWidth}"

Buuuuttt

3. Streaming needs a web session, and OPDS readers authenticate with HTTP Basic

/pagereader/ only accepts the web login session. A reader sending Basic credentials gets autherror.png back with a 200 status and image/png, so the app displays the error picture as if it were the page, and never retries with credentials because there is no 401. The OPDS provider's own page route (/pagereader/) builds a URL with a doubled slash (//) that Jetty rejects. 2.1.5 handed the OPDS user to the comic reader, so streaming just worked there.

Suggestions: accept Basic auth on /pagereader/ for users who can see the file (as 2.1.5 did), and answer unauthenticated requests with 401 plus WWW-Authenticate: Basic rather than a 200 picture. Chunky, for one, only sends credentials after a 401 challenge.

My workaround is a small proxy in front of /pagereader/: it logs into the web side as the same user and serves the page with that session.

Two smaller things I hit while porting a 2.x theme:

- Files served through ?folderinfo= (folder.css, series.json, images) come without a Content-Type. Safari then refuses folder.css ("non CSS MIME types are not allowed in strict mode") and jQuery reads series.json as text.

- Adding any extra query parameter to a ?folderinfo= request (jQuery's cache buster _=...) redirects to the folder page instead of returning the file.

For anyone else hitting these: the OPDS templates load from the classpath under templates/, so a folder placed ahead of the jar (java -cp patchdir:Ubooquity.jar com.ubooquity.Launcher ...) overrides them without modifying the jar.

Happy to test a fix. Thanks again!

Same. Downgrading java worked but that's obviously not a great idea.

Ah I think I know why; I set the audiobook share as /Audiobooks/ and it doesn't like it. Let me see what the usage pattern is here...

Got it. needs "", derp.

Any way to hide the "Files" in the top nav since the only thing there is AudioBooks and now it's blank?

ahhhhhh I can't believe I only saw this now! Amazing work Scott!!

When logging in as 127.0.0.1 everything is fine, but when I come from the outside, I get a spinning throbber and errors in the console. Thoughts?

you mean the publisher layer? What difference are you referring to vis-a-vis the screenshot?

This is always how it has worked for me, making me also keep increasing the number of thumbnails per page to keep Marvel on the first page ;) Not ideal, but you'll notice other CSS elements also don't translate to the following pages. It's not surprising the Featured code applies only to what it sees on the first page.

BTW, I see you have some publisher themes that aren't on the GitHub. Sharing is caring? =]

That sounds great. CLI works for me. And yeah I've actually grabbed assets off comicsblitz before so agree makes sense to futureproof that scenario.

If I had a priori a list of hidden publishers they wouldn't be hidden ;)

This is one of them as an example, but there are many more: https://www.comixology.com/Tesladyne/comics-publisher/4597-0

I think it would be great to just be able to add them as we find them and for the tool to scrape them ad hoc.

re: storage, I put mine on GitHub because someone earlier on the thread asked. They were on my dropbox before that, but gdrive works just as well, I'm happy either way :)

Yep, I remember having to do some manual tweaking for Viper's page too. 

One thing that would be great is to be able to just provide the URL for the "hidden" publisher pages and have it crawl for all the files needed, instead of filling in on the material in the .json file... If I'm filling in all that, might as well just do it myself! :)