- General
-
Ideas
+16
Planned
write read states to metadata files (comic and books alike)
wish that Ubooquity saved the read state of the comics/books we read into the metadata files itself. that way we will always be in sync with ComicRack and such as read states would cross over, if you read something in CR it will reflect in Ubooquity and vice versa (mainly this one for my usage)
would be great to be able to read whatever with Ubooquity when you are on the move and dont have access to CR freely and the read states would be saved in the cbz files we have so when we return to CR or whatever place we choose to read more it will know our read state.
your server program can already read CR supported metadata, why not read states and let it update read states aswell for us.
just started to use your program and i love it so far as it just opens up the sharing in a much easier way than CR does it.
would be great to be able to read whatever with Ubooquity when you are on the move and dont have access to CR freely and the read states would be saved in the cbz files we have so when we return to CR or whatever place we choose to read more it will know our read state.
your server program can already read CR supported metadata, why not read states and let it update read states aswell for us.
just started to use your program and i love it so far as it just opens up the sharing in a much easier way than CR does it.
Customer support service by UserEcho
So modifying comics metadata is not an option.
However, keeping the unred/read state of a given book in the database (as well as the current page number for comics read using the online reader) is something that can be done (and already requested a few times).
So why not.
I don't know if the server-sync'd read state is coming soon or not, but do you think it could also be added in your OPDS page streaming extension ? to get the last page I think it would be pretty easy, something like pse:current="x" in <link> section. Tricky part (maybe not :)) is to push back the new current page to ubooquity.
POST /opds-comics/readstate/{comicID} (data var: current={currentPage}, force=[null|yes])
Without "force" argument, server would decided whether or not the state needs to be updated.
With "force" argument, server would update no matter what (that way OPDS client can allow any user to rollback to any page)
We also need to have the ability to check current readstate for any comic :
GET /opds-comics/readstate/{comicID}
That way when you resume your OPDS client with a comic already open, we can check if user have read any pages with another client/browser, and prompt him to go to that page or not.
Maybe you already thought of all this, anyway, what do you think ?
And since It's my first comment here, I'd like to thank you for all your work !
I have not put much thoughts in the way I'll implement it yet, but the reader integration in the OPDS feeds simply consists in providing the OPDS client with a template link to get comic images.
So when server-sync is implemented, it will very probably work the same whether you open comics through the usual web page or through the OPDS feed.
Hi Tom,
I was wondering is it possible to have a sort of *.txt or *.conf or whatever file, so when you using webinterface change the status of a book to "read" that the name is being put in this text file or so. So Ubooquity scans that text file and every book who is named in that text file gets a "read" icon or something like that. Or maybe could that be very sluggish and slow? I'm just giving you my two cent because you said you haven't put much thoughts in it how to implement it. This could also be very handy when you migrate/upgrade your server, you just have to take that file where all those books have been named that one has read. After migration/upgrade everything is back as how it was.
What ever you do, i really appreciate this wonderful piece of software. Good job.
He never really discusses implementation, but even so ubooquity has an internal database of everything. So why use an external file? Also, in your case, it would work well for a single user. Some people share their collections with tons of people, read status needs to be tracked per user... The simplest would be a table/datastruture that simply contains a userId, comic/bookId, and a boolean for whether read or not... The harder part is the read icon and then integrating it into the OPDS.
Server side bookmarks (allowing you to resume reading on a different device) are still planned and are quite high on my todo list.
Read/unread flag will be a side effect of this development.
You can expect it this year.
I did not knew that it had a internal database. You are indeed right that some people share their collection with tons of people and read status needs to be tracked per use. I just gave my two cents with my limited understanding of it.
In the end of my comment i also stated "What ever you do...". So it was not like as if my was the only way ;).
However thank you for your reply and educating me on certain things that i did not know or thought about.
A read/unread state and current location in book are literally the last features I wish for out of your app. Otherwise, it's nearly perfect. All I want is something that can actually stream comics to a device, so that I can pick up on another one if needed. I look forward to seeing this feature implemented.
would love for an update on this.
and maybe we all should vote over on the League of Comic Geeks site aswell (its kinda like trakt for comics in a way) we need more votes on the api and get their dev to step it up ;)
combination with their site, api and ubooquity you can stay in sync no matter where you are :D
https://leagueofcomicgeeks.uservoice.com/forums/213333-feature-requests/suggestions/6893699-api-access
even without something like that, doing it all locally on the server is a nice step to the right way :)
having a way for apps like Chunky to read the read states would be amazing aswell.
the Chunky dev has always be great and supportive before so im sure he will get too it if you make such a system.
Synchronized bookmarks (which includes unread/read state synchronization) is still planned for the next release.
I still have to begin working on it though (been lost in HTTP server and web UI rewriting the past few months).
That's great to know. Will you be providing an API for external apps to update read states as well? Or will that be planned for a release after the next one?
I had not thought about providing a synchronization API. But that's a good idea.
Noted (no planned date though).
an api would open stuff up Aton tho. I bet we can get some of the devs of the Readers out there to add support for it. I'm sure atleast the chunkycomicreader dev would support it. That's one os. Would need to be able to request and load all metadata. Heck a comic rack plugin could be made aswell if needed.
Just think an api is the way to go in the long run.
Wouldn't it be great to have apps like chunky load all the comics in they own ui? It would be a lot less limiting in general.
Well I'm personally working on a reader with Ubooquity support a key feature for Windows/UWP right now which is why I asked in the first place :D. After it's done I plan on porting it to other platforms.
Is the UI rewrite more backend stuff, or should we be braced for broken themes?
The UI rewrite will only impact administration UI (the desktop GUI and the web admin page).
The only modification that will impact themes is the potential addition of a new "mark as read" button. Nothing too big.
Is there any update on where this is on the road map? This would almost perfect ubooquity for me
Tom has said HERE that he doesn't want to give any more estimations on releases, since they change so much. BUT, this is the feature he's currently working on and then releasing V2.0! =D
Ah perfect thank you I completely understand. I am in the software world myself.