No user activity notification email since updating to latest emby prod version.

[Jrod696 28]

I am having this same issue, if I rely on the scheduled trigger I no longer receive email user activity notifications, if I manually trigger it I do get the email, however I can tell the trigger is working on the schedule because I also have it sending the same notification to a discord channel for logging as well and that shows up on the schedule. 

When I look at the logs I can also see the discord trigger happening but its not even trying to send the email when its left to run on its schedule.

I have tried deleting and recreating the User Activity Notification trigger with no luck, I went to the notification where the SMTP data is stored and hit save to refresh it although that already works because I get reboot notifications and things like that just not the scheduled User Activity Notification none the less I hit save on it and nothing so I deleted the whole email notification and rebuilt it as well and still nothing unless I manually trigger it. I even tried uninstalling and reinstalling the email plugin with no luck.

 

[Luke 42077]

@Jrod696

HI there, can you please provide a specific example?

How to Report a Problem

Thanks !

 

[Jrod696 28]

I provided the info the troubleshooting I went through and the steps I took to test it, I have concerns about uploading a log to a public forum, it contains a ton of PII.

[Luke 42077]

Hi, you can also send it via PM.

[Jrod696 28]

Sounds good, I sent it over and noted it the best I could to identify it to this post.

[Jrod696 28]

I also found a bug that I think is unrelated, but I wasn’t sure if I should start a new thread or just mention it here on the very slim chance it’s connected. It might also already be in the log file I DM’d you, but depending on rotation timing, it may have rolled out. I found this issue right after updating.

Here’s what’s happening and how to reproduce it:

Environment

• Emby Server: 4.9.x (Windows service)

• Email Notifications plugin: 3.2.1.0

• SMTP provider: SMTP2GO (requires STARTTLS on port 587, implicit SSL on 465)

• Multiple RR servers in the same environment using the same SMTP2GO account and settings

  Servers using port 465 or 587 with SSL/TLS enabled work correctly

Summary
On this particular server, if “Enable SSL/TLS” is checked, the test email sends successfully, but the scheduled job fails to send. When “Enable SSL/TLS” is unchecked, both the test and the scheduled job work fine.
The logs clearly show an AuthenticationException on the scheduled send path when SSL/TLS is enabled — an SSL handshake failure — even though the test email works with the same settings.

Repro steps

• Configure Email Notifications:

  Host: mail.smtp2go.com

  Port: 587

  Enable SSL/TLS = ON

  Click “Send test email” → succeeds.

• Generate a playback event (play → stop). Run “User Activity Notification” manually or let it trigger on schedule.

  Expected: email sent.

  Actual: email not sent; Discord/webhook still succeeds.

  Log shows:
  System.Security.Authentication.AuthenticationException: Cannot determine the frame size or a corrupted frame was received.

• Uncheck “Enable SSL/TLS,” keep everything else identical, rerun → scheduled email sends successfully. SMTP2GO activity confirms TLS 1.2 encryption via STARTTLS.

Notes

• The same configuration works on other RR servers (465 and 587 with SSL/TLS checked).

• Only this instance shows the error, and only when the SSL/TLS checkbox is enabled.

• The test email succeeds because it uses a direct synchronous send; the scheduled task uses an asynchronous path that fails during the SSL handshake.

• The failure appears to happen because the plugin forces an implicit-SSL connection on a port expecting STARTTLS, causing the handshake to break.

Summary
The plugin’s SSL/TLS checkbox seems to call implicit-SSL logic instead of STARTTLS on ports 587/465 in the async/scheduled path. The synchronous test path works fine, but the async one throws an AuthenticationException and drops the email. Other servers configured the same way don’t have the issue, so this might be an environmental edge case or a bug in how the scheduled async path handles TLS negotiation.

I also verified with Wireshark that encryption was active on port 587 with the SSL/TLS option unchecked. The encryption occurred because SMTP2GO initiated a STARTTLS handshake during the connection, ensuring the session was fully encrypted even with the checkbox disabled in Emby.

