Improve architecture, performance, testability of Library management #2207

Closed
opened 2026-02-06 21:51:11 +03:00 by OVERLORD · 2 comments
Owner

Originally created by @xaviergxf on GitHub (Oct 22, 2020).

I was looking at the source code of library management and i believe lots of improvements could be done. I would like to open a discussion about improvements. Here are some suggestions:

  • Lots of static methods, that are hard to test, shouldn't we use di for that? Ex: SeriesResolver.IsSeriesFolder
  • Lots of classes without interfaces, they cannot be easily mocked. Ex: EpisodePathParser
  • Some classes are huge. Ex: Library Manager
  • Use of dependency injection instead of instantiating classes. Ex: EpisodeResolver
  • Use more composition and less inheritance.
  • Improve performance of regex using .net5, span, compiled regex, etc.
  • More use of async.
  • Do we still need IFileSystem abstraction?

Do anyone have other suggestions? I believe this is a complete redo of what exists currently.

Originally created by @xaviergxf on GitHub (Oct 22, 2020). I was looking at the source code of library management and i believe lots of improvements could be done. I would like to open a discussion about improvements. Here are some suggestions: - Lots of static methods, that are hard to test, shouldn't we use di for that? Ex: SeriesResolver.IsSeriesFolder - Lots of classes without interfaces, they cannot be easily mocked. Ex: EpisodePathParser - Some classes are huge. Ex: Library Manager - Use of dependency injection instead of instantiating classes. Ex: EpisodeResolver - Use more composition and less inheritance. - Improve performance of regex using .net5, span, compiled regex, etc. - More use of async. - Do we still need IFileSystem abstraction? Do anyone have other suggestions? I believe this is a complete redo of what exists currently.
Author
Owner

@Motophan commented on GitHub (Nov 10, 2020):

I have a 100TB library on zfs w/ a cache system. I can read and write to the array at 1.2GBps (bytes) after my cache device is fatigued (out of L2ARC and ARC). My library scans take ~ 12 hours and fail >50% of the time. Library scans are significantly slower with more users. Example: you can scan my 100TB library in a fresh jellyfin container w/ 1 user (after initial scan) in about 10 minutes. With 120 users this balloons into 4 hours and increases from there.

I think we should focus on what makes the library scan slow w/ lots of users and lots of watch time first as this seems to have the most dramatic performance increase.

If there is any way I can give you telemetry data about this please let me know. My jellyfin server is very active.

@Motophan commented on GitHub (Nov 10, 2020): I have a 100TB library on zfs w/ a cache system. I can read and write to the array at 1.2GBps (bytes) after my cache device is fatigued (out of L2ARC and ARC). My library scans take ~ 12 hours and fail >50% of the time. Library scans are significantly slower with more users. Example: you can scan my 100TB library in a fresh jellyfin container w/ 1 user (after initial scan) in about 10 minutes. With 120 users this balloons into 4 hours and increases from there. I think we should focus on what makes the library scan slow w/ lots of users and lots of watch time first as this seems to have the most dramatic performance increase. If there is any way I can give you telemetry data about this please let me know. My jellyfin server is very active.
Author
Owner

@cvium commented on GitHub (Nov 10, 2020):

@Motophan That's not really relevant to the OP. It's also a known problem and fixed in unstable (future 10.7): https://github.com/jellyfin/jellyfin/issues/4364

@cvium commented on GitHub (Nov 10, 2020): @Motophan That's not really relevant to the OP. It's also a known problem and fixed in unstable (future 10.7): https://github.com/jellyfin/jellyfin/issues/4364
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/jellyfin#2207