I have been using Mylar (docker version) now for quite some time and am very happy with it but am also having performance issues (I am an impatient kind of guy ). Right now I am managing 7K series, have 40K issues in Mylar and am looking for around 1.5K missing issues. It could be that I am simply not using Mylar in the most optimized way, but I do a lot of checking/searching for missing issues by hand. For this I use the default view and sort everything by the Have column. But to switch to this view it takes a really long time like 10+ seconds on average. And when going into a comic, do my thing and try to go back to the sorted view by clicking the back button in my browser, Mylar sometimes will do this but also sometime goes back to the default view. Then I have to click the Have column again, wait 10+ seconds again, etc. This makes it very tedious and time consuming.
Mylar is running as a docker on a docker host (Ubuntu) that is running on ProxMox with an Intel i7 and loads of memory. I am guessing it might have something to do with SqLite, but I might be wrong. Is there anything I can do to increase performance or would Mylar need another database engine (which of course is not possible right now) or something completely different?
Hitting the back button on the browser isn't really advised as it will load a cached page instead of a real-time one. In order to go back to the watchlist, you should just click on the mylar logo in the upper left corner so that it loads a clean data set.
As far as the load time, I'm guessing you have the alpha index enabled for the watchlist page (meaning you have the alphabet appearing along the top where you can click on a letter and go directly into those comics beginning with said letter).
You can disable the alpha index on the 2nd page of the configuration in mylar, and in doing so will make mylar uses the dynamic loading for the watchlist page (meaning it will only load what it can display). This will result in much faster load times, but you loose the ability to "jump" to a specific letter. Altho you can use the filter box to subset the list just as easily and even more specifically
SQLite has really nothing to do with this tbh.
As far as your searches, odds are most of your issues you're watching is in tier 2 which comes down to the tier segregation.
Tier 1 = issues in this tier are searched every 6hrs by default using both the api and rss aspects of your providers. They stay in this tier for 14 days unless specified differently.
Tier 2 = issues in this tier are only searched for when rss is initiated. Otherwise they're not searched for unless manually done.
This is because hitting the same indexers for 14 days isn't going to change what they have as it's already searched for the oldest items and the results will never change unless something new is posted.
While this works fine for new issues, older issues that may get reposted via usenet won't get found unless rss is enabled and yes this is done intentionally as hitting a newznabs' api for every wanted issue when the list is large will take forever to run and won't provide any benefit that wouldn't be achieved easier than just enabling rss.
Keep in mind that mylar has to text-based searches so a file with the name 01 will not match to 1 and won't match to 001 so all iterations have to be accounted for as well as various naming differences alloted with the same numbering aspects. Searching for one issue can take a few minutes depending on the numeric issue number and the actual naming of the series.
Thanks for your answer. I forgot to mention that I do the manual part because I can see old comics get posted but are not picked up by Mylar. But I now understand that is because they were moved to tier 2.
I must be doing something wrong but I cannot find the alpha index setting in Mylar anywhere. I am using v0.8.2, python3-dev. Could you show me where it is with a screenshot? Thanks in advance.
I think that setting is in config.ini only, not the UI. If you make changes to config.ini, shut mylar down first as otherwise they will be overwritten.