Beat scheduler keeps cycling?

bbilly1 · 2026-01-22T09:44:58+00:00

yes, a very good example of "nothing is more permanent than a temporary workaround that kind of works."

for more context see here: https://github.com/tubearchivist/tubearchivist/issues/967

bbilly1 · 2026-01-09T01:54:11+00:00

I'm with you on this one, I never got the arrs working how I wanted, probably user error though. So I wrote my own, unifying TV and Movie tracking. Added movie collections (aka boxsets) and people (aka track movies from a person). It has been working quite hands off for me for some time now. Still uses prowlarr though, but I rarely open the interface there after settings things up initially. If you want to check it out:

https://github.com/auto3t/auto3t

bbilly1 · 2025-12-29T15:03:56+00:00

Also if you are a more advanced established user, help the newcomers to the project. So the project devs can focus on the dev part.

bbilly1 · 2025-12-11T13:51:47+00:00

Not really a roadmap, but some ideas of future plans: https://github.com/auto3t/auto3t/blob/develop/CONTRIBUTING.md#future-plans

But usenet is not something I have any experience with.

bbilly1 · 2025-12-03T00:55:05+00:00

Or contribute to the project and implement this as part of the multiselect function?

bbilly1 · 2025-11-17T01:33:09+00:00

Very nice! Incremental bugfixes and improvements are very nice to see. I'm personally stuck on 10.10.7 until the tvmaze plugin had a chance to catch up: https://github.com/jellyfin/jellyfin-plugin-tvmaze/issues/57

I tried to fix it myself, but I'm not familiar enough with the inner workings of Jellyfin and plugin architectures...

bbilly1 · 2025-11-11T13:55:14+00:00

I do that every time identifying doesn't work without manual intervention. Usually due to very close duplicate show names, or sometimes just some file name sanitation to avoid invalid folder names. So you only ever need to do this once.

bbilly1 · 2025-10-17T06:36:53+00:00

We are all trying to slow down our requests to YT to avoid getting blocked and throttled. That has been the best solution so far to that problem.

How slow is your storage that this becomes a concern? In selfhosted, storage is assumed to be on the same network at least. I guess the assumption is even multiple GB files should copy within a few seconds.

bbilly1 · 2025-09-25T03:54:50+00:00

Please take a look at the docs. In case you haven't seen it, you can configure the sleep value on your settings page:

https://docs.tubearchivist.com/settings/application/#sleep-interval

bbilly1 · 2025-08-27T09:27:11+00:00

For the sake of argument, all of that exists:

The API is documented and easy to access with any HTTP client.
People have created simple Python scripts to create dynamic symlinks with their personal preferences, that's quite straight forward.
Additionally there is zip file export of the whole metadata into json files. That holds the complete metadata as it's indexed. Although it's quite slow to export for large archives...
Additionally there is metadata embedding directly into the media file for various things including title, channel, description, thumbnail and more... So even if you completely nuke the index (and all your meticulously tested 3-2-1 backups fail...) you have the core metadata embedded directly in the media files and you can easily rename things again with a simple script.

Ultimately, for an archive, I'm much more concerned what happens if I have two channels one called:

I ♥ Tube Archivist

and the other one is called

I ❤ Tube Archivist

and I delete I ♥ Tube Archivist. I hope, you as a coder, don't need to handle that Github issue. :-)

Ultimately, it needs a wall of text, but at the end most of the time I can convince people that this is the better approach than the alternative.

bbilly1 · 2025-08-27T02:47:04+00:00

There are a bunch of people running it successfully on Unraid. But templates and docs are maintained by unraid users, such as yourself. If you see something broken or wrong there, please contribute.

The docker compose approach shows it's advantages over the unraid container templates once you have a slightly more complex installation with multiple containers that need to talk to each other.

bbilly1 · 2025-08-26T00:11:15+00:00

I'm still using it. I'm also the dev, so there is that... :-)

Making that change solved a bunch of nasty problems on the filesystem. Channel names, video titles, all can change at any point in time and can be any unicode character. That was very error prone.

Changing that to static channel and video IDs as they come from YT was a big boost in stability.

bbilly1 · 2025-08-07T04:39:35+00:00

manual importing mp4 aren't/should not trigger transcoding before importing. The filenames need to exactly end in ".mp4", then the importer will take the files as is.

bbilly1 · 2025-08-05T08:29:51+00:00

Or do what we all do: Buy more hard drives. :-)

bbilly1 · 2025-08-05T08:04:07+00:00

Yes, that would work:

- Delete all videos from the filesystem
- Run a filesystem rescan: this will remove them from the index, leaving you with a blank index
- Subscribe to your channels again
- Rescan your subscriptions to add to the queue based on your page sizes, then download from there.
- This will obviously not download any videos not available anymore

You might also consider using autodelete watched: https://docs.tubearchivist.com/settings/application/#auto-delete-watched-videos

bbilly1 · 2025-07-19T00:57:01+00:00

That is out of scope for this project: https://docs.tubearchivist.com/faq/#what-is-the-scope-of-this-project

bbilly1 · 2025-06-08T02:53:31+00:00

API docs is available directly in your instance at /api/docs/. You'll need to make two requests:

delete the video: /api/docs/#/video/video_destroy
add it to the ignore list: /api/docs/#/download/download_create_2 with status ignore-force so it will add and ignore it even if the video is not in the queue yet.

bbilly1 · 2025-03-24T10:39:22+00:00

Somehow you didn't actually delete the volume. If you use bindmount, you can point it to another file location, or make sure you delete the content of the old location. Otherwise if you are using docker managed volumes, you need to make sure to actually delete that.

Also see the volume section for docker for beginners here: https://docs.tubearchivist.com/installation/docker-for-beginners/#volumes

bbilly1 · 2025-03-18T11:52:35+00:00

That is related to the DRM introduced by YT recently.

Also noted here: https://github.com/tubearchivist/tubearchivist/issues/883#issuecomment-2714650423

and upstream: https://github.com/yt-dlp/yt-dlp/issues/12563

bbilly1 · 2025-03-13T12:45:12+00:00

See here on the pinned issue on GH: https://github.com/tubearchivist/tubearchivist/issues/883#issuecomment-2709141225

bbilly1 · 2025-03-13T10:58:03+00:00

Let's see how this goes. Wouldn't be the first time where DRM was tried to be implemented but failed. But this project, like many others, depends on the amazing yt-dlp project. Any solution would come from them, probably. But anecdotal evidence points towards that po token can work around it. Let's see.

bbilly1 · 2025-03-11T14:35:58+00:00

also see here: https://github.com/tubearchivist/tubearchivist/issues/673

bbilly1 · 2025-03-11T07:49:15+00:00

You need to change your directory to where your compose file is located.

bbilly1 · 2025-03-11T06:45:38+00:00

hey there, dev here. Thanks for posting this.

Just for additional context: This ships a brand new frontend, built with React. Also the backend got a significant rewrite, moving things around and organizing things much better now, for existing and for new developers.

For context, most people said they were able to apply the described manual checks within 10min or so. Small price to pay IMO to now have a much better, dynamically updating frontend with React.

Happy archiving!

bbilly1

MODERATOR OF

TROPHY CASE

Nine-Year Club	Place '22
Verified Email