For context, I have a development background and I suspect this may be related to recent .NET updates possibly changes in how SslStream or the MailKit implementation handles STARTTLS vs. implicit SSL negotiation. The timing and behavior line up with that kind of framework-level change.

Edited October 31, 2025 by Jrod696

[Luke 42077]

6 hours ago, Jrod696 said:

Sounds good, I sent it over and noted it the best I could to identify it to this post.

What example are we focusing on in this log?

[Jrod696 28]

So the not sending the email is not in the log, on the schedule you can look for the webhook to fire to send over the info to Discord but it does not even attempt to send an email so there is nothing in the log I could find, you should see where it sent emails for reboot notifications and things of that nature but that was why I ended up posting, I went through as much troubleshooting as possible and read through the logs and basically came up empty handed when I didnt even see a failure in the log itself.

its like the scheduled task is just ignoring the email notification for user activity all together, this one is interesting.

Edited October 31, 2025 by Jrod696

[Luke 42077]

How did you configure your notifications? What specific notification did you expect to see ?

[Luke 42077]

37 minutes ago, Jrod696 said:

I also found a bug that I think is unrelated, but I wasn’t sure if I should start a new thread or just mention it here on the very slim chance it’s connected. It might also already be in the log file I DM’d you, but depending on rotation timing, it may have rolled out. I found this issue right after updating.

Here’s what’s happening and how to reproduce it:

Environment

• Emby Server: 4.9.x (Windows service)

• Email Notifications plugin: 3.2.1.0

• SMTP provider: SMTP2GO (requires STARTTLS on port 587, implicit SSL on 465)

• Multiple RR servers in the same environment using the same SMTP2GO account and settings

  Servers using port 465 or 587 with SSL/TLS enabled work correctly

Summary
On this particular server, if “Enable SSL/TLS” is checked, the test email sends successfully, but the scheduled job fails to send. When “Enable SSL/TLS” is unchecked, both the test and the scheduled job work fine.
The logs clearly show an AuthenticationException on the scheduled send path when SSL/TLS is enabled — an SSL handshake failure — even though the test email works with the same settings.

Repro steps

• Configure Email Notifications:

  Host: mail.smtp2go.com

  Port: 587

  Enable SSL/TLS = ON

  Click “Send test email” → succeeds.

• Generate a playback event (play → stop). Run “User Activity Notification” manually or let it trigger on schedule.

  Expected: email sent.

  Actual: email not sent; Discord/webhook still succeeds.

  Log shows:
  System.Security.Authentication.AuthenticationException: Cannot determine the frame size or a corrupted frame was received.

• Uncheck “Enable SSL/TLS,” keep everything else identical, rerun → scheduled email sends successfully. SMTP2GO activity confirms TLS 1.2 encryption via STARTTLS.

Notes

• The same configuration works on other RR servers (465 and 587 with SSL/TLS checked).

• Only this instance shows the error, and only when the SSL/TLS checkbox is enabled.

• The test email succeeds because it uses a direct synchronous send; the scheduled task uses an asynchronous path that fails during the SSL handshake.

• The failure appears to happen because the plugin forces an implicit-SSL connection on a port expecting STARTTLS, causing the handshake to break.

Summary
The plugin’s SSL/TLS checkbox seems to call implicit-SSL logic instead of STARTTLS on ports 587/465 in the async/scheduled path. The synchronous test path works fine, but the async one throws an AuthenticationException and drops the email. Other servers configured the same way don’t have the issue, so this might be an environmental edge case or a bug in how the scheduled async path handles TLS negotiation.

I also verified with Wireshark that encryption was active on port 587 with the SSL/TLS option unchecked. The encryption occurred because SMTP2GO initiated a STARTTLS handshake during the connection, ensuring the session was fully encrypted even with the checkbox disabled in Emby.

For context, I have a development background and I suspect this may be related to recent .NET updates possibly changes in how SslStream or the MailKit implementation handles STARTTLS vs. implicit SSL negotiation. The timing and behavior line up with that kind of framework-level change.

