Search Issue Tracker
Won't Fix
Won't Fix in 1.8.X
Votes
1
Found in [Package]
1.8.8
Issue ID
TB-337
Regression
No
INotificationReceiver does not receive a notification when using custom markers in the Timeline
How to reproduce:
1. Open the attached “findBUG_TimelineNotificationsNotEmiting” project
2. Open the “SampleScene”
3. Enter Play mode
4. Observe the Console
Expected result: A message “Setup SomeNotificationReceiver on 1 outputs” followed by nine “SomeNotificationReceiver X”, each one second apart, are displayed
Actual result: Only the “Setup SomeNotificationReceiver on 1 outputs” message is displayed
Reproducible with: 1.7.0 (2022.1.0a1), 1.8.8 (2022.1.0a1, 2022.3.62f1, 6000.0.52f1, 6000.1.10f1, 6000.2.0b8, 6000.3.0a1)
Reproducible on: Windows 10
Not reproducible on: Windows 11
Note: Only reproducible in the Editor, does not reproduce in build
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Texture2D hash changes inside of an AssetBundle when rebuilding a SpriteAtlas bundle with an empty AssetPostprocessor Script enabled
- Aniso Level still applies when Generate MipMap is disabled in Texture Import Settings
- Mipmap Limit Groups long names are not truncated when creating a new Mipmap Limit Group with a long name
- “ArgumentException: Invalid double parameter.” error is thrown when Infinity is typed into the Fixed Timestep field
- GameObject becomes gray when using HDRP and STP together on macOS
Resolution Note:
This issue is happening because of the difference in the way garbage collection is handled in the Editor Playmode compared to Runtime.
In Runtime (Standalone) the garbage collector does not run if it is not explicitly called whereas in Playmode it runs automatically.
Because PlayableOutputs hold only a weak reference to the receiver objects they will be garbage collected in playmode unless they are referenced somewhere else. With receivers getting destroyed of course nothing happens.
An easy way to fix this is to manage their lifetime in the PlayTimelineWithSetup monobehaviour or notification receiver class, for example they can be held in a static list in the notification receiver class in this way.
private static List<SomeNotificationReceiver> managedReceivers = new List<SomeNotificationReceiver>();
public static void Setup(PlayableGraph graph)
{
managedReceivers.Clear();
for (int i = 0; i < graph.GetOutputCount(); i++)
{
var notif = new SomeNotificationReceiver();
graph.GetOutput(i).AddNotificationReceiver(notif);
managedReceivers.Add(notif);
}
}
That way they will be referenced until a new setup is called and won't be destroyed during the first frame.
Resolution Note (1.8.X):
This issue is happening because of the difference in the way garbage collection is handled in the Editor Playmode compared to Runtime.
In Runtime (Standalone) the garbage collector does not run if it is not explicitly called whereas in Playmode it runs automatically.
Because PlayableOutputs hold only a weak reference to the receiver objects they will be garbage collected in playmode unless they are referenced somewhere else. With receivers getting destroyed of course nothing happens.
An easy way to fix this is to manage their lifetime in the PlayTimelineWithSetup monobehaviour or notification receiver class, for example they can be held in a static list in the notification receiver class in this way.
private static List<SomeNotificationReceiver> managedReceivers = new List<SomeNotificationReceiver>();
public static void Setup(PlayableGraph graph)
{
managedReceivers.Clear();
for (int i = 0; i < graph.GetOutputCount(); i++)
{
var notif = new SomeNotificationReceiver();
graph.GetOutput(i).AddNotificationReceiver(notif);
managedReceivers.Add(notif);
}
}
That way they will be referenced until a new setup is called and won't be destroyed during the first frame.