Heh I don’t mind - honestly, I always welcome feedback on the infrastructure. You’re right. It’s definitely less robust from a purely server infrastructure perspective as now i’m adding another potential failure with Elastic.co’s service.
However, elastic.co has a lot better performance measures and alerting services out of the box compared to OpenSearch, which you have to configure yourself through Cloudwatch. And generally, I was hopeful that using Elasticsearch vs OpenSearch would be a bit better, as it seems to have more active development.
Frequently, in the past with OpenSearch, search would just stop working and I was at a loss why. Whether it was a memory issue or CPU issue or configuration issue… I struggled to figure it out.
So far with Elastic.co, when I have had issues it’s been pretty clear what the problem has been… until this outage!
Edit: They actually do email support for the basic subscription, which has helped me in the past. And I’ve also been able to deploy a smaller cluster than on OpenSearch with less issues… not entirely sure why.
I set a reminder for myself to reply to this and then still didn’t Whoops.
Anyways, since it’s veering off topic:
Elastic search stuff
I don’t actually use Elasticsearch at my current job but I extensively use AWS and am 0% surprised that you have to set up your own monitoring and that the UI was less than intuitive. I suppose I was mostly curious what drew people to the competition, having never used it and those are valid reasons. I suspect there may be more tilt towards AWS on a cost or configuration basis if someone has the time and support to accommodate that, but a more ‘out of the box’ solution for a one-person-company makes perfect sense to me.
Right, it’s absolutely cheaper to setup your own ElasticSearch cluster on AWS (without using OpenSearch), which isn’t terribly hard to do. But for all the reasons you stated, yeah as a one person team doesn’t make much sense. And, in any case, we got elastic search costs to around $40 a month now, which I think is pretty reasonable
Also, as an aside… speaking of configuring your own alerts and whatnot for AWS, can I just say CloudWatch is stupidly expensive? Like I had very few metrics & streams going and it already was above $60 a month. I ended up using NewRelic which is amazing, with tons of great out of the box monitoring and alerts… for $50 a month. CloudWatch pricing is pretty shocking tbh.
Monitoring can easily spiral out of control re: spend. I’ve never used NewRelic but I currently am using DataDog and oh my is that a beast to keep the spend under control. We barely use Cloudwatch but that’s less for price reasons and more because Cloudwatch is a pain and we want something the devs will actually look at and interact with.
For me that title always goes to Redshift Although we do have a shameful S3 bill that I won’t go into detail about on a public forum, but I’ll just say: store things in a manner in which you can set up sane lifecycle rules and you’ll save a lot of money!
We’ve moved TV Progress tracking to focus on ‘Finished Episodes’. This means by default you start at 0 episodes watched. There’s also a small ‘+’ sign for quick incrementing the episodes watched.
You’ll notice now too that the ‘update progress’ form only shows a ‘finished epsisode’ field. After some discussion with everyone, I think this will probably be more intuitive. If you’d like to mark partial episodes, you still can though! Just have to click ‘mark partial episode’.
One final note! Before this update, we encouraged you to set your current location to the episode you were about to watch with a minute = 0. So if you had watched episode 1, we encouraged you to set the location to episode 2 minute 0.
However, we’ve automatically moved those location back to the previous episode with minute equal to the runtime for that episode. So, back to our example, if there were 24 mins in episode 1, your ‘location’ now would have been automatically updated to episode 1 minute 24, not episode 2 minute 0.
If your location was not at minute 0, do not be concerned - the location would not be touched by this auto update.
What exactly do you mean by redundant information? Agreed though, that error is a bit-non specific. Should say that the time spent needs to be greater than zero.
I could add a field for time spent there too, hmm. I was thinking we only have time data on the ‘update progress’ form, but i understand that people like simply using the episode UI too. I’ll think on it. As i’m back working on the data manager now, this impacts that as well.
The time spent if I start on min 0 and go to min 25 is already known, putting that I spent 25 minutes is redundant, unless there’s a scenario where someone might be watching at 0.5x or 2x speed. Is that a thing?
Is just that if it can’t be done there, I’d change the input field for normal text, and maybe a tooltip saying where to update it. A disabled input field makes you think you are doing something wrong, or that something is not working properly.
This is still a bit awkward. I went to mark episode 8 of Oshi no Ko as watched (I forgot to update it when I actually watched it). It says my current location is episode 7, 25 minutes. I change to episode 8 and then it notes that episode 8 was 24 minutes, but the minutes input still said 25. Do I really have to specify the end minutes manually? That’s from the Basic Info view. Should I be using the Progress Update view instead?
So I had a question for you @brandon: let’s say I start book A in January, read 30 pages, record it, then put the book down until May. I want to start the book over from the beginning, but preferably I’d like to keep the fact that I did 30 pages of reading in January noted in the system. Is that possible with the current setup? If I set the pages read from 30 → 0, then back to 30 after I start reading again, does Natively still know about those original 30 pages?
While that 30 pages will no longer be counted towards your stats (we do not double count) , we do maintain that ‘reading session’ in storage. Even if you were to delete that reading session (say in the new data manager i’m working on), we still have multiple ways to get at the information… we store a log of every update you do to a book in your library and we keep every activity generated, even if deleted (except in the case of a user account deletion). All of which would allow us to reconstruct past sessions.
So, your data does have a lot of redundancy if that’s what you’re worried about. If you’re more wondering about if you could access obsolete data once I implement rereads, yes you could. Although if it’s the latter, I would recommend not deleting the obsolete session once the data manager rolls out, simply for ease of use for everyone
I regularly skip OP/EDs fwiw, which shaves about 3 min off. I assume I’m not the only one so that’s another potential use case. Not sure I care about being that specific, but it is the difference between 3,100 and 2,800 minutes watched (or 31k vs 28k) over time
In case you’re wondering, I changed my mind on using the Owned list as a way to track availability and decided to use Wish List for everything with custom lists to indicate how to watch it. But I can’t set the custom lists on movies because of this bug.
Also, how are custom lists ordered? Since there’s no way to order them manually I’d expect them to be alphabetical, but mine just flipped order for no apparent reason…