When you check the box, this property gets set to true: https://learn.microsoft.com/en-us/dotnet/api/system.net.mail.smtpclient.enablessl?view=net-9.0

[Jrod696 28]

3 minutes ago, Luke said:

How did you configure your notifications? What specific notification did you expect to see ?

I expected to get the same email I’ve been receiving for years at 12:30 AM, the one showing who watched what and for how long. That email no longer sends automatically. I can watch a show for 20 seconds and manually trigger the User Activity Notification in the scheduler, and I’ll get both the expected email and the Discord message. But when it runs on the scheduled trigger, I only get the Discord drop and no email, and there’s nothing in the log showing that it even attempted to send one.

[Jrod696 28]

12 minutes ago, Luke said:

When you check the box, this property gets set to true: https://learn.microsoft.com/en-us/dotnet/api/system.net.mail.smtpclient.enablessl?view=net-9.0

That makes sense, though it looks like the issue might relate to how that property behaves in the async send path. The .NET docs mention that if EnableSsl is true but the server’s STARTTLS advertisement isn’t correctly handled, SendAsync will throw an SmtpException. Since the scheduled task doesn’t surface that error, it could explain why the test email works but the scheduled job fails silently.

[Jrod696 28]

I think I may have muddied things up in this thread by posting two separate bugs that aren’t actually tied together. At first I thought they might be related, but since I’ve got a workaround for the SMTP issue, it’s probably a separate problem.

If it helps keep things organized, I can create a new post titled SMTP TLS/SSL Bug and move all of that info there, or if it’s easier for you to split it out on your end, that’s fine too. I just don’t want to mix two unrelated bugs in the same thread and make troubleshooting harder.

[Jrod696 28]

I rotated the log so it would waaaay smaller and DM'd it to you, you should be able to see clearly at 00:30 there is the call for the webhook to send the info to discord but nothing talking to email, then I manually ran the schedule by hitting the play button at about 00:41 (at the bottom) and I did get the email and you can see the log light up like a Christmas tree with the proper SMTP send sequence

[Luke 42077]

I see in the log at 00:30 it tried to send an email but there was a failure.

[Jrod696 28]

4 minutes ago, Luke said:

I see in the log at 00:30 it tried to send an email but there was a failure.

I didn't catch that one I'll have to go back and look but why does it fail on schedule but not when manually triggered 

Edited October 31, 2025 by Jrod696

[Jrod696 28]

I see it and actually my initial theory of the 2 issues of SMTP handling the SSL and TLSS may actually tied together, the issue looks like its happening when Emby’s scheduled task runs, it uses SendAsync() to send email notifications. That async call throws an SmtpException and terminates, so no email ever goes out. You only saw the webhook (Discord) succeed because it uses a different handler. 

That same exception (SmtpException) is what Microsoft warns about in their docs: if EnableSsl = true and the SMTP server doesn’t immediately advertise STARTTLS, the SendAsync() call will fail with the exact error you’re seeing  “SMTP command timeout - closing connection.” 

It looks like something in the base code isn’t fully honoring the SSL/TLS checkbox setting and is still trying to initiate part of that handshake anyway. Since I’m using a stricter, enterprise-grade SMTP server, it’s probably rejecting that partial or “dirty” negotiation attempt.

 

