[FR] Suggestions from a longtime Tartube user

[Austinzveare]

I've been trying out Pinchflat for about a week now after using Tartube for quite some time and really like how fast I was able to get pretty much everything set how I had it in Tartube (but now automated better), but I have a few specific notes on what needs to be added to make this a full replacement for me.

• The quality selection only goes up to 4K, and while I haven't tested if this can download 8K I would like that option added because I do subscribe to a select few people doing 8K.
• Tartube lets you create an ordered list of quality profiles to download, but something along the lines of "best", involving AV1>VP9>AVC, 4K/8K HDR>4K/8K SDR would be great, as I've had a few 1080p videos download in AVC instead of the preferred VP9, so completely excluding AVC is ideal for me.
• Along the lines of the previous, audio seems to only download in AAC format instead of OPUS, which isn't ideal.
• I don't mind the .MP4 format for the finished file, but maybe give the option for .MKV?
• As someone else suggested a separate working folder would be great because I can see the file(s) going through all the different stages and would prefer that to be done somewhere else and then moved, like the Arr's.
• I'm sure the auto indexing/downloading will be improved, but right now I have ~50 subscription sources added, all with fast indexing, and going by the Discord notifications there seems to be a lot of redownloading even when nothing changes (like AV1 becoming available for example), though I haven't looked to deep at this.

All in all this is a great app that's close to being great, thanks for making it!

[kieraneglin]

