jellyfin-web
jellyfin-web copied to clipboard
Don't set content type to null for mixed libraries during creation
Changes Removed code that set content type to null for mixed libraries during virtual folder creation.
This was added in https://github.com/jellyfin/jellyfin-web/commit/81d936ff1cbb3a4b8c15098da5e159ea3096c800. There is no further information about what issue this fixed, however it is currently causing issues for parts of code that expect the content type to be correctly set.
I was not able to find any issues when creating a mixed library, viewing mixed library content, etc. after making this change but so much of the code has changed since 2015 it's hard to say if whatever issue that prompted this change has been fixed somewhere else or if it is just not obvious enough to find during preliminary testing.
Alternatively, code that checks for 'mixed' type could instead check for null.
Issues Fixes #5490 Fixes https://github.com/jellyfin/jellyfin/issues/11284
Also fixes related issues such as library sub-heading showing "Other" instead of "Mixed Movies and Shows."
Quality Gate passed
Issues
0 New issues
0 Accepted issues
Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code
Cloudflare Pages deployment
Latest commit | fca2be4 |
---|---|
Status | ✅ Deployed! |
Preview URL | https://c48ee241.jellyfin-web.pages.dev |
Type | 🔀 Preview |
This will definitely break other functionality (in web) that depends on the mixed type being undefined.
This will definitely break other functionality (in web) that depends on the mixed type being undefined.
Would it be better then to change code that checks for mixed type to check for undefined type? Seems to just be a few places in the library scripts. As long as it's guaranteed that an undefined type always means mixed movies and shows then that should also work.
I haven't had a chance to read over the related issue fully but we need to ensure that existing libraries with the undefined type continue to work as expected.
Is there a technical reason to why mixed type is converted to other on creation?
I have a quite big library with type set to mixed, but since trickplay doesn't work with 'other' https://github.com/jellyfin/jellyfin-web/issues/5490 and I'm not aware of any way to modify existing library type this is a potential serious issue if it would require rebuilding libraries with different type.
I actually need mixed, because there are movies and television series in one library on purpose. I may find necessary to recreate my libraries but have to know if removing old library will also remove its content from already created playlists?
Basically I have one giant playlist that sorts movies and tv shows for watching chronologically and this playlist points to movies and shows stored inside this one mixed type library.
Example:
library 1 (type: mixed): ├─ series 1 ├─├─ movie 1 ├─├─ movie 2 ├─└─ tv show 1 ├─ series 2 ├─├─ movie 3 └─└─ tv show 2
Now my playlist consists of all above so I can watch in order eg: series 1, movie 1 -> series 1, tv show 1 -> series 2, tv show 2 -> series 1, movie 2 etc. etc.
So if I recreate my library and distribute files to separate folders without changing file names will my playlist continue to work as before or will it break (e.g. missing movies or removed items)?
Sorry for this long wall of text but I would rather not have to recreate my entire 450+ elements playlist if I can avoid it. It was a long and tedious process to sort this list for chronological order.
Is there a technical reason to why mixed type is converted to other on creation?
They are the same thing. Mixed libraries have always used a null/undefined type so every check in web (and server and possibly every other client) would need updated to handle mixed with a specific type now.
I have a problem with subfolders, I don't understand if there is a way to solve it. Basically, I use a separate folder to make it less crowded so I can find a better way to include new items... ├─ Anime ├─ Several folders where I didn't follow the season (identify correctly) ├─├─ 2024 2 TRIM (identifies 1 and the rest appears as season in the same)
#5490 was fixed in #5810