2025-10-31 00:30:01.681 Error Notifications: Error sending notification
    *** Error Report ***
    Version: 4.9.1.80
    Command line: AppData\Roaming\Emby-Server\system\EmbyServer.dll -noautorunwebapp
    Operating system: Microsoft Windows 10.0.19045
    OS/Process: x64/x64
    Framework: .NET 8.0.20
    Runtime: AppData/Roaming/Emby-Server/system/System.Private.CoreLib.dll
    Processor count: 8
    Data path: AppData\Roaming\Emby-Server\programdata
    Application path: AppData\Roaming\Emby-Server\system
    System.Net.Mail.SmtpException: System.Net.Mail.SmtpException: Service not available, closing transmission channel. The server response was: mail.smtp2go.com: SMTP command timeout - closing connection
       at System.Net.Mail.MailCommand.CheckResponse(SmtpStatusCode statusCode, String response)
       at System.Net.Mail.MailCommand.EndSend(IAsyncResult result)
       at System.Net.Mail.SendMailAsyncResult.SendMailFrom()
       at System.Net.Mail.SmtpTransport.BeginSendMail(MailAddress sender, MailAddressCollection recipients, String deliveryNotify, Boolean allowUnicode, AsyncCallback callback, Object state)
       at System.Net.Mail.SmtpClient.SendMailAsync(Object state)
       at System.Net.Mail.SmtpClient.SendAsync(MailMessage message, Object userToken)
    --- End of stack trace from previous location ---
       at MediaBrowser.Plugins.SmtpNotifications.Notifier.SendNotification(InternalNotificationRequest request, CancellationToken cancellationToken)
       at Emby.Notifications.NotificationQueueManager.StartProcessingQueue()
    Source: System.Net.Mail
    TargetSite: Void CheckResponse(System.Net.Mail.SmtpStatusCode, System.String)

 

 

Edited October 31, 2025 by Jrod696

[Luke 42077]

It sounds like an issue in the dotnet smtp client.

[Jrod696 28]

If it helps, I set up a new Windows Server 2019 virtual machine on my ESXi host and performed a completely fresh install of Emby to rule out any environmental factors. The setup was intentionally minimal with only Emby and its required dependencies, a small local media library not linked to my NAS, and the essential plugins, specifically the email and Discord notification plugins for testing.

I was able to reproduce the same errors seen in my primary production server logs, and the behavior was identical.

For reference, I’m using SMTP2GO as the mail service. I have one of their higher-tier plans for my environment, but the same results should be reproducible using their free tier as long as a valid domain is connected.

Based on my testing on this clean, isolated Server OS installation running under ESXi where both the TLS and SSL checkbox issue and the “no notification unless manually triggered” issue were consistently reproducible, I believe this can be replicated on your end as well using SMTP2GO’s free option.

[vaise 340]

On 31/10/2025 at 19:10, Luke said:

It sounds like an issue in the dotnet smtp client.

isnt that emby ?  its set up with the emby notifications.

[Jrod696 28]

Ok, I’ve got a follow up, though I can’t really explain this one. Two days ago, I got the email notification from Emby saying it needed a reboot because some plugins had updated, so I rebooted it right away. I already knew that part of the email system was still working so that was no surprise, but here’s where it got weird. That email went out at exactly 11:58 PM, and then at 12:30 AM, 32 minutes later, I actually got my user activity email like I was supposed to.

I figured maybe something got patched in the updates, but since neither email nor core showed as updated in the log, I decided to wait for another cycle to be sure. Yesterday’s came around, and sure enough, no email, just the Discord push through the webhook, so it’s definitely not fixed.

Still, something about that restart notification must’ve temporarily triggered whatever piece of the email process is broken, because it worked that one time. I have no idea what, though. At first, I thought maybe the SMTP connection was still held open or the auth token hadn’t expired yet, but 32 minutes is a long time for something like that to stay alive.

The log from 11/4 at 00:30:00 there is not even logging of it sending the email at all no pass or fail, just the discord webhook which further confused me because I did receive that email.

From Email Header:

Message ID	<xxxxxxxxxx@message-id.smtpcorp.com>
Created at:	Tue, Nov 4, 2025 at 12:30 AM (Delivered after 3 seconds)
From:	Emby@mydomain.com
To:	xxxxxx@gmail.com
Subject:	User Activity Report Notification
SPF:	PASS with IP xxx.xxx.xxx.xxx
DKIM:	'PASS' with domain mydomain.com
DMARC:	'FAIL'

 Emby Log from 11/4:

