feat: Display specials #711

HachiHalation · 2026-01-14T09:13:49Z

Pull Request Description

Adds a special features row to show details and season details screens, similar to the official jellyfin client. Unfortunately, due to how the special features API is set up, it is really difficult to group them by season in the show screen without making a bunch of API calls.

Add SpecialFeatureModel
Add SpecialFeatureRow widget (based on EpisodePosters)
Add the required data to relevant providers
Add Special Feature localization string to EN file

Issue Being Fixed

Resolves #632

Screenshots / Recordings

show screen:

season screen:

Checklist

If a new package was added, did you ensure it works for all supported platforms? Is the package well maintained
Check that any changes are related to the issue at hand.

PartyDonut

Thank you for implementing this. I added a few comments let me know if anything is unclear.

I don't have any special features so not fully able to test it. But the code looks fine logic wise.

PartyDonut · 2026-01-18T17:17:22Z

lib/models/items/special_feature_model.dart

+@MappableClass()
+class SpecialFeatureModel extends ItemStreamModel with SpecialFeatureModelMappable {
+  final List<Chapter> chapters;
+  final ItemLocation? location;


This seems unused probably better to remove it.

PartyDonut · 2026-01-18T17:18:03Z

lib/models/items/special_feature_model.dart

+  static List<SpecialFeatureModel> specialFeaturesFromDto(List<dto.BaseItemDto>? dto, Ref ref) {
+    return dto?.map((e) => SpecialFeatureModel.fromBaseDto(e, ref)).toList() ?? [];
+  }
+}


Please add the newline as well. So we can keep consistent formatting.

PartyDonut · 2026-01-18T17:19:51Z

lib/providers/service_provider.dart

