A way to organize, display & browse a recipe files (PDFs) would be a nice feature

[RLanger7228 54]

I have an extensive recipe collection (literally thousands).  I currently share it with my family & friends by sharing a view-only collaboration link for the main sub-folder in the Public folder of my iCloud Drive (screenshot).  While this works for me, it would be nice to be able to include them in Emby, which is a much easier & user friendly interface that works better across platforms.

I imagine this would be a subset of BOOKS, since the individual recipe files would function in the same way.  The easiest way I found to organize them is by folder & sub-folder, then additionally organized by tags (for holidays, particular ingredients, etc), to simplify searching & browsing, also allowing cross-referencing (e.g. chicken recipes for Easter, etc).

A quick-view feature to allow a user to "glance" at a recipe file before downloading would also be helpful, as would a way to keep it separate from books (or a separate subset of books), so It can be browsed separately, though I suppose browsing by FOLDER could accomplish that, even if less intuitive.

I have heard that new BOOK features are being considered for future Emby updates, so I wanted to add this to the considerations.

 

I am curious if there are enough other users that also share this interest to justify the effort to make recipe-specific features, otherwise folder & tag organization can work well enough.

[seanbuff 1113]

1 hour ago, RLanger7228 said:

I am curious if there are enough other users that also share this interest to justify the effort to make recipe-specific features, otherwise folder & tag organization can work well enough.

For me personally, I think this ventures far outside the scope of what Emby is intended for. 

You might have a better experience using something for which this use case is designed for like Mealie

https://mealie.io/

[RLanger7228 54]

14 hours ago, seanbuff said:

For me personally, I think this ventures far outside the scope of what Emby is intended for. 

Emby is intended to share content with a group of users.  Having E-books/PDFs as part of that offering would easily allow the sharing of recipes as well, using already existing features.  For me, I would like to be able share all my content using a single user-friendly,  cross-platform app like Emby.

I can understand that the implementation of topic-specific features requires time, effort (and salary) for programmers to create & maintain, not to mention extra space on user's systems to store the coding and resource usage, etc.  It certainly would not make sense to make these investments unless there were a broad interest among Emby subscribers for such features.  This IS a public forum, and users should post their interest (if there is any).  It may surprise all of us, though I suspect this is probably a "niche interest" and may not get as much support as I hope.  

It occurs to me that to allow selective implementation of recipe-specific features, Emby could offer a Recipe Plug-In for those users that are interested, though enough interest would need to be demonstrated before investing the time, effort & expense to make & maintain one.

15 hours ago, seanbuff said:

You might have a better experience using something for which this use case is designed for like Mealie

I begin to see your point:  The Mealie Server offers comprehensive recipe & meal management services that DO go way beyond what anyone should expect from Emby.  However, this requires some setup & configuration with Docker to get it up & running on my NAS.  I will need to explore some more to see exactly what it entails.

All my recipes are stored as PDFs, which could easily be presented using mostly features already available under Emby BOOKS.  The "recipe-specific" features I was suggesting were simply a way to keep them separate from books when searching/browsing, a way to preview them before downloading and hopefully, a way to open & read them without having to download then import them into a reader.  The advanced features offered by Mealie (like recipe re-sizing, grocery lists & meal planning) go WAY beyond what I was asking for in Emby.  On that point, I agree with you.

 

FOR USERS INTERESTED IN SHARING PDF RECIPES USING EMBY AS-IS, THESE ARE MY SUGGESTIONS:

1) Have a separate folder tree for recipes that can be searched separately from other books using the FOLDER option in the BOOK library, then add the main folder to the Emby Book Library.  On a NAS, having a separate SHARED FOLDER might be easiest, though I see no reason having a RECIPE sub-folder under your main E-BOOK folder shouldn't work as well.

2) My original post in this thread has a screenshot showing how I chose to organize topics to allow for easy browsing by folder.  Any intuitive organization you choose would be helpful.  Use of TAGS for individual recipes will allow users to FILTER by additional topics you define (such as holiday, ingredient or cooking style/technique [e.g.sheet-pan, slow-cooker, nationality, etc]).

3) As more general E-book related features come online (intent stated by other forum moderators), hopefully a "quick-view" feature will be among them to allow "glancing" at an item before downloading it.  An Emby dedicated book/PDF reader would make reading all items easier directly from the platform, without requiring the multi-step process of downloading a file, then importing to a reader.

[visproduction 264]

There is also the issue of should the pdf reader function not allow downloading which matches the functionality of all other Emby assets that are not downloadable, unless there is a license and that admin turns this feature on.

It's difficult to stop .pdf to be downloadable.  You would have to use a special viewer that stops downloading.  Why would anyone wish to not allow pdf downloading?  Users could capture a screenshot, page by page.  Perhaps some longer content needs to be protected from downloading.
 

1. Should pdf downloading be normally blocked and only available for users to read inside Emby app, page by page?  If so, what does the special pdf viewer do and how does it look?
2. Should the admin be able to switch downloading for pdf on and off for each user?
3. Should the admin be able to switch downloading for pdf on and off for each pdf?

 

[RLanger7228 54]

On 3/30/2025 at 5:21 PM, visproduction said:

Why would anyone wish to not allow pdf downloading

in my example (browsing recipes) "quick-view" would simply be a convenience to "glance" at a recipe while browsing through a lot of them, allowing the user to select the one(s) they WANT to download.  I never intended to prevent downloading.  Viewing without being allowed  to download would be subject to potential "security breaches" as you described.  

The issue you raise regarding licensing is also applicable to other content presented in Emby.  However, Emby is intended to be a private platform for sharing content you own with a select group of users, and should not be subject to licensing concerns.  Presumably, the Administrator would select who has access to which library content, and should only be sharing content that can be shared with the users that are authorized.

Determining authorizations for individual files for individual users seems to be a function that goes beyond the scope of what Emby is intended for, and would require an intensive amount of coding to achieve,  If that were my intention, a different platform better suited to that functionality would be a better option, as suggested by @seanbufffor recipe management in general.

I only wanted to use the user-friendly cross-platform Emby to easily share my recipe file with the family members I have as authorized users in my system.  Everyone is allowed to download everything, so the security issues you raised are not applicable to what I was suggesting, and should be easily manageable using Emby features as is, with only small modifications to existing features for the sake of convenience.  The comprehensive features (like recipe resizing & making grocery lists) go beyond what Emby should provide & were not what I was asking for in my original suggestion.