Have something to say?

Tell us how we could make the product more useful to you.

Have a premium subscription with less throttled /requestdl API calls

Currently the initial jellyfin scan of a rclone (with custom torbox backend) library generate a lot of calls to /requestdl endpoint, which seems to be throttled when requested more than 20 times per minute or something like that. Whereas my calls are already “paced” with a 1sec interval, it is not sufficient to avoid 429 HTTP errors. My rclone backend does cache the final CDN URL (meaning it is not requesting indefinitely the same permalink or requestdl endpoint for same file so I’ve already optimized as much as I can). It would be cool to have “premium API subscription” for power users using API more intensively. I would be willing to pay few more bucks for that. Alternatively, I would be ok to be able to seek in zip files but in your current zipping implementation does not allow that (HTTP partial content is not accepted). Maybe with both solution your server load is an issue, I don’t know. But if in any case you can make either partial content work with zip files (or RAR files) OR less throttled /requestdl API calls (needing a better subscription would be understandable), it would be cool.

Philippe Gaultier about 1 month ago

💡 Feature Request

Real-time data updates with exact numbers and history log

​Hi team, ​Since TorBox now limits outgoing data, users need a more transparent way to check their usage. ​The current updated hourly system makes it very hard to track what is happening. If a media player encounters a bug and accidentally drains a massive amount of data, we wouldn't know until an hour later, which is too late to stop it. ​If the system is truly accurate, please let us see the numbers change in real time on the dashboard, and give us a simple history log showing: ​When the data was used. ​Which file consumed the data. ​Exact numbers instead of rounding: Show us the precise data used (e.g., 29.87 GB) rather than just rounded integers. ​We just want to be able to verify our own usage transparently. Thank you!

jaredleeisthepro about 2 months ago

💡 Feature Request

Feature request: WebVTT sidecar subtitles instead of burn-in

Right now the converter burns subtitles into the video, which means every subtitle track requires a separate re-encode. This is painful for a few reasons: Each subtitle language requires a full re-encode of the same file Switching subtitle language after the fact triggers ANOTHER full video re-encode, just to change the subs. The burn-in encoding is broken for certain languages. Thai renders as [] boxes, clearly not encoded correctly (missing font or wrong encoding). This is a daily issue for me, my partner is Thai Proposed fix: extract the subtitle tracks, convert them to WebVTT and serve them alongside the original source as separate tracks instead of burning them in. Benefits: Single encode per file, not one per subtitle language Switching subtitle language is instant, no re-encoding at all No more rendering issues with non-Latin scripts, the browser/player handles the text with the user's system fonts Much easier to consume via the API in a custom player (just point a element at the VTT URL) Users can toggle subs on/off or switch languages without waiting This would massively simplify the pipeline on your end, save you compute and make the API far more useful for anyone building a custom frontend. Thanks.

Paul 3 months ago

💡 Feature Request

Ability to submit alternative hashes earlier

A common flow is Lookup in indexer Check if any of those items are cached Add item to account, potentially triggering download The problem is that that flow doesn't usually wait for the download to finish and as a result the data from the indexer that would be most useful as an alternative hash is gone by the time it can be added. To give a practical example, Newznab indexers usually have an id that would be basically perfect: guid. The only issue is that I realistically only have the guid at the time of the initial create request. It would still be a huge win even if they didn't get applied until the download completed and it got added to cache even though that wouldn't let me easily identify if I'm already downloading it.

decoupled456 5 months ago

💡 Feature Request