Home Artists Posts Import Register

Content

Hello!


A big welcome to all the supporters who have joined over the last few weeks. Over 150 pledgers is a big milestone!


Just an update to say that last week I started working on Tdarr again. I've had a think about the best changes to make going forward - the most significant application gripes/hindrances for me are the following:

1.Needing a separate database (MongoDB).  This is quite annoying if you're not using Docker and can be confusing for new or non-technical users. MongoDB isn't great for distributed applications, especially given all the OSs/devices that people are trying to run Tdarr on. This is obvious in hindsight, but the reason I went with MongoDB is that the framework (more on that next) Tdarr uses has all sorts of MongoDB features/functions built-in. Over the past year, there have been plenty of DB errors reported due to settings/configs out of my control so it would best to use an embedded database (one that comes directly in Tdarr's code)  resulting in easier setup and debugging.

2.The framework (MeteorJS). I went with this framework it has plenty of really useful features such as combining server and client development into one, a MongoDB tracker and 'Meteor.call' methods which remove the need for API endpoints. However, there have been issues such as:

- The constant 'fibers' errors users have reported due to having the wrong NodeJS version installed (Meteor currently runs on Node 12.x)

- Bugs when trying to auto-build Meteor Windows packages using GitHub Actions.

- Sluggishness, especially with Tdarr's UI as the client and server are so tied together. This is especially evident when starting up Tdarr with a large library as the UI hangs/fails. Meteor also takes a good minute to start up in development (this adds up when restarting often) and building packages locally sometimes takes 10+ minutes which isn't ideal. I also only make use of a few features of the framework so it feels like there is a lot of unnecessary overhead.

- Other random bugs such as the recent UI bug in the Nightly for some people when trying to load the stats graphs. The bug seems to be related to the screen being used and is completely unreproducible by me (I've tried on 4 different screens). The error of 'meteor_js_resource=true:129

69ed31e05308055b33bf3e21fda1c4c4981fb7b8.js:42:83125' hasn't been too helpful.

I'm not trying to bash Meteor and I'm sure someone over at Meteor would have all the answers but I'd prefer to have to put a bit more work in upfront and be more in control. While I'm not 100% certain the bugs mentioned are directly to do with Meteor, I'd like to remove the possibility.

3. No desktop applications. Moving away from Meteor opens up the possibility of some Windows, Linux and MacOS apps similar to my other application, HBBatchBeast. No guarantees/timeframes on that though as it's still a lot of work.

So with that in mind, I've been working on breaking down Tdarr into its core components so there'll be a distinct server (Express) and client (React). Starting up Tdarr will still be done through a Node terminal command which will run both concurrently unless you're using Docker where you don't have to deal with that. Usage will be the same.

According to Git, I've already done 3,345 additions and 1,869 deletions, redoing the front-end and several hundred server/client sections so that a new database can be used. I currently have Tdarr running on a new DB (LowDB) and I'll be testing things out on that this week. The neat part is I've simplified DB interfacing into a 10 function DB handler (i.e. 'getAll', 'insert' etc) which all of Tdarr's 255 DB interactions now point to. This makes it easy to swap in any document/JSON based database (or potentially others with more work). Next up is implementing API endpoints (redoing 330+ 'Meteor.call' functions. Fun times...).

While doing all of this work may not make much practical difference to how Tdarr works for myself and many others, hopefully, it will help with plenty of the aforementioned issues and also make development more enjoyable. I'll update you when I'm close to a release (2-3 weeks).


Thanks for supporting the project!

HGG

Comments

Carlos Hartmann

Hey I'm a new backer but my machine runs on Armbian and that doesn't support Tdarr unfortunately. I have no idea how much work it would be to get Tdarr working on Armbian but I'll gladly remain a backer if you say that Armbian support could be done soonish.

James Smith

There's a discussion on that at https://github.com/HaveAGitGat/Tdarr/issues/110, there are a few people thinking it'll be an increasingly in demand option especially with Apple's new M1 silicon.

Andy Womsley

Thanks for the update - having been through a simlar process myself I understand your pain! Keep up the good work.

Tdarr

Yeah it’s a good learning experience for sure. Thanks!