2025-11-04 00:30:00.017 Info UserActivityReportNotification - TaskNotifictionReport: Activity Query : SELECT UserId, ItemType, ItemName, SUM(PlayDuration - PauseDuration) AS PlayTime FROM PlaybackActivity WHERE DateCreated > '2025-11-03 06:30:00.6970696' AND UserId not IN (select UserId from UserList) GROUP BY UserId, ItemType, ItemName
2025-11-04 00:30:00.025 Info UserActivityReportNotification - TaskNotifictionReport: Cutoff DateTime for new items - date: 2025-11-03 06:30:00.6970696 ago: 17:59:59.3272608
2025-11-04 00:30:00.025 Info UserActivityReportNotification - TaskNotifictionReport: User activity Message : ItemCount : 4
2025-11-04 00:30:00.158 Info HttpClient: POST https://discord.com/api/webhooks/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
2025-11-04 00:30:00.591 Info HttpClient: Http response 204 from https://discord.com/api/webhooks/xxxxxxxxxxxxxxxxxxxxxxxxx after 433ms

 

Emby Log from 11/5 (next day):

2025-11-05 00:30:00.741 Info UserActivityReportNotification - TaskNotifictionReport: Activity Query : SELECT UserId, ItemType, ItemName, SUM(PlayDuration - PauseDuration) AS PlayTime FROM PlaybackActivity WHERE DateCreated > '2025-11-04 00:30:00.0266882' AND UserId not IN (select UserId from UserList) GROUP BY UserId, ItemType, ItemName
2025-11-05 00:30:00.742 Info UserActivityReportNotification - TaskNotifictionReport: Cutoff DateTime for new items - date: 2025-11-04 00:30:00.0266882 ago: 1.00:00:00.7161273
2025-11-05 00:30:00.742 Info UserActivityReportNotification - TaskNotifictionReport: User activity Message : ItemCount : 1
2025-11-05 00:30:00.802 Info HttpClient: POST https://discord.com/api/webhooks/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
2025-11-05 00:30:00.976 Info HttpClient: Http response 204 from https://discord.com/api/webhooks/xxxxxxxxxxxxxxxxxxxxxxxxx after 174ms
2025-11-05 00:30:01.044 Error Notifications: Error sending notification
    *** Error Report ***
    Version: 4.9.1.80
    Command line: AppData\Roaming\Emby-Server\system\EmbyServer.dll -noautorunwebapp
    Operating system: Microsoft Windows 10.0.19045
    OS/Process: x64/x64
    Framework: .NET 8.0.20
    Runtime: AppData/Roaming/Emby-Server/system/System.Private.CoreLib.dll
    Processor count: 8
    Data path: AppData\Roaming\Emby-Server\programdata
    Application path: AppData\Roaming\Emby-Server\system
    System.Net.Mail.SmtpException: System.Net.Mail.SmtpException: Service not available, closing transmission channel. The server response was: mail.smtp2go.com: SMTP command timeout - closing connection
       at System.Net.Mail.MailCommand.CheckResponse(SmtpStatusCode statusCode, String response)
       at System.Net.Mail.MailCommand.EndSend(IAsyncResult result)
       at System.Net.Mail.SendMailAsyncResult.SendMailFrom()
       at System.Net.Mail.SmtpTransport.BeginSendMail(MailAddress sender, MailAddressCollection recipients, String deliveryNotify, Boolean allowUnicode, AsyncCallback callback, Object state)
       at System.Net.Mail.SmtpClient.SendMailAsync(Object state)
       at System.Net.Mail.SmtpClient.SendAsync(MailMessage message, Object userToken)
    --- End of stack trace from previous location ---
       at MediaBrowser.Plugins.SmtpNotifications.Notifier.SendNotification(InternalNotificationRequest request, CancellationToken cancellationToken)
       at Emby.Notifications.NotificationQueueManager.StartProcessingQueue()
    Source: System.Net.Mail
    TargetSite: Void CheckResponse(System.Net.Mail.SmtpStatusCode, System.String)

 

Edited November 6, 2025 by Jrod696

