Welcome, Guest
General discussion about ComicRack

TOPIC: Is comicrack dead?

Is comicrack dead? 9 months 1 week ago #48813

  • perezmu
  • perezmu's Avatar
  • Offline
  • Platinum Boarder
  • Posts: 1135
  • Thank you received: 64
  • Karma: 51
Thanks, I will give it a try!
The administrator has disabled public write access.

Is comicrack dead? 9 months 1 week ago #48825

  • krandor
  • krandor's Avatar
  • Offline
  • Gold Boarder
  • Posts: 313
  • Thank you received: 34
  • Karma: 5
kino13 wrote:
I think I used this:
comicrack.cyolito.com/dokuwiki/doku.php?...ng_a_shared_database

You need to have the mysql installed already.

I am managing 105000 Comics at the moment, I can assure you it it waaaay faster than xml.

I second this. I have a huge library and the move to SQL was great. It also helped in that now my DB is on my NAS (run mysql on my synology) so if my hard drive crashes I won't lose the whole DB (just smartlists and the like).
The administrator has disabled public write access.

Is comicrack dead? 9 months 1 week ago #48845

  • nfp1971
  • nfp1971's Avatar
  • Offline
  • Fresh Boarder
  • Posts: 13
  • Thank you received: 6
  • Karma: 0
Hi, first things first.

Thank you to Cyo an all the other developers who took their time coding this program and its extension/scripts.
Now thatcomicrack is dead, how should we move forward. Can anyone make a poll in here or elsewhere as to users casting their votes on a comicrack successor?
I'm starting to have issues using Comicrack, mainly it says many of my files are missing or corrupt, and they are not. with this is mind i started looking for alternatives.
First considered option is the obvious choice of calibre (i'm trying not to go this way), i use calibre to mange my ebooks/magazine pdfs. It's feature rich rich but also very heavy on resources (i have about +-30000 files and editing one book always takes more time than i think is resonable, the spining wheel in macos keeps poping up), of courese doing this in my +- 110000 comic files would make go mad. As such i'm trying not to use calibre.
Afterwards i discovered YACReader, i'm trying to use it but it still lacks many features. YAC it basically a 2 man coding effort, im pretty sure they would appreciate coders joining them into turning that project a flagship one.
i've recently found mcpierce/comixed, Have yet to install it.

Anyone has other good alternatives, can you share?

I'm using macOS (comicrack in w10 vm) and for reading purposes i use ChunkyComic Reader in ipad. I bought Cover from FrenchFry (windows only) and tested in w10 vm, would love to use Cover in macos as it seems pretty good.

Suggestions welcomed.

Thank you for reading my message.
Last Edit: 9 months 1 week ago by nfp1971. Reason: bad spelling on my part
The administrator has disabled public write access.

Is comicrack dead? 9 months 6 days ago #48856

  • Xelloss
  • Xelloss's Avatar
  • Offline
  • Platinum Boarder
  • Posts: 596
  • Thank you received: 150
  • Karma: 30
krandor wrote:
kino13 wrote:
I think I used this:
comicrack.cyolito.com/dokuwiki/doku.php?...ng_a_shared_database

You need to have the mysql installed already.

I am managing 105000 Comics at the moment, I can assure you it it waaaay faster than xml.

I second this. I have a huge library and the move to SQL was great. It also helped in that now my DB is on my NAS (run mysql on my synology) so if my hard drive crashes I won't lose the whole DB (just smartlists and the like).

Passing to SQL comic database was the best decision I made.... It is almost a year now, and It is SO much better... and stable... It is a real pitty it was never correctly finished... (CR use SQL only partially)

CR is really the best piece of software I have ever used in my entire life, and it is a real pitty it is not updated anymore. Of course I don't blame Cyo for that, he moved on with his life, it would happen sooner or later, and he gave SO MUCH to the program already... But it would be just great that if he is not planning in working in it anymore he just releases the code and make it an open source project... That was my birthday wish this year (???) hahahaha There are so many people in this forum that would continue developing it... I would be one of them :)
Last Edit: 9 months 6 days ago by Xelloss.
The administrator has disabled public write access.

Is comicrack dead? 9 months 6 days ago #48860

  • perezmu
  • perezmu's Avatar
  • Offline
  • Platinum Boarder
  • Posts: 1135
  • Thank you received: 64
  • Karma: 51
Thanks,

I have a question, though... Will CR copy my existing xml database on the new mysql database, or do I have to re-import all comicbooks to the new database...
The administrator has disabled public write access.

Is comicrack dead? 9 months 6 days ago #48861

  • Xelloss
  • Xelloss's Avatar
  • Offline
  • Platinum Boarder
  • Posts: 596
  • Thank you received: 150
  • Karma: 30
If you follow the tutorial that is somewhere out there (?) as I did... the first time you run CR with the new configuration it will export everything to your new sql database automatically... and clean your xml from that data...

Remember the xml will still be used for smart lists and comicrack configurations... so it will be GREATLY reduced in size, but not erased...

All the same I recommend to make a backup of the xml just in case it doesn't work... as it will modified both, your xml and your sql database when the migration is done...
Last Edit: 9 months 6 days ago by Xelloss.
The administrator has disabled public write access.

Is comicrack dead? 9 months 5 days ago #48865

  • fieldhouse
  • fieldhouse's Avatar
  • Offline
  • Expert Boarder
  • Posts: 96
  • Thank you received: 10
  • Karma: 1
Same story here. I had to jump to using a database instead of xml just out of necessity. I later had to move mysql off of my Synology NAS since it was too slow and queries were timing out. Now that mysql is backed by an SSD and has a couple hundred megs to play with my only complaint is the memory usage on the client side. I just checked and ComicRack us using ~ 4GB RAM. I'm sure that's partly my fault for loading up plugins, etc. and I'm sure >600k files isn't helping either.
The administrator has disabled public write access.

Is comicrack dead? 9 months 5 days ago #48867

  • pueblo
  • pueblo's Avatar
  • Offline
  • Junior Boarder
  • Posts: 30
  • Thank you received: 3
  • Karma: 0
Did anyone made any benchmark before/after migration to sql?
Some time ago I've tested it on my old database (~60k files) and didn't see any improvements in query execution time (both ComicDb.xml and sql file were on ssd drive).
Based on what I read, ComicRack is reading whole db to memory and then operates on it. It explains why CR is taking so much RAM.
I just don't see any reason why SQL would made query run faster if it is treated solely as a 'storage'.
Could anyone explain this to me? :)

