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
- “FMOD failed to set the software format to the custom sample rate…” warnings are thrown as System Sample Rate value is being changed in Audio section of Project Settings window
- VFX Marquee selection does match the visual indicator
- “Invalid AABB aabb” errors are spammed when “Infinity” value is entered in Collider Component fields
- Editor Role does not sync with the MPPM Play Mode Scenario Role when entering Play mode
- Long asset names cause overlap with the “Find” function in search result tabs
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.