[Luke 42077]

@Jrod696here you do. As you can see it tried to send the email, but the email server had an error:

Service not available, closing transmission channel. The server response was: mail.smtp2go.com: SMTP command timeout - closing connection

 

[Jrod696 28]

13 minutes ago, Luke said:

@Jrod696here you do. As you can see it tried to send the email, but the email server had an error:

Service not available, closing transmission channel. The server response was: mail.smtp2go.com: SMTP command timeout - closing connection

 

I pulled the session log from SMTP2GO, and it kind of backs up what I was seeing before. The connection initializes like it should, but it looks like Emby’s client never actually finishes the TLS handshake. After sitting open for the full timeout window, SMTP2GO closes the connection with that same “Service not available, closing transmission channel” message.

That makes me think it’s not really a refusal or bad auth on their end more like the handshake just never completes. So it’s possible the .NET SMTP client in Emby is opening the line, starting STARTTLS, and then stalling before it gets a proper response. When I trigger an email manually, it goes through fine, so it seems like whatever’s happening only hits the async send path.

Edited November 6, 2025 by Jrod696

[Luke 42077]

Ok that sounds like an issue in the dotnet smtp client.

[mjtbrady 1]

I think that I am seeing the same issue.  At least I am getting the same error in the log.

2025-11-08 00:46:13.101 Error Notifications: Error sending notification
        *** Error Report ***
        Version: 4.9.1.80
        Command line: /system/EmbyServer.dll -programdata /config -ffdetect /bin/ffdetect -ffmpeg /bin/ffmpeg -ffprobe /bin/ffprobe -restartexitcode 3
        Operating system: Linux version 6.12.43+deb12-amd64 (debian-kernel@lists.debian.org) (x86_64-linux-gnu-gcc-12 (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils fo
        OS/Process: x64/x64
        Framework: .NET 8.0.11
        Runtime: system/System.Private.CoreLib.dll
        Processor count: 16
        Data path: /config
        Application path: /system
        System.Net.Mail.SmtpException: System.Net.Mail.SmtpException: Service not available, closing transmission channel. The server response was: 4.4.2 kolab06.devnull.net.nz Error: timeout exceeded
           at System.Net.Mail.MailCommand.CheckResponse(SmtpStatusCode statusCode, String response)
           at System.Net.Mail.MailCommand.EndSend(IAsyncResult result)
           at System.Net.Mail.SendMailAsyncResult.SendMailFrom()
           at System.Net.Mail.SmtpTransport.BeginSendMail(MailAddress sender, MailAddressCollection recipients, String deliveryNotify, Boolean allowUnicode, AsyncCallback callback, Object state)
           at System.Net.Mail.SmtpClient.SendMailAsync(Object state)
           at System.Net.Mail.SmtpClient.SendAsync(MailMessage message, Object userToken)
        --- End of stack trace from previous location ---
           at MediaBrowser.Plugins.SmtpNotifications.Notifier.SendNotification(InternalNotificationRequest request, CancellationToken cancellationToken)
           at Emby.Notifications.NotificationQueueManager.StartProcessingQueue()
        Source: System.Net.Mail
        TargetSite: Void CheckResponse(System.Net.Mail.SmtpStatusCode, System.String)

I am not certain when this started, but I think that it was with the 4.9.1.80 upgrade.

The notifications that I noticed failing were "New Media Added" and "Media Removed".  These were enabled before the Emby upgrade.  The above log message is for a "New Media Added" event.

The "Send Test Notification" always works.  Both before and after the upgrade and specifically worked both before and after receiving the above log message without any changes.

Enabling "Playback - Start" and "Playback - Stop" notifications works.  These were not enabled before the upgrade.

Disabling the "New Media Added" and "Media Removed" notifications, saving, re-enabling them and saving made a "New Media" event work once.  A subsequent "Remove Media" failed again.

The SMTP server that I am sending to is my own internal server that is being used by many other applications on my network.  Emby is the only application having problems.