From old thread, by cYo:
comicrack.cyolito.com/forum/32-news-and-...eased?start=50#31804
cYo wrote:
It makes no sense for ComicRack to split comics up into a "proper" table based schema.
I treat the SQL server as an object database.

Just a few points:
* ComicRack has it's own sophisticated query language that is not simply translatable into SQL queries. So breaking objects up in tables/columns gives me nothing.
* ComicRack uses an in memory approach which gives you all the nice features like live counters and live updates
* Comics are like they should in an object database: "atomic" and always consistent

To say the only advantage is "shutdown does not take so long any more" is a little bit short sighted.

A lists of advantages:
* Data is immediately stored and updated into the store
* Data Integrity is guaranteed
* Databases are shareable between multiple users/machines with live updates. Try the following: Connect to the same database from 2 computers and change/scrape/add comics on one machine and look what happens on the other machine without you hitting refresh, reload or whatever you usually do.
* Shutdowns are faster

Or something has changed and this statement is depreciated?
The administrator has disabled public write access.

Is comicrack dead? 9 months 5 days ago #48869

  • fieldhouse
  • fieldhouse's Avatar
  • Offline
  • Expert Boarder
  • Posts: 96
  • Thank you received: 10
  • Karma: 1
You are correct that ComicRack isn't using a table-based schema and there are definitely better choices than MySQL or MS SQL for serving up an Object Oriented Database.