Hey there! Thank you for the feedback - I genuinely appreciate it (:

Keep in mind that I edited your commend to break the MKV/working folder point into two distinct points. In order:

• Fair shake on 8k support! I'll add that this week
• Hmmm. I think I like this, but I would want to keep this optional to configure and global in scope (ie: not configurable per-profile or per-source). I'll mull over this and see if I can come up with something I'm happy with!
• I'm hesitant on adding happy-path OPUS support for a few reasons, but the biggest one is that I want the app to take as little config as possible for the largest number of users. iPhones don't support OPUS and I'd contend that the real-world differences between AAC and OPUS are minimal/imperceptible when it comes to content downloaded from YouTube. Given those two factors, AAC seems like a sensible default
  • That said, if I can come up with a good solution for the point on format preferences then I could just do the same for OPUS and y'all can take it from there. No promises for now but I'll give it an honest go some time this week and let you know!
• I'm very keen on forcing MP4 if only for the reason that Plex doesn't support reading MKV metadata. Since Plex doesn't support NFO or other metadata formats (without installing a custom agent), MP4 is a sensible default. I've had this request a few times, but each time I've asked for why MKV is preferred and the answer is always personal preference rather then it causing a limitation within the scope of functionality of this app. I'm open to revisiting this if there's a concrete use-case that's actively affecting people! In the meantime you may be able to use custom yt-dlp options if that's a dealbreaker
• I want a separate "assembly" directory too, but I'm limited by a bug in yt-dlp (See #139). I have a PR for yt-dlp linked that issue if you want to give it a 👍. Once that's merged, I'll add it!
• Fast indexing (or regular indexing for that matter) shouldn't be redownloading at all. Elixir can be hard to parse if you've never worked with it, but you can see here that it only notifies for media items that didn't exist prior. What version of the app are you using? Because this sounds like the issue from #184 (fixed by #187) but that's from several version ago. Let me know!

---

On whole, these are some great suggestions! I don't mean to sound too dismissive in some of them, but it's important for me to keep a tight focus on the vision I had for Pinchflat in the first place. Many other apps end up becoming unmaintainable or near-unusable because enthusiastic and well-meaning maintainers added too many features/customizations/knobs to tweak. Not pointing fingers, just speaking generally since I've been programming for a hot minute and I've seen it MANY times.

I always need to remember that I am but one man working on a passion project in an obscure programming language - I need to be pretty critical of features I take on so that my maintenance burden doesn't become too large to handle.

Anyway, I'm going to work through at least a few of these throughout the week and I'll let you know when/if I add in your suggestions!

[parasiteoflife]

I want to add to this request since opening another one to basically ask for the same is pointless.

I would also like to have an option to choose for MKV, I don't think it would be a problem to add the option keeping MP4 the default.

Also for the other points I would prefer to have an option to add custom arguments, if I go by asking for each argument I use daily I would have to open 20 FR and even then it's too much work for you, would be much better to just have a text area where we can enter additional arguments, for this it would be great to have a checkbox alongside the currently available options so we can set the options to be overriden by the custom args, that way when building the full command pinchflat skips the option we marked because they will be set in the custom args.

You could hide all these configs on the advanced section.

[kieraneglin]

EDIT: marking our comments as duplicate to keep the original thread on-track

---

I would also like to have an option to choose for MKV

I'm interested in hearing the use case and why MP4 isn't sufficient! Like I said, I'm totally open to adding it if there is a good reason but all the responses I've gotten so far boil down to personal preference rather than MP4 providing some sort of technical limitation (or a misunderstanding codecs vs. containers)

Also for the other points I would prefer to have an option to add custom arguments

Custom yt-dlp options should do what you need! (link)

for this it would be great to have a checkbox alongside the currently available options so we can set the options to be overriden by the custom args

This would imply that the app provides support for custom options when it doesn't and, indeed, cannot. The app is very resilient but yt-dlp arguments could absolutely be used in such a way that breaks the app's internal representation of media. That doesn't even mention the yt-dlp bugs I've added workarounds for which the average user could not be expected to accommodate.

The approach for custom yt-dlp options I linked above is very likely the most I'll ever do to support that functionality.

I don't think it would be a problem to add the option keeping MP4 the default

I mean this with all due respect, but deciding whether or not it's a "problem" to add a feature is up to my discretion.

To expand on what I mentioned in my last comment, I am one guy working on a passion project in an obscure programming language (read: intimidating for outside contributors if they don't know Elixir/Erlang). Every time I add a feature, no matter how seemingly inconsequential, I now have to worry about one more thing providing compatibility concerns or impeding refactoring (relevant XKCD). It doesn't matter much in a case-by-case basis, but when you multiply that by all the various functions of an app, it can quickly becomes a support burden unless I carefully weigh each request against a few points:

• Does it solve a problem or is it just personal preference?
• If it solves a problem, is it a common enough use case to justify it?
• If it is common, does that use case align with the goals of the app?
• Even if it solves a common problem in alignment with the app's goals, is implementing that feature prohibitively difficult?
• etc.

If I don't do this the app could easily become bloated, hard to refactor, lose its goal of ease-of-use, and overall inhibit me from continuing to improve it. This isn't a hypothetical - it happens all the time!

---

I know that was a wall of text and I wanted to truly thank you for your suggestions! I don't mean to be harsh but it's important for me to highlight why I'm hesitant to add new features that don't have a clearly articulated benefit

[kieraneglin]

@Austinzveare I've added 8k support and the ability to set codec preferences in #254 and #255 respectively. The latter will also allow you to use OPUS audio. I'll need to do quite a bit of testing around these changes but that should be going up in a release sometime this week!

I'm still curious about the issue you saw with fast indexing - can you confirm it's still happening and also confirm your current app version? Thank you!

[kieraneglin]

254 and #255 are included in the latest release and will be available in ~30 mins 🤙

[Austinzveare]

@kieraneglin Sorry for the late response. Thank you so much for implementing these changes, I just updated and set things how I like and so far so good. Also, I was on the 5.16 build, but I started using this on the 16th and didn't seem to have index issues after the first day, either way It's been doing things correctly since.

[kieraneglin]

Closing this issue since this is as far as I'm going to take these comments for now. Thank you again for your feedback (:

If I missed something please open a new issue!

[kieraneglin]

@Austinzveare heads up that I've had to partially revert the codec selection changes I've added here (see #279). That changed caused a regression that, after checking with the yt-dlp team, would involve a very complicated fix.

The impact is that instead of choosing a list of preferred codecs, you will only be able to choose one

[Austinzveare]

Thanks for letting me know. Ultimately not a huge issue since I only ever get AV1 days after the videos's been uploaded, and by that time I've already watched the VP9 version, so VP9 only is fine with me. What would happen if I selected AV1? Would it just not download anything at all until said AV1 version became available?

[kieraneglin]

Good question! Codec selection is a soft preference, so it'll grab the codec if it's available but it'll fall back to other codecs if yours cannot be found at a given resolution.

If it takes a few days to get the codec you want, you can probably do something with a Media Profile's Redownload Delay

[Austinzveare]

I actually have the redownload delay set to 1 day, it just takes YouTube a few days to get to processing the AV1 version after the VP9 version is live. This is something I hope they improve in the future as AV1 becomes more mainstream.