+    try {
+      return api.itemsItemIdSpecialFeaturesGet(itemId: itemId, userId: account?.id);
+    } catch (e) {
+      return Response(http.Response("", 400), []);


Any errors here will be obfuscated because we throw away whatever the exception is telling us.
Remove the try{} catch{}. So we can monitor the original response.

I agree that we shouldnt swallow the exception here. But I do think the current callers should catch them and emit a log if there is a problem since in this context a failure should not stop the application.

Makes sense. Currently the handling of errors is a bit of a mess of my making.

Lets just leave it as is without the try/catch same as most of the other calls. I will have to come up with a proper solution when I can find the time.

Sorry, I already moved the try catch before I saw this. Let me know if you want me to remove it anyways.

PartyDonut · 2026-01-18T17:22:46Z

lib/screens/shared/media/special_features_row.dart

+  List<SpecialFeatureModel> get specialFeatures {
+    return widget.specialFeatures;
+  }


Suggested change

List<SpecialFeatureModel> get specialFeatures {

return widget.specialFeatures;

}

List<SpecialFeatureModel> specialFeatures = widget.specialFeatures;

This can be moved to the build part of the widget. After that make the widget stateless as there is no state we need to maintain.

PartyDonut · 2026-01-18T17:25:20Z

lib/screens/shared/media/special_features_row.dart

+  final String? label;
+  final ValueChanged<SpecialFeatureModel> playSpecialFeature;
+  final EdgeInsets contentPadding;
+  final Function(VoidCallback action, SpecialFeatureModel specialFeatureModel)? onSpecialFeatureTap;


Suggested change

final Function(VoidCallback action, SpecialFeatureModel specialFeatureModel)? onSpecialFeatureTap;

final Function(SpecialFeatureModel specialFeatureModel)? onSpecialFeatureTap;

Why does this take another VoidCallback as argument? I would suggest to only return the SpecialFeatureModel.

PartyDonut · 2026-01-18T17:27:51Z

lib/screens/shared/media/special_features_row.dart

+      startIndex: null,
+      items: specialFeatures,
+      itemBuilder: (context, index) {
+        final specialFeature = specialFeatures[index];
+        final tag = UniqueKey();
+        return SpecialFeaturePoster(
+          specialFeature: specialFeature,
+          heroTag: tag,
+          blur: false,
+          onTap: widget.onSpecialFeatureTap != null
+              ? () {
+                  widget.onSpecialFeatureTap?.call(
+                    () {
+                      specialFeature.play(context, ref);
+                    },
+                    specialFeature,
+                  );
+                }
+              : () {
+                  specialFeature.play(context, ref);
+                },


Suggested change

startIndex: null,

items: specialFeatures,

itemBuilder: (context, index) {

final specialFeature = specialFeatures[index];

final tag = UniqueKey();

return SpecialFeaturePoster(

specialFeature: specialFeature,

heroTag: tag,

blur: false,

onTap: widget.onSpecialFeatureTap != null

? () {

widget.onSpecialFeatureTap?.call(

() {

specialFeature.play(context, ref);

},

specialFeature,

);

}

: () {

specialFeature.play(context, ref);

},

onTap: widget.onSpecialFeatureTap != null

? () => widget.onSpecialFeatureTap?.call(

specialFeature,

)

: () => specialFeature.play(context, ref),

Ok now we know why there was a action. But I'm not sure why that behaviour is there.
I would expect the function to be called if not null and we then supply the tapped specialFeature. Where we can then do whatever action needed in the details screens.

It's ok to fallback to a "default" action, but when the function has a override it should not still call the "default" action.

This behavior is consistent with the existing behavior from EpisodePosters widget. I don't really understand the concern, it is up to the caller to invoke the default action (in this case play) using the callback provided in onSpecialFeatureTap if they wish to.

From what I understand from looking at the code, onSpecialFeatureTap provides a hook to callers to change the behavior of the tap action. onSpecialFeatureTap also provides a callback to the default action so that the caller can use it if they still want to perform the default actions during the customized logic.

This all makes sense to me and is what was already implemented in EpisodePosters so I am keeping it like this for now. But please correct me if I am missing something and I will fix it.

It's more that I like to explicitly know what "action" is.
This makes the code just a little bit less readable because we have to dive into the widget itself to see what action actually does.

I know it also happens in the EpisodePosters but I don't like it there either, I should probably remove it there as well just did not get to that yet.

So it's fine to leave it as is, this works perfectly fine. But I would prefer the callback to be more explicit.

Made some changes to hopefully make it more readable. If you still don't like it I will take your recommended solution instead.

PartyDonut

Looks good to me, thanks for implementing the changes.

HachiHalation added 2 commits January 11, 2026 19:12

add special features row to series and seasons

ae44be2

make special features playable

7a03706

PartyDonut requested changes Jan 18, 2026

View reviewed changes

HachiHalation added 6 commits January 18, 2026 20:16

some cleanup for special features

0874ae9

small logging improvments

01d81f9

Merge branch 'develop' into display-specials

008b2a9

update onSpecialFeatureTap behavior

e0da2f1

fix formatting

1fb2dab

remove unsused import

73d35a8

HachiHalation requested a review from PartyDonut January 20, 2026 09:31

PartyDonut approved these changes Jan 21, 2026

View reviewed changes

PartyDonut changed the title ~~Display specials~~ feat: Display specials Jan 21, 2026

PartyDonut added the feature New feature or request label Jan 21, 2026

PartyDonut merged commit 50a22fa into DonutWare:develop Jan 21, 2026
1 check passed

popdollar pushed a commit to popdollar/Fladder-Tizen that referenced this pull request Jan 22, 2026

feat: Display specials (DonutWare#711)

88e0178

chocolate-neko mentioned this pull request Jan 24, 2026

feat: Display movie specials #723

Merged

2 tasks

	final Function(VoidCallback action, SpecialFeatureModel specialFeatureModel)? onSpecialFeatureTap;
	final Function(SpecialFeatureModel specialFeatureModel)? onSpecialFeatureTap;

Uh oh!

feat: Display specials #711

feat: Display specials #711

Uh oh!

Conversation

HachiHalation commented Jan 14, 2026

Pull Request Description

Issue Being Fixed

Screenshots / Recordings

Checklist

Uh oh!

PartyDonut left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

PartyDonut left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

PartyDonut left a comment •

edited

Loading