Each book record is a single table entry with all the info jammed into a column named "Data".
Just look at this single entry to see how much stuff is jammed into a container several sizes too small. (single line wrapped for sanity):
'0004495d-0098-44a0-802a-78253d798799', '4472917', 
'<ComicBook Id=\"0004495d-0098-44a0-802a-78253d798799\" 
File=\"....DC Comics - Bombshells 078 (2017) (Digital) (BlackManta-Empire).cbr\">
<Title>All Good Things Part 3 of 3</Title>
<Series>DC Comics Bombshells</Series>
<Number>78</Number>
<Volume>2015</Volume>
<Summary>Steve Trevor accompanies Supergirl on a train back home to Russia, where she still has hopes of rescuing her father. 
During the ride, the two unexpectedly meet Alexander Luthor, who offers Supergirl an unusual glowing green rock.</Summary>
<Notes>Scraped metadata from ComicVine [CVDB576260].</Notes>
<Year>2017</Year>
<Month>1</Month>
<Writer>Marguerite Bennett</Writer>
<Penciller>Mirka Andolfo</Penciller>
<Inker>Mirka Andolfo</Inker>
<Colorist>J. Nanjan</Colorist>
<Letterer>Wes Abbott</Letterer>
<CoverArtist>Ant Lucia</CoverArtist>
<Editor>Jessica Chen</Editor>
<Publisher>DC Comics</Publisher>
<Web>http://comicvine.gamespot.com/dc-comics-bombshells-78-all-good-things-part-3-of-/4000-576260/</Web>
<PageCount>24</PageCount>
<Characters>Alex Luthor, Steve Trevor, Supergirl</Characters>
<Pages>
<Page Image=\"0\" ImageWidth=\"1650\" ImageHeight=\"1268\" Type=\"FrontCover\" />
<Page Image=\"1\" ImageWidth=\"1650\" ImageHeight=\"1268\" /></Pages>
<Added>2017-01-21T11:33:56.1044922-08:00</Added>
<Released>2017-01-13T00:00:00</Released>
<ComicInfoIsDirty>true</ComicInfoIsDirty>
<FileSize>15799581</FileSize>
<FileModifiedTime>2017-01-21T00:13:48Z</FileModifiedTime>
<FileCreationTime>2017-01-21T02:43:09.3926975Z</FileCreationTime>
<CustomValuesStore>,comicvine_issue=576260,comicvine_volume=83493</CustomValuesStore>
</ComicBook>'

Every time ComicRack starts it scans the entire database. Currently this takes ~14 seconds just to run the query on my system and it's a couple minutes before everything's loaded into memory so I start it up and go grab a cup of coffee while I wait.
select update_counter, data from comicdb.comics limit 0, 9999999	759845 row(s) returned	0.000 sec / 13.860 sec

However, raw speed is only one aspect. The stability of the app is much better with most of the info stored in a transactional database. My current database is 1.2 GB. I was having xml corruption issues on a regular basis when the data size was 1/10 of what I have now. It seemed like i was playing Russian Roulette every time I opened ComicRack, hoping it wouldn't crash and, knowing that if it did, chances were high that I'd be restoring a backup copy of the xml file. Now if CR crashes, I just have to start it back up (and go grab another cup of coffee).
The administrator has disabled public write access.

Is comicrack dead? 9 months 5 days ago #48870

  • krandor
  • krandor's Avatar
  • Offline
  • Gold Boarder
  • Posts: 313
  • Thank you received: 34
  • Karma: 5
pueblo wrote:
Did anyone made any benchmark before/after migration to sql?
Some time ago I've tested it on my old database (~60k files) and didn't see any improvements in query execution time (both ComicDb.xml and sql file were on ssd drive).
Based on what I read, ComicRack is reading whole db to memory and then operates on it. It explains why CR is taking so much RAM.
I just don't see any reason why SQL would made query run faster if it is treated solely as a 'storage'.
Could anyone explain this to me? :)

From old thread, by cYo:
comicrack.cyolito.com/forum/32-news-and-...eased?start=50#31804
cYo wrote:
It makes no sense for ComicRack to split comics up into a "proper" table based schema.
I treat the SQL server as an object database.

Just a few points:
* ComicRack has it's own sophisticated query language that is not simply translatable into SQL queries. So breaking objects up in tables/columns gives me nothing.
* ComicRack uses an in memory approach which gives you all the nice features like live counters and live updates
* Comics are like they should in an object database: "atomic" and always consistent

To say the only advantage is "shutdown does not take so long any more" is a little bit short sighted.

A lists of advantages:
* Data is immediately stored and updated into the store
* Data Integrity is guaranteed
* Databases are shareable between multiple users/machines with live updates. Try the following: Connect to the same database from 2 computers and change/scrape/add comics on one machine and look what happens on the other machine without you hitting refresh, reload or whatever you usually do.
* Shutdowns are faster

Or something has changed and this statement is depreciated?

Before moving to SQL I had to make backup copies of my xml file very often because I had more then a few get corrupt on me which was not fun. I also on SQL love the fact that changes take affect immediatly. Nothin more frustratin then scraping a few thousand comics and then CR crash or lock up and lose all that information.
The administrator has disabled public write access.
Time to create page: 0.226 seconds

Who's Online

We have 